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

From: Serge Hallyn (serue@private)
Date: Wed Dec 08 2004 - 13:37:21 PST


On Wed, 2004-12-08 at 15:07 -0500, Stephen Smalley wrote:
> 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.

But you still want cap_vm_enough_memory() to ask for selinux
avc_has_perm_noaudit if cap_capable() failed, right?  So might it be
better to create a new vm_may_exceed() hook, where the commoncap version
is simply

int cap_vm_may_exceed() {
  return cap_capable(CAP_SYS_ADMIN);
}

And have cap_vm_enough_memory call vm_may_exceed().  Then selinux_ops
can set
	vm_enough_memory = cap_vm_enough_memory,
	vm_may_exceed = selinux_vm_may_exceed,

Is that what you were getting at in your previous message by "a common
helper"?

-- 
Serge Hallyn <serue@private>



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