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 http://marc.theaimsgroup.com/?l=linux-kernel&m=108153697611991&w=2 and http://marc.theaimsgroup.com/?l=linux-kernel&m=108256931919656&w=2 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