Re: [RFC] [Stacking v4 2/3] New version of SELinux patch to support stacking

From: Stephen Smalley (sds@private)
Date: Wed Dec 08 2004 - 11:22:59 PST

On Tue, 2004-12-07 at 15:44, Stephen Smalley wrote:
> When cap_ptrace or cap_bprm_apply_creds calls capable(), we do want that
> capability to be checked by SELinux as well, just as we would for a
> capable() call by the core kernel's ptrace_attach or compute_creds
> logic.  From our perspective, the original capabilities logic is part of
> the core kernel, despite the fact that it has been pushed into a
> module.

Note btw that cap_bprm_apply_creds() isn't just the capability logic
anymore, as the entire compute_creds logic was pushed into it as part of
fixing a race condition.  (See the threads starting at and for
background on that change).

>   In order to independently apply that capability check in the
> corresponding SELinux hook function, we would have to duplicate the
> logic in the cap_ptrace or cap_bprm_apply_creds functions that decide
> whether or not to check that capability, and would end up duplicating
> most of those functions in their entirety.  At that point, we lose any
> value from using cap_* at all and might as well just maintain our own
> copy of the entire logic in the SELinux hook functions.

And we definitely don't want to have to reproduce the core setuid/setgid
logic in SELinux.

> On the other side, with the current situation, we have to duplicate a
> copy of the logic in the cases where we need to customize it, e.g.
> vm_enough_memory, inode_setxattr, inode_removexattr.  But I'd rather do
> that and be able to re-use cap_bprm_apply_creds than the other way
> around.

This is actually not quite right - even with your patch, we can't re-use
cap_inode_setxattr or cap_inode_removexattr.  So the tradeoff is between
being able to re-use cap_vm_enough_memory vs. being able to re-use
cap_ptrace and cap_bprm_apply_creds.

Speaking of cap_vm_enough_memory, looks like I need to re-sync
selinux_vm_enough_memory with it.

Stephen Smalley <sds@private>
National Security Agency

This archive was generated by hypermail 2.1.3 : Wed Dec 08 2004 - 11:28:34 PST