LSM stacking (again) [LWN.net]

LSM stacking (again)

Posted Jun 24, 2010 4:46 UTC (Thu) by raven667 (subscriber, #5198)
Parent article: LSM stacking (again)

I don't think stacking modules is actually a good idea. It way over complicates practical system security. I also think that the assertion that SELinux isn't used needs some clarification and may be false. As a user and administrator of Linux systems everything has come with selinux on and enforcing for many years now. I have not had a problem with this, the few times I needed to run chcon or change the policy I can count on one hand and have not required more than a few lines generated by audit2allow.

The take-up by individual developers to write policies for their code instead of the distributers and the understanding level of the full policy amongst anyone who isn't responsible for writing policies full time might be low but I don't think that selinux has failed at all in penetrating the marketplace and in being a useful tool that all take advantage of. I think that the set of people that aren't using selinux or another comprehensive LSM module are fairly low. The people who are disabling selinux are just very vocal and uninterested in actually solving their security policy problem, whatever it happens to be.

to post comments

LSM stacking (again)

Posted Jun 24, 2010 7:32 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

note that by 'everything' you must mean redhat/fedora

ubuntu currently ships with apparmor as it's default LSM

that knocks a huge hole through your assertian

LSM stacking (again)

Posted Jun 24, 2010 15:13 UTC (Thu) by raven667 (subscriber, #5198) [Link] (2 responses)

Maybe that was a bit hyperbolic, I didn't mean to suggest that there weren't other competitive security frameworks in production use. What I wanted to point out is that there are many millions of deployed systems with selinux on by default and most people are happy with selinux if they are even aware that it exists. A small, vocal number have trouble and disable it instead of figuring out how to solve their problem but I think that's a small minority and I'm not sure what reasonable change would satisfy them.

LSM stacking (again)

Posted Jun 27, 2010 15:59 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

The millions of deployed systems have people who don't need to touch the SELinux configuration. The people who are dissatisfied with SELinux are those who use it until they have to install something that requires they change the policy; then they look at the hundreds of thousands of lines of policy and say 'life is too short'.

This is even true in areas such as massive stockbroking servers, where they really do care a good bit about security. Not even there do they care enough to make SELinux work with them: what in a simpler system might be a small possibility that a config fixup might break something, in a system of the complexity of shipped SELinux policies becomes a *large* possibility in these people's eyes. So they always turn SELinux off. And I think they're right.

Probably nowhere outside the military would people care enough to fix such problems. Of course, that's where SELinux emerged from: and it's probably a good fit for there.

If we want a security framework we can configure ourselves without driving ourselves insane -- if we occasionally have demands not met by our distributors -- then something simpler, something *comprehensible* is needed.

LSM stacking (again)

Posted Jun 27, 2010 18:00 UTC (Sun) by raven667 (subscriber, #5198) [Link]

I agree, many people run selinux systems without incident and of the few admins who do run into a need to make changes disable it instead. I don't think it is only miliary wonks who can work with it, in my environment I made a concerted effort to just make the appropriate policy changes when the need arrised. I found in my experience that the few changes I needed were not really that hard to make.

A few times I needed to make a local policy to allow an app to make syscalls it otherwise wasn't allowed to do, iterations of audit2allow made short work of it. On another instance I needed to grep through the existing security context list to find a suitable policy as one already existed and I was just a chcon away from my app working. I haven't had problems with third party apps because they tend not to come with policies so just pick up the default.

I don't think selinux is bad but there does not seem to be the amount of shared knowledge and lore that would allow people to eaisly solve problems when they come up. You can find some help via google or serverfault but the quality is sometimes poor and the most common recommendation is to turn selinux off rather than use the tools that come with to actually understand and fix the problem.

LSM stacking (again)

Posted Jun 24, 2010 8:04 UTC (Thu) by mjthayer (guest, #39183) [Link]

My personal problem with SELinux is that it tries to solve all problems with one solution (which seems to rather run against what many would call the "*NIX tradition"). I think that having individual components attacking individual issues that SELinux addresses (off the top of my head, sandboxing and controlled privilege escallation, but I'm definitely no security expert) might have the potential to be a lot simpler.

On the other hand, SELinux is there now, and has the advantage that it is reasonably transparent to the developer, so they don't really need to understand much about how SELinux policy works when they write their application. At the worst, if it is a third-party product, some poor person working on the installer has to worry about that.

LSM stacking (again)

Posted Jun 24, 2010 9:26 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

Stacked security modules are common. Just look at your /etc/pam.d, and it works just fine.

LSM stacking (again)

Posted Jun 24, 2010 14:57 UTC (Thu) by raven667 (subscriber, #5198) [Link] (4 responses)

The difference in complexity is massive though. To be able to effectively stack LSM modules you'd need the equivalent of a Pam config for each hook point. You cant guarantee that a coarser grained policy is going to make sense.

LSM stacking (again)

Posted Jun 24, 2010 15:05 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Why?

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".

LSM stacking (again)

Posted Jun 24, 2010 16:26 UTC (Thu) by bronson (subscriber, #4806) [Link] (2 responses)

So and AppArmor and SELinux and Smack and Tomoyo would need to be written with all possible permutations in mind? That sounds absolutely hellish to analyze and test. Remember, we're talking about security here -- failure is far worse than a kernel panic.

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.

LSM stacking (again)

Posted Jun 24, 2010 16:54 UTC (Thu) by farnz (subscriber, #17727) [Link]

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.

LSM stacking (again)

Posted Jun 24, 2010 17:41 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

"So and AppArmor and SELinux and Smack and Tomoyo would need to be written with all possible permutations in mind?"

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.

LSM stacking (again)

Posted Jun 25, 2010 14:01 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (6 responses)

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.

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.