Date: Fri, 25 Jul 2008 06:56:54 +0200 From: Szilveszter Adam <sziszi@bsd.hu> To: freebsd-security@freebsd.org Subject: Re: A new kind of security needed Message-ID: <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> In-Reply-To: <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 25, 2008 at 01:18:25PM +1000, Tim Clewlow wrote:
> Some more thoughts.
<...>
> The existing DAC method already provides sufficient protection (we
> all hope) to system objects, often via root/wheel. What we really
> want is a mechanism to protect user data from being clobbered by an
> errant program. By extending the traditional DAC with an Application
> ID (AID) the kernel could allow or deny processes that are part of a
> particular application from accessing a file based on the rwx flags
> of the AID for a particular user file.
This idea may work quite well for a server (and already does, there are
several implementations out there). But for an interactive desktop
software that a user drives in real-time (like firefox, as you mention)
this does not work. Think about it: You want firefox to not touch your
files in your ~ directory, so you configure FF in this way. But then,
somehow you come to the very unlikely idea that you want to actually
download something from the web. (eg a PDF manual for the latest gadget
that you bought) Or upload one of your photos to an
online album (as Robert Watson has already pointed out). What now? FF is
not allowed to touch your files, so will not be able to do at least the
first case (because that requires write access to some location in order
to save the file) but quite possibly the second may not work either,
after all, why would you want FF to read your office documents, so you
have already denied that as well.
There is no secure and usable solution to this problem, as Robert has
already pointed out. The whole notion of sandboxing rests on the idea
that the behaviour of an application is very deterministic (it only does
A, and never, ever, anything else, during normal operation) and not very
complex. Typical desktop software is already very complex, has a lot of
functions and is not deterministic almost by design: there is a human
sitting in front of it, doing this on one occassion and something else
on another. If you allow everything that the functions of the software
might cover (or only a reasonable set) you are already almost at the
status-quo: You have to allow access to many-many objects, many of which
are not in use most of the time, some are not in use ever, but who
knows.
Anything else is bad: Requiring reconfiguration of the sandbox everytime you
want to save a file and then setting it back does not work. Prompting
the user "Are you sure you want FF to access your files?" is bad. ("Yes,
do it already!") Using "trusted" components, services, or locations to
hack around it is bad. (When push comes to shove, there is nothing that
could be "trusted" on a normal PC, not even the hardware in this age of
mobile computing.)
So no, the idea itself is interesting but does not work in the general
case. It does work in specific cases though, and there it should be
considered. (For example in a public Internet terminal you have no business to
save anything on the local hard drive, so there is no need to allow
that. But then, the desired effect can be reached much more easily
there even with the existing access control.)
--
Regards:
Szilveszter ADAM
Budapest
Hungary
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080725045654.GA1572>