LSM stacking (again)
Posted Jun 24, 2010 14:57 UTC (Thu) by raven667 (subscriber, #5198)
Posted Jun 24, 2010 15:05 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
I see that we can broadly divide LSM hooks into: filesystem, network, CPU resources, misc.
So we can specify: "First use AppArmor to check filesystem access, but use SeLinux to check security labels on network packets".
Posted Jun 24, 2010 16:26 UTC (Thu) by bronson (subscriber, #4806)
Maybe it would be possible if all projects split their code into completely isolated modules: AppArmor-Network, AppArmor-Filesystem, etc. No interaction allowed between the Network and Filesystem modules. But I don't think that would meet SELinux's needs.
Posted Jun 24, 2010 16:54 UTC (Thu) by farnz (subscriber, #17727)
A safer variation on the same theme would be to write the stacking such that each LSM only gets to check accesses that other loaded LSMs have permitted; for example "check everything with AppArmor. If AppArmor permits it, fall through to SELinux. If SELinux permits it, fall through to Yama."
If you then want to have AppArmor handle all the filesystem stuff, while SELinux only deals with networking, you have to design your AppArmor and SELinux policies to do this, and you've hopefully thought about the failure modes of doing so. If Clueless CrazyAdmin uses off-the-shelf SELinux and AppArmor policies, they get only the accesses that both LSMs believe are safe.
In practice, such a stacking method makes stacking full-fledged security modules like SELinux and Smack together rather pointless; where you benefit is with "boutique" LSMs like Yama, which aim to prevent a limited set of security flaws - you can stack Yama and SELinux, and get Yama covering everything, while SELinux only protects that part of the system that you've written policy for.
Posted Jun 24, 2010 17:41 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
Why would AppArmor need to know anything about SELinux?
A special stacking-driver should think like: "Oh, we have a file request. Let's see: - we need to pass it to AppArmor first. Done, result is OK. Then we need to pass it to Yama, result is OK. So we can perform the action".
At no point AppArmor needs to know that after it returns 'OK' further checks will be carried out.
"That sounds absolutely hellish to analyze and test. Remember, we're talking about security here -- failure is far worse than a kernel panic."
Whose who need NSA certification can go and make love with SELinux.
Posted Jun 25, 2010 14:01 UTC (Fri) by tialaramex (subscriber, #21167)
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.
Posted Jun 25, 2010 14:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
Posted Jun 28, 2010 1:54 UTC (Mon) by raven667 (subscriber, #5198)
Posted Jun 28, 2010 2:16 UTC (Mon) by dlang (subscriber, #313)
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
Posted Jun 28, 2010 4:36 UTC (Mon) by raven667 (subscriber, #5198)
Posted Jun 29, 2010 12:54 UTC (Tue) by mpr22 (subscriber, #60784)
My perspective is that we're in a "pick one" scenario, with the options being roughly:
Posted Jun 28, 2010 5:47 UTC (Mon) by nix (subscriber, #2304)
I think I prefer stacking, at least restrictive stacking.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds