On Tue, 2006-04-18 at 08:21 -0500, Serge E. Hallyn wrote:
> Quoting Stephen Smalley ([email protected]):
> > I doubt you'd drop capability altogether. You could incrementally
> > enable the direct granting of capabilities based on SELinux security
> > context by defining a new class in its policy (cap_override) that
> > mirrors the existing capability class, and modifying SELinux to
> > authoritatively grant the capability if it is allowed in that class for
>
> Subject, I hope, to other selinux permission checks! (ie "authoritatively"
> meaning over dac checks, not over it's own mac checks)
Authoritatively over the capability module is what I meant, i.e. if
capability X is allowed in a new cap_override access vector for the
process' domain, then allow the process to exercise that capability and
skip the call to the secondary module (capability or dummy). So you
could allow ping_t to exercise that single capability even if it wasn't
uid 0. But if it is only allowed in the existing capability access
vector and not in the cap_override vector, then only allow it if both
SELinux and the secondary grant it (existing behavior).
Note btw that another reason it is better to do this via SELinux than by
fs caps is that SELinux already provides the right separation/protection
between processes with different security contexts, whereas the
capability module does not (many inter-process interactions are
presently only governed by uid/gid checking).
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
