Music Applet 0.9.0 Released

Rhythmbox Applet is dead! Long live Music Applet!

That’s right, with the advent of support for Banshee, the name Rhythmbox Applet is no longer suitable for a GNOME panel applet that lets you control your favorite music player. So, despite Benji‘s best efforts to get me to name it “Kulinibox” (“it’s eponymously cool!”), its name has changed to Music Applet

And accordingly with big changes, there’s been a big jump in the version number (0.9.0) and a new web site for the software, one that should hopefully load much faster than the old one did.

Here’s a quick sketch of the roadmap for Music Applet’s future. This is all subject to change, of course:

  • For 0.9.1: Muine support.
  • For 0.9.2: Album art support (and figuring out how to properly handle features that are supported by only some music players, such as album art and song ratings).
  • For 0.9.3 and beyond: Improving the applet GUI.

For those of you using the old Rhythmbox Applet RSS feed, you’ll want to switch over to the new Music Applet RSS feed, which will carry all future announcements for the software.

SELinux Symposium Notes: Session 7

[Editor's note: It's almost over! Since I had to bail on Session 8 to catch my flight back to Indiana, this is the last set of notes I was able to take. My handwriting gets worse and the content gets more terse with each set. Insert disclaimer here. Enjoy.]

Lessons Learned Developing Cross-Domain Solutions on SELinux (Karl MacMillan et. al., Tresys Technology)

for high-security or untrusted compartmentalized environments
primary goals: confidentiality (H -/-> L) & integrity (L -/-> H); use information flow pipeline
CDS breaks BLP, Biba models — want to control flows, not prohibit outright
let SELinux do the heavy lifting; minimize what app has to do; but apps do need to do transfer policy (e.g. “documents have no executable content” done by app, but SELinux can force filter to be used)
control access to domains to prevent uncontrolled information flows
use multiple localhost aliases (separately labeled) for network-based IPC among local compartments
one-way IPC w/o covert back channels (e.g. timing)? most design for bidi IPC
existing policies often more permissive than strictly necessary — not consider narrow flows
TE works very well for CDS & assured pipelines

Lopol: A Deductive Database Approach to Policy Analysis and Rewriting (Aleks Kissinger et. al., University of Tulsa)

lightweight, interactive, iterative, based on logic programming (Datalog)
operates on policy.conf, translate rules into relations
Datalog evaluation on binary decision diagrams
analysis by forming rules & running queries (primitive rules: reads, writes, [transitive] flows)
generic rules: privileged types, trusted intermediaries, …

Attack-based Domain Transition Analysis .(Susan Hinrichs et. al., University of Illinois at Urbana – Champaign)

what happens if a domain is coopted? information flows, domain transitions (transitively)
look at what a domain can read and write, considering transitions
global domain transition graphs large — domain not bounded as much as we’d like
graph shallow and very wide
consider subgraphs starting at suspect domains & end at sensitive domains
edges: cut edges along paths, or log more carefully, or disable when under threat (via boolean)
nodes: study domain & verify it can’t be misused, insert high-assurance proxy, split domain

Comments Off

SELinux Symposium Notes: Session 6

[Editor’s note: Is he seriously still typing up the notes he scribbled down during the talks at the SELinux Symposium earlier this month?! Doesn’t he know they’re not even necessarily reliable and shouldn’t be used for anything more than recreational reading?]

Experience Implementing a Higher-Level Policy Language for SELinux (Chad Sellers et. al, Tresys Technology)

SELinux has MAC foundation; HLL represents different paradigms, reaching new users, new features
CDS describes information flows, targeted at app developers — compiler & IDE
domains — active entities/security perimeter; shared resources — passive, for domain interaction
access — r/w/rw b/t domain & shared objects
decomposition of domains for better least privilege
challenges: concepts (idealized) v. SELinux details, must integrate w/ base policy [CDS only for cross-domain, not the whole thing]
e.g. IPC not labeled a priori but by creator, same label = equivalent — control resources share label w/ domain and are individually unique
SELinux has many ways to label files, but too complex for HLL; but paths aren’t enough
idea: paths label directories only, sidestepping many issues (leakage, existence, etc.)
hooking into base policy: wrap resource in “baseresource” to define r/w access to it; singleton (likewise for basedomain)

SENG: An Enhanced Policy Language for SELinux (Paul Kuliniewicz, Purdue University)

[Editor's note: Sorry, no notes for this one. I must not have been paying attention.]

Guided Policy Generation for Application Authors (Brian Sniffen et. al., MITRE Corporation)

policy creation/management tools, looking at information flow goals
guided automation, least privilege in use, not toal capabilities of app
idea: find patterns in program behavior, ask writer if things look reasonable
polgen specification language to describe architecture of app
suggest additions from execution traces — limits to how app will be used
can recognize ~12 patterns of operation

Comments Off