[lkml]   [2006]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)
On Tue, 2006-04-18 at 08:21 -0500, Serge E. Hallyn wrote:
> Quoting Stephen Smalley (
> > 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-04-18 15:39    [W:0.146 / U:35.340 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site