[cap-talk] "ACLs don't" paper rejected from Oakland 09

James Morris jmorris at namei.org
Mon Feb 2 08:05:42 EST 2009


On Mon, 2 Feb 2009, Matej Kosik wrote:

> "On the other hand, capabilities solve the problem of sandboxing mobile
> code very elegantly. When a foreign program is started, it is given a
> capability list containing only those capabilities that the machine
> owner wants to give it, such as the ability to write on the screen and
> the ability to read and write files in one scratch directory just
> created for it. If the mobile code is put into its own process with only
> these limited capabilities, it will not be able to access any other
> system resources and thus be effectively confined to a sandbox without
> the need to modify its code or run it interpretively. Running code with
> as few access rights as possible is known as the *principle of least
> privilege* and is a powerful guideline for producing secure systems"
> 
> He does not explain how to do a similar (quite important) thing with
> ACLs. Was that already achieved? Is that planned? Is UAC the solution?
> Is SELinux the solution?

Work has been going on in this area with SELinux.  There are a couple of 
examples which are shipping and ready to use.

"Kiosk Mode" uses a combination of filesystem namespaces and fine grained 
MAC policy to provide a highly constrained anonymous desktop/web 
environment, aimed at public-use systems, but also potentially useful for 
browsing untrusted sites and running untrusted code.  Nothing persists 
after the session is terminated, so it may also have applications in the 
area of privacy.

A few talks on the topic have been given at Linux conferences, including 
mine at last year's FOSS.IN.  The abstract and slides may be found at 
http://foss.in/2008/register/speakers/talkdetailspub.php?talkid=572

It's pretty easy to get running if interested, just install a recent 
Fedora and install the 'xguest' package, and you're set.

Another area of work with SELinux is confining Firefox browser plugins, 
which is made possible using the 'nsplugin' facility originally designed 
to allow 32-bit plugins to run in 64-bit browsers.  This runs as a 
separate process to the browser, so a tighter MAC policy may be applied to 
it compared to the browser, and the scheme seems to be able to provide 
useful protection against malicious code executed via plugins (which are 
often proprietary).

This work is not complete (e.g. protection needs to be extended throughout 
the X framework, which is ongoing; and these ideas could be generalized to 
cover all content parsing & processing), although it does seem workable as 
a useful security enhancement in the case of retrofitting an existing OS.


- James
-- 
James Morris
<jmorris at namei.org>


More information about the cap-talk mailing list