Date: Fri, 25 Jul 2008 13:18:25 +1000 (EST) From: "Tim Clewlow" <tim@clewlow.org> To: "Matthew Dillon" <dillon@apollo.backplane.com> Cc: Kostik Belousov <kostikbel@gmail.com>, Liste FreeBSD-security <freebsd-security@freebsd.org>, Robert Watson <rwatson@freebsd.org>, Lyndon Nerenberg <lyndon@orthanc.ca> Subject: Re: A new kind of security needed Message-ID: <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> In-Reply-To: <200807242320.m6ONKPgW007279@apollo.backplane.com> References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Well, what we are talking about here is not just copying > OpenBSD, > but perhaps providing a similar feature that doesn't have the > same > security failings. > > I think the best way to approach the problem is to work out the > desired > userland API first... find the easiest and most convenient way > to wrap > an application, what kind of features are desired, etc, and then > implement it. > > It seems to me that while there are many system calls which can > indirectly provide filesystem accessibility (1), the biggest > guns are > the ones which have to run through namei(). That bodes very > well for > being able to code up namespace controls that would also > properly operate > across softlinks. FreeBSD's namei() does do a copyinstr()... at > that > point the path and its various components are in kernel space. > > The only gotcha that I see is how to match directory-relative > components against global paths. You might need a working > kernel-side > CWD for that. I dunno, I haven't thought that far ahead. > > (note 1): For a production system I think one must separate > recovery > from exploitation. The idea of having namespace restrictions is > not > to prevent the exploitation from occuring, but instead to > prevent > it from causing so much damage that the sysad is forced to > compare the > entire set of accessible filesystems against backups to > revalidate > the system. > > -Matt 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. Note 1: the AID would only be tested if/after normal DAC has granted access. Note 2: It may be desirable to limit this extention to a particular section of the file system, eg /home/ - perhaps via a configuration setting somewhere. Note 3: There would need to be a way of guaranteeing unique identification of an application, maybe the full path / binary name. Note 4: It would not need to be an extension to DAC, it could just as easily be a layer added on top. Anyway, to summarise, my thinking is that: to protect all/most of a users data from a badly behaving user process (eg firefox), there would need to be a way to allow/deny specific applications from accessing specific files - and therefor at a minimum there must be the equivalent of an Application ID to match against. Just some thoughts, Tim. PS - This may already be covered by MAC, I should really read more about that :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51095.192.168.1.10.1216955905.squirrel>