Re: [RFC] [PATCH] file posix capabilities

[Casey Schaufler <casey@schaufler-ca.com>]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:


> The hard part of capabilities isn't the kernel
> mechanism - it is the
> proper assignment and management of the capability
> bits on files, and
> teaching userland that uid 0 is no longer magic.

Stephen is correct here. Getting the capability
settings correct on all setuid programs is a
tough nut. Training people out of the root
model isn't easy, either.

> Which is all work that
> is already well underway for SELinux, but you would
> have to replicate it
> for capabilities.

The work underway for SELinux is different
from that of capabilities. POSIX capabilities
offer substantial benefits without the high
cost of SELinux.

> And since there is no notion of
> equivalence classes
> ala SELinux types and the "policy" is completely
> distributed throughout
> the filesystem state, management is going to be even
> more painful for
> the capabilities.

This is not the experiance of Irix, which
has supported POSIX capabilities for years.

> On the kernel side, in addition to updating the
> bprm_secureexec logic,
> you would need to consider whether the capability
> module needs to
> implement capability comparisons for the other
> hooks, like task_kill.
> At present, many operations only involve uid
> comparisons and SELinux
> checks without explicitly comparing capability sets.

Yes. There is work to be done.

>  Properly isolating
> and protecting processes with different capability
> sets but the same uid
> is something SELinux already can do (based on
> domain), whereas the
> existing capability module doesn't really provide
> that. 

That's a matter of taste in policy. There
is certainly no Common Criteria requirement
for that.

Sure, SELinux and POSIX capabilities are
different. No arguement. POSIX capabilities
predate SELinux in the community and in the
Linux kernel. To date they have been limited
by the lack of xattr support, but now that 
that is available there is every reason to
complete the implementation.


Casey Schaufler
casey@schaufler-ca.com