Re: capabilitiescompute_cred

Re: capabilitiescompute_cred

[Andy Lutomirski]

Chris Wright wrote:
>>IMHO, capabilities are a broken idea anyway, and should ultimately be
>>replaced entirely using Type Enforcement (which SELinux includes).  A
>>comparison of the two approaches is in
>>http://www.securecomputing.com/pdf/secureos.pdf.  Today we still stack
>>SELinux with the capabilities module, but long term, I'd like to see us
>>just drop capabilities and use TE by itself to manage privileges.
> 
> 
> 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.

> 
> 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.

> 
> thanks,
> -chris

Re: capabilitiescompute_cred

[Chris Wright]

* 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

Re: capabilitiescompute_cred

[Stephen Smalley]

On Fri, 2004-04-02 at 15:21, Andy Lutomirski wrote:
> 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.

I'm not opposed to making the existing capability logic more useable; I
just think that capabilities will ultimately be superseded by TE.
 
> 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.

Does revising the capability logic need to wait on 2.7?  Have you
changed the logic significantly since the last patch you posted to lkml?

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

Re: capabilitiescompute_cred

[Andy Lutomirski]

Stephen Smalley wrote:

> On Fri, 2004-04-02 at 15:21, Andy Lutomirski wrote:
> 
>>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.
> 
> 
> I'm not opposed to making the existing capability logic more useable; I
> just think that capabilities will ultimately be superseded by TE.
>  
> 
>>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.
> 
> 
> Does revising the capability logic need to wait on 2.7?  Have you
> changed the logic significantly since the last patch you posted to lkml?
> 

I don't _think_ it's changed, but I'll double-check that in a few days 
(I'm out of town).  I'll also rediff my patch.  Should it be a config 
option?

Anyway, I have no strong objection to seeing a change in 2.6 -- there's 
just some risk that it could break something that depends on the current 
(broken, undocumented) behavior.

Andrew:  would you be willing to put a capabilities fix into -mm?

--Andy