Date: Thu, 24 Jul 2008 16:20:25 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: 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: <200807242320.m6ONKPgW007279@apollo.backplane.com> References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org>
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
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807242320.m6ONKPgW007279>