Messages in this thread | | | Subject | Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks) | From | Stephen Smalley <> | Date | Tue, 18 Apr 2006 09:40:34 -0400 |
| |
On Tue, 2006-04-18 at 08:21 -0500, Serge E. Hallyn wrote: > Quoting Stephen Smalley (sds@tycho.nsa.gov): > > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |