LSM stacking (again)

Posted Jun 25, 2010 14:01 UTC (Fri) by tialaramex (subscriber, #21167)
In reply to: LSM stacking (again) by Cyberax
Parent article: LSM stacking (again)

You're using PAM as your example? Seriously?

It is /way/ too easy to screw up PAM configuration and get something that doesn't work, or, worse something which gives every appearance of working but turns out to inadvertently let anyone into service X with root privilges by providing a blank username and password.

If PAM is the standard to which stacked modules will be held, they're never going to get into the Linux kernel.

to post comments

LSM stacking (again)

Posted Jun 25, 2010 14:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

But the alternative is no access control at all. Is it better?

LSM stacking (again)

Posted Jun 28, 2010 1:54 UTC (Mon) by raven667 (subscriber, #5198) [Link] (4 responses)

That is a false dichotomy if I ever heard one. The alternative to stackable LSM is the current state, several comprehensive security frameworks, not a lack of access permissions. It's unfortunate that this approach starves out small single purpose access control modules but any controll which is worthwhile will probably get picked up by one or more frameworks eventually.

LSM stacking (again)

Posted Jun 28, 2010 2:16 UTC (Mon) by dlang (guest, #313) [Link] (2 responses)

Quote: any controll which is worthwhile will probably get picked up by one or more frameworks eventually

If you believe that this is the case you should have no objection to LSM stacking as you will only want to use these major frameworks that have picked things up from the small players anyway.

the rest of us who are interested in multiple small solutions that we can understand will be your beta testers for these small modules before they can get picked up.

if the only way to try something new is to either abandon all protection from anything else, or wait until the idea gets picked up in the big framework (without anyone being able to test it until then) you have very little testing of new things

LSM stacking (again)

Posted Jun 28, 2010 4:36 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

Your arguments do not convince me that the kernel developers are wrong in rejecting stackable LSM. What you describe, kernel hackers making their own new modules to test different security ideas, is already happening in the real world and is the reason we are having this conversation. You don't need this change to support testing, it's not clear where exactly it would be useful. Not just useful but it is not clear that a stackable approach would be better than just having a working security system, whichever one you like.

LSM stacking (again)

Posted Jun 29, 2010 12:54 UTC (Tue) by mpr22 (subscriber, #60784) [Link]

My perspective is that we're in a "pick one" scenario, with the options being roughly:

The kernel team provides LSM stacking.
Someone writes an LSM which implements "LSM stacking" by some godawful collection of shims.
Someone writes a mindblowingly generic LSM in which everything is possible but nothing is easy. World+dog are happy up until they want to do something that conflicts with their distro defaults, at which point they meet Pain.
End users get stuck with the choice of either putting up with what the "big boys" want to implement in their LSMs, or using a "boutique" LSM that covers a particular case but doesn't really handle general security well enough.

LSM stacking (again)

Posted Jun 28, 2010 5:47 UTC (Mon) by nix (subscriber, #2304) [Link]

And if you like two different tiny LSMs, and they get picked up by different security frameworks (each rejecting the LSM that the other accepted), I guess you can just suffer.

I think I prefer stacking, at least restrictive stacking.