Date: Thu, 17 Jul 2008 23:34:50 +1000 (EST) From: "Tim Clewlow" <tim@clewlow.org> To: "Robert Watson" <rwatson@FreeBSD.org> Cc: Liste FreeBSD-security <freebsd-security@freebsd.org> Subject: Re: A new kind of security needed Message-ID: <50456.192.168.1.10.1216301690.squirrel@192.168.1.100> In-Reply-To: <20080717085136.B87887@fledge.watson.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> > On Thu, 17 Jul 2008, Patrick Proniewski wrote: > >>> Absolutely. Right now, I use different logins for different >>> things (casual >>> web surfing, financial stuff, snd work), but it's inconvenient >>> and far from >>> fullproof. >>> >>> Capabilities or MAC systems could be used here -- someone just >>> has to put >>> in the work to make it happen. >> >> What about sandbox/chroot ? Apple has designed such a system for >> Mac OS X >> 10.5, and even if it's not fully functional now, it's probably >> interesting. >> >> <http://developer.apple.com/documentation/Darwin/Reference/ManPages/man7/sandbox.7.html>; > > And, interestingly, the Mac OS X Sandbox parts are based on the > TrustedBSD MAC > Framework that was first developed on FreeBSD and later port to Mac > OS X. > However, Sandbox is not open source, and does rely on the > reliability of > pathnames, which on UFS (and even HFS+) is a bit of a tricky issue. > > FWIW, I have some work in progress on the capability front, but it's > a highly > complex issue that will take years to work through properly. > Unfortunately, > the real issue isn't so much the OS primitives as building up a > non-trivial > application base that uses them. Providing primitives to subdivie > applications isn't easy, but once you've done that you still have to > rewrite > lots of applications to take advantage of it, and in a way that > shows a lot > more application programmer discipline. It's not clear to me that > the > pressure is there to make feature-driven application development for > major > desktop applications adopt techniques of this sort. > 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?) 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. Regards, Tim. We are BSD ... resistance is futile. http://www.freebsd.org/ - http://www.openbsd.org/ - http://www.netbsd.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50456.192.168.1.10.1216301690.squirrel>