Date: Mon, 28 Jul 2008 12:28:38 -0700 From: "Matt Reimer" <mattjreimer@gmail.com> To: "Szilveszter Adam" <sziszi@bsd.hu> Cc: freebsd-security@freebsd.org Subject: Re: A new kind of security needed Message-ID: <f383264b0807281228t7a20861do2f0c150cb5eb67f3@mail.gmail.com> In-Reply-To: <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> 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> <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 24, 2008 at 9:56 PM, Szilveszter Adam <sziszi@bsd.hu> wrote: > 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. My idea was to basically have a secure file picker that grants the app (e.g. Firefox) access to the file, in a way that would be transparent to the user. For example, when Firefox wants to save a PDF it displays the file picker as usual and the file is saved. Underneath what's happening is that Firefox talks to the trusted system filepicker via a socket, and depending on the user's input it grants access to the file, whether temporarily or permanently. If Firefox is using the standard GTK file picker, then only GTK would need to be changed. Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f383264b0807281228t7a20861do2f0c150cb5eb67f3>