On Thu, 2004-01-29 at 17:25, Serge E. Hallyn wrote: > Stacker now exports a sysfs file "next_secondary" which would be used as > follows: > > stacker compiled in > selinux compiled in > echo selinux > next_secondary > modprobe capability > > To get capability loaded as a secondary under selinux under stacker. In addition to the sysfs interface, how about a function provided by the stacker module that can be called by the SELinux module internally as part of its initialization to automatically set this "next_secondary" attribute after registering itself with the stacker. Then we could compile all three modules (stacker+selinux+capabilities) into the kernel and not require a userspace action on sysfs. > In SELinux, then, SELinux still unregisters, but if a secondary is loaded > other than dummy, then SELinux manually loads that secondary whichever > way (ie 'register_security' or "mod_unreg_security") selinux itself had > registered. > > Does all that seem like a reasonable approach? Hmm...the problem is that this still can cause automatic escalation of a secondary module to primary module status without its awareness. Now, if using the stacker, then everything else is a "secondary", so that won't be a problem in practice. But if not using the stacker, you still have the same situation as you have today, i.e. SELinux runtime disable escalates capability from secondary to primary without any awareness by it. Only situation where that will matter is if capability is dynamically loaded, in which case it will be confused about how to unregister. > That claim was inaccurate - the function was doing mostly the same thing > as RETURN_ERROR_IF_ANY_ERROR, but with its own shortcircuit variable. > Perhaps another variable should be added which lets stacker_capable act > the way the original did, that is, authoritatively? I don't want to make > this too complicated... I'd favor just being restrictive, and I'm not sure you need the separate shortcircuit variable for capable. Are there any issues with security modules internally calling the top-level capable() function from a particular hook function when used with the stacker? There are examples of such usage in dummy, capability, and SELinux. Or should they always be calling their own capable hook function (e.g. selinux_capable) instead when they want to check a capability within a particular hook function? The latter won't set the PF_SUPERPRIV flag; not sure if that will be an issue for accounting. -- Stephen Smalley <sds@private> National Security Agency
This archive was generated by hypermail 2.1.3 : Tue Nov 30 2004 - 05:44:56 PST