Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Tim Clewlow (timclewlow.org)
Date: Thu Jul 24 2008 - 22:18:25 CDT
> Well, what we are talking about here is not just copying
> but perhaps providing a similar feature that doesn't have the
> security failings.
> I think the best way to approach the problem is to work out the
> 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
> 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
> CWD for that. I dunno, I haven't thought that far ahead.
> (note 1): For a production system I think one must separate
> from exploitation. The idea of having namespace restrictions is
> to prevent the exploitation from occuring, but instead to
> it from causing so much damage that the sysad is forced to
> compare the
> entire set of accessible filesystems against backups to
> the system.
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
Note 2: It may be desirable to limit this extention to a particular
section of the file system, eg /home/ - perhaps via a configuration
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 :-)
freebsd-securityfreebsd.org mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribefreebsd.org"