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

From: Stephen Smalley (sds@private)
Date: Wed Dec 08 2004 - 12:07:24 PST


On Wed, 2004-12-08 at 15:01, Stephen Smalley wrote:
> Hmm...maintaining selinux_vm_enough_memory() is a bit of a pain, as we
> just want the same logic as cap_vm_enough_memory() except for
> distinguishing the capable() call so that we don't audit CAP_SYS_ADMIN
> attempts on every process for no reason.  I had originally only
> suggested replacing the capable() call with a hook call and leaving the
> rest of vm_enough_memory in the core kernel, but Alan Cox had suggested
> moving the entire logic into a security hook so that security modules
> could in the future implement role-based policies on memory allocation
> (see
> http://marc.theaimsgroup.com/?l=linux-security-module&m=105638662108785&w=2).
> That still seems like a good idea, but it would be nice if we could
> leverage cap_vm_enough_memory or a common helper to reduce the code
> duplication between it and selinux_vm_enough_memory.

Perhaps cap_vm_enough_memory() should be using cap_capable() rather than
capable() for checking CAP_SYS_ADMIN?  Otherwise, it is going to set the
PF_SUPERPRIV flag in current->flags for the process just because of a
mapping, not necessarily just for real use of the capability.

cap_bprm_apply_creds and cap_ptrace should still use top-level
capable(), I think, both to set PF_SUPERPRIV and to ensure that other
security modules are invoked for what is essentially core kernel logic.

-- 
Stephen Smalley <sds@private>
National Security Agency



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