Date: Thu, 24 Jul 2008 09:05:45 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Tim Clewlow <tim@clewlow.org> Cc: Liste FreeBSD-security <freebsd-security@freebsd.org> Subject: Re: A new kind of security needed Message-ID: <20080724085912.U63347@fledge.watson.org> In-Reply-To: <50456.192.168.1.10.1216301690.squirrel@192.168.1.100> References: <f383264b0807161710m285ed915m8ea9d088fbe83df9@mail.gmail.com> <alpine.BSF.1.00.0807162303490.34772@treehorn.dfmm.org> <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <50456.192.168.1.10.1216301690.squirrel@192.168.1.100>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080724085912.U63347>