Performance impact

Posted Aug 9, 2022 16:16 UTC (Tue) by cschaufler (subscriber, #126555)
In reply to: Performance impact by Cyberax
Parent article: Security requirements for new kernel features

Stacking LSMs could have been completed a decade ago had it not been for some of the design choices forced upon the security module developers to ensure that performance impact on systems that don't use LSMs is minimized. I understand and appreciate that in whatever subset of the Linux development community you reside LSM is not considered useful. I personally have little interest in the device driver infrastructure, which many developers consider most critical. I am concerned that work I do in LSM does not interfere with device drivers *to the extent possible*. If you need to blame CAP_SYS_ADMIN on somebody, I'm probably the best target. The Linux kernel does lots of things for lots of reasons. I have no idea what you work on, or why, but I'm willing to wager a refreshing beverage that we could have made security a much bigger pain than it is now.

to post comments

Performance impact

Posted Aug 9, 2022 20:15 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

> I understand and appreciate that in whatever subset of the Linux development community you reside LSM is not considered useful.

It's not that it's not useful, additional mitigations are great. It's that the amount of effort that needs to be expended to make use of SELinux is just not comparable with the amount of protection it provides. I long ago tried to make sense of policies and to create my own toy policies, but failed miserably. TOMOYO is rigorously undocumented and I haven't touched Smack because it doesn't even look in any way "simplified".

AppArmor is a bit better, since it at least doesn't require labelling across all of the filesystem which is nothing but security theater compared to just using paths. Its policies are also easier to understand.

One feature that I really personally would have liked is an ability to use LSMs to _grant_ permissions instead of taking them away.

Performance impact

Posted Aug 9, 2022 20:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

And yeah, at this point I'd just prefer a well-tailored ad-hoc solution like pledge()/unveil() in OpenBSD to the generalized LSM system that Linux has.

Authoritative hooks

Posted Aug 9, 2022 20:29 UTC (Tue) by corbet (editor, #1) [Link] (4 responses)

It seems you have one point of agreement with Casey, anyway: at one point, at least, he too wanted authoritative hooks in the LSM subsystem.

Authoritative hooks

Posted Aug 10, 2022 21:39 UTC (Wed) by cschaufler (subscriber, #126555) [Link] (3 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"? 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.

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.