Re: capabilitiescompute_cred

[Chris Wright <chrisw@osdl.org>]

* Andy Lutomirski (luto@stanford.edu) wrote:
> Chris Wright wrote:
> > I have the same dislike for capabilities.  It's more like a wart than
> > a feature.  I get requests to have RBAC be the core priv system rather
> > than capabilities.
> 
> I agree in principle, but it would still be nice to have a simple way to 
> have useful capabilities without setting up a MAC system.  I don't see a 
> capabilities fix adding any significant amount of code; it just takes 
> some effort to get it right.

Main problem is the granularity and poorly defined semantics.  You have
no context when making a capability decision.  In some cases it
overrides normal DAC checks, and in other cases it's a stand alone
privilege.  Then there's CAP_SYS_ADMIN...

> > In the meantime, I've often idly wondered why we don't simply inherit as
> > advertised.  The patch below does this, but I haven't even started
> > looking for security sensitive failure modes.
> 
> I'm not sure that introduces security problems, but I'm also not sure it 
> fixes much.  You can find my attempts to get it right in the 
> linux-kernel archives, and I'll probably try to get something into 2.7 
> when it forks.  With or without MAC, having a functioning capability 
> system wouldn't hurt security.

It simply allows one to properly inherit.  As it stands inherit is
totally broken.  Once you execve() the capabilities get reset to all or
nothing.  So if you want to drop privs and execve() bash (as a login
utility might do), you'll need something like this.  Only hesitance I
have is being sure it doesn't introduce some subtle bug.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net