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
* Andy Lutomirski ([email protected]) 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
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 <[email protected]>
National Security Agency
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