Chris Wright wrote: >* Chris Wright (chrisat_private) wrote: > > >>* Greg KH (gregat_private) wrote: >> >> >>>Ok, that's reasonable to me, have a patch? :) >>> >>> >>Heh, not right now...I can spin up some examples later today. Do you >>have an audit list of the unused hooks? The two together would be useful. >> >> >A couple of trivial examples below. For things like iopl/ioperm where >capable() is only called when you are increasing your privilege level or >enabling perm bits on ioports I expect we'd preserve that behaviour. >That would mean the LSM hook would not be consulted on all checks, just >those deemed security sensitive. The alternative is to hide those >details in the capability module, which seems wrong to me. >-chris > > On the one hand, my instinct says that it is bad to confound the permissive capable() interface with the restrictive other hook interfaces: that breaks the abstraction, making the interface harder to understand. On the other hand, the alternative seems even worse: the sample Chris illustrates has a call to capable() followed immediately by a call to security_ops->reboot(). These two hooks are now at war: the capable module may be trying to permissively grant permission to reboot, with some other module saying "no you cannot reboot." This is problematic because from the outside (say, an admin composing modules with Stacker) you cannot tell which policy will win without looking at the code. Aaieee :) So it seems to me that these two hooks should be composed, if only for clear semantics. In general, we should compose adjacent calls to capable/adjoining hook calls, so that it is clear who wins if the policies conflict. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX http://wirex.com/~crispin/ Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html
This archive was generated by hypermail 2b30 : Tue Oct 01 2002 - 00:41:26 PDT