User: Password:
Subscribe / Log in / New account

LSM stacking (again)

LSM stacking (again)

Posted Jun 27, 2010 15:59 UTC (Sun) by nix (subscriber, #2304)
In reply to: LSM stacking (again) by raven667
Parent article: LSM stacking (again)

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.

(Log in to post comments)

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.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds