A change in direction for security-module stacking?

Posted Apr 24, 2024 9:27 UTC (Wed) by zyga (subscriber, #81533)
Parent article: A change in direction for security-module stacking?

As someone who works with LSMs I would not mind if the end game was that the kernel offers a unified security architecture that does not differ widely from one major distribution to another, and that a meaningful upgrade path exists to keep all the current use-cases handled.

Maybe that is eBPF everywhere, maybe it is one comprehensive neo-LSM that people can agree upon, but the current situation is far from desirable.

A change in direction for security-module stacking?

Posted Apr 24, 2024 10:23 UTC (Wed) by snajpa (subscriber, #73467) [Link]

Maybe if there's no mention of the word "security" anywhere in that new generation... so it wouldn't trigger the leadership, which doesn't even think there ever was such a thing as "security" bugs. IMHO it's futile.

A change in direction for security-module stacking?

Posted Apr 24, 2024 15:46 UTC (Wed) by cschaufler (subscriber, #126555) [Link] (1 responses)

Security has evolved significantly during the lifetime of Linux. No one saw a need for containers, sandboxes or kernel hardening when LSM was introduced over twenty years ago. Back then we were looking at Bell & LaPadula sensitivity and access control lists. We can't introduce new mechanisms to support new use cases if it means dropping support for old mechanisms needed for old use cases. There isn't now, nor will there ever be, a single "security" solution that will please everyone. Even if everyone did agree, there would still be the need to turn it off in some configurations.

A change in direction for security-module stacking?

Posted Apr 25, 2024 10:55 UTC (Thu) by snajpa (subscriber, #73467) [Link]

linux-vserver was introduced in 2001, OpenVZ GPL'd in 2005... so, noone could have predicted this :-D