On Tue, 30 Nov 2004 08:39:09 EST, Stephen Smalley said: > I'd favor just being restrictive, and I'm not sure you need the separate > shortcircuit variable for capable. Agree on that one... > 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. This has always given me a Bad Feeling - if capability and selinux are both doing that in the same hook, we end up with selinux doing its own checks and then calling the capability checks, then capability does its own checks and the calls the selinux checks. At best, this is doing all the checks twice. Does anybody else on the list have kids that have learned to social-engineer the "It's OK with me if it's OK with <other parental unit>?" and "Go ask your <other parental>?" - this feels a lot like that same failure mode... Given that all the *other* cases are strictly "each LSM in turn consults its own exits/data in a restrictive chain", the capable stuff should probably be refactored to do it the same way, before some LSM is created that doesn't realize that capable is different from all the others (has anybody looked at the 'realtime' LSM to see if they get it right? Or do they just assert the appropriate capability bit and then hope everybody else gets it right?)
This archive was generated by hypermail 2.1.3 : Tue Nov 30 2004 - 09:07:17 PST