On Thu, 17 Jul 2008, Tim Clewlow wrote:
The "One Laptop Per Child" organisation seem to be taking the sandbox/jail
concept to its extreme in an attempt to neuter viruses. In FreeBSD terms,
they appear to be insisting that each user application on the laptop be run
in its own jail.
http://news.softpedia.com/news/The-100-Laptop-Virus-Free-37464.shtml
This may be feasible on a system designed to be very restrictive in regards
to hacking/tinkering, but much more difficult, if not impossible, to
implement on a system like FreeBSD (how do you build a piped process group
when all the individual processes are separately jailed?)
I think it's worth comparing this and other approaches to the Sandbox approach
used in the version of Mac OS X in the iPhone, which fairly firmly
compartmentalizes applications. The obvious upsets are a high level of
isolation. The downsides are also pretty important to think about, though:
common non-OS-provided infrastructure is minimized, inter-process services are
limited, and especially, inter-application data sharing. Notice that the
iPhone is careful not to expose a generic file system interface for sharing a
single user's files between applications, and for good reason.
This captures, I think, the fundamental challenges of desktop security quite
well: desktop environments are highly interconnected and interdependent
software packages built with a lot of mutual trust and integration. If you
start slicing them up, you both completely disrupt the model they are designed
around, and you also limit their ability to do some fairly widely depended on
things.
Perhaps a security layer could be implemented that includes the ability to
designate some applications as being only allowed to run if they are in a
jail, and then have all other executables not available to be run on their
own. But this would be a very different system from FreeBSD. Maybe it could
be done with a sysctl switch, or maybe it would be such a major change it
should really be considered a separate operating system in its own right, ie
perhaps better implemented as part of PCBSD, or something of that ilk.
Of course, if it can be done, without upsetting everyone, then that would be
ideal, but I agree there would be a great deal of work involved.
Jails are extremely useful, but rest on the principle of pretty complete
isolation of jailed environments. This is great for ISPs, but not so good if
you want your web browser to sometimes, but not always, be able to upload your
OpenOffice.org accounting spreadsheets to web sites. Even if you play a lot
of grafting games using nullfs, etc, it's still messy. Assuming a desire to
move incrementally towards a more fine-grained model, I suspect the starting
point is to produce some security tools for application-based subdivision of
the OS environment (and user rights), and then apply them in the most critical
places first.
I've had capability-related patches for FreeBSD on the back-burner for some
time -- they allow processes to arbitrarily subdivide themselves into "jails"
passing only very specific rights into the compartments, etc. They're not
really for widespread use, since I've been trying to drive their development
by adapting applications to use them for things like executing script
interpreters, etc, and that process is slow, as it involves a lot of software
adaption, but some of the work, at least, is probably ready to see the world.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
