I don't think that calling of capable from modules is a problem, because it is not actually called from any module's capable itself. It's used to check for specific privileges, and if any stacked LSM does not want to grant that privilege, then any action depending on that privilege should probably be refused. So I'm actually leaning even more toward agreeing with Stephen that capable should be restrictive. More of a problem is that setting capabilities calls capset_check. In dummy.c this returns -EPERM. So if selinux and capability are each loaded under stacker, without capability being stacked under selinux, then you can't set capabilities. I'm not particularly opposed to saying that if you want to use both selinux and capability, then you should stack capability under selinux. But it was an unexpected result for me just now. -serge Quoting Valdis.Kletnieks@private (Valdis.Kletnieks@private): > 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 - 12:12:31 PST