Authoritative hooks

Posted Aug 10, 2022 21:39 UTC (Wed) by cschaufler (subscriber, #126555)
In reply to: Authoritative hooks by corbet
Parent article: Security requirements for new kernel features

Had we adopted authoritative LSM hooks the landscape would be very different indeed. Stacking of modules would have been impossible. What would happen if module A said "yes" and module B said "no"? You'd have to define some sort of peeking order for the modules, which wouldn't make each module authoritative now, would it? What we could do is refactor the traditional Linux discretionary controls into an LSM and insert it at the front of the list. You could then implement POSIX ACLs in an LSM, replacing the mode-bit only hooks with ACL cognizant ones. To forgo DAC all you would have to do is drop that module from the list. Now I suppose one might only want to drop certain of the controls (e.g. signal delivery ) and not the whole set. That's solvable, but hideous. Too much "fine granularity" for my taste.

to post comments

Authoritative hooks

Posted Aug 11, 2022 0:09 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> Had we adopted authoritative LSM hooks the landscape would be very different indeed. Stacking of modules would have been impossible. What would happen if module A said "yes" and module B said "no"?

Various systems (like IAM policies in AWS or ACLs in Windows) typically consider "Deny" to be a veto on any allowing ACLs/policies.

Authoritative hooks

Posted Aug 11, 2022 17:50 UTC (Thu) by cschaufler (subscriber, #126555) [Link] (1 responses)

This is exactly the "bail on fail" model of permissive hooks that we have today. What you can't do is what you had asked for, which is to provide a mechanism for a hook to grant access instead of denying it as would occur otherwise. We could make it possible, but that would have -- wait for it -- performance impact. :)

Authoritative hooks

Posted Aug 11, 2022 18:50 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> What you can't do is what you had asked for, which is to provide a mechanism for a hook to grant access instead of denying it as would occur otherwise.

That would actually help and make time investment into SELinux be worthwhile, as it will open up _new_ possibilities. Performance impact is another question, and it'd be interesting to see if removing the DAC entirely in favor of MAC would help.