Skip site navigation (1)Skip section navigation (2)
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>