* Stephen Smalley (sds@private) 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. Yeah, I wondered the same when I did that helper hack. It's even more egregious, because the capability may not even be checked (i.e. OVERCOMMIT_ALWAYS). thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2.1.3 : Wed Dec 08 2004 - 12:24:54 PST