3 ms·

I'm looking at disabling selinux on some of the systems I work on. But I don't think it's for a lack of trying to use and understand it. I don't think it's just

I'm looking at disabling selinux on some of the systems I work on. But I don't think it's for a lack of trying to use and understand it. I don't think it's just a matter of being complicated, to me I find the system cryptic, and information about how to do things correctly very difficult to find information for. While I agree with your sentiment, I think I have tried to give selinux a fair chance, but I've reached the point where it seems to add more overhead than it benefits us. This is combined with, I'm also likely making mistakes with my configuration, that make it too permissive, because with my limited understanding, I'm putting together modules that make my stuff work, but I don't actually understand the implications of some of the decisions I'm making for permissions. And my entire team seems to be struggling with selinux, and a little bit fed up with it, because we keep running into it blocking things, simple things, against our intuitions of the way our system and selinux should work. It might be the perfect access control system, but to me UX is horrible. Or maybe I just hate to admit it, but I've utterly failed at building a mental model for how it works, and how I can effectively interact with it to do what I need to do. So while you might be right, at least in the case of selinux, I'm not sure I agree that it's simply a matter of developers and admins refusing to learn things that are difficult. In the selinux case, I think it goes deeper, where it creates a cognitive load, that someone needs to invest a significant amount of effort to truly learn it.

deleted 10y ago
[deleted]
hoistbypetard 10y ago
> it creates a cognitive load, that someone needs to invest a significant amount of effort to truly learn it. To benefit from SELinux, I don't think you need to "truly learn" it... but you do need to invest some effort developing troubleshooting skills that are specific to SELinux. But the thrust of your point is right. We need to invest some effort to benefit from it. I think postings like RedHat's are useful because they show us in a concrete way why it might be worth the small effort to develop the troubleshooting skills, or even worth the large effort to really understand SELinux.
viraptor 10y ago
Just an agreement. I make a point of using some LSM everywhere I can, but in practice selinux is still hard to debug properly. The level of abstraction in module doesn't help here. System-wide integration means that patching single app profile sometimes involves patching the system profile package, sometimes just one module. And that's just on redhat-like system - anything else gives no guarantees about selinux working at all. Sure, apparmor has fewer options, but it's trivial to manage a profile along with the package itself. The learning and reporting system is much simpler. And there's no need for debugging the "where did I miss the context setting this time" problem in deployment. I can deal with both and either one is needed. But selinux simply wastes my time way too often.
mook 10y ago
I agree that the UX is bad, and I think that's because they were wearing heavily SELinux-tinted glasses when they designed it. As an example, even if you correctly expanded `chcon` to "change context" the name of the command itself tells you nothing about it being SELinux related. In contrast, `aa-enforce` and friends hint that they're all AppArmor commands. (This is more useful when trying to remember the name of the command you typed a few months ago.) This is of course difficult to get right - one would need to be aware of what everything does detail, but still know what it would be like to use it with no prior knowledge.

deleted 10y ago

[deleted]

hoistbypetard 10y ago

> it creates a cognitive load, that someone needs to invest a significant amount of effort to truly learn it. To benefit from SELinux, I don't think you need to "truly learn" it... but you do need to invest some effort developing troubleshooting skills that are specific to SELinux. But the thrust of your point is right. We need to invest some effort to benefit from it. I think postings like RedHat's are useful because they show us in a concrete way why it might be worth the small effort to develop the troubleshooting skills, or even worth the large effort to really understand SELinux.

viraptor 10y ago

Just an agreement. I make a point of using some LSM everywhere I can, but in practice selinux is still hard to debug properly. The level of abstraction in module doesn't help here. System-wide integration means that patching single app profile sometimes involves patching the system profile package, sometimes just one module. And that's just on redhat-like system - anything else gives no guarantees about selinux working at all. Sure, apparmor has fewer options, but it's trivial to manage a profile along with the package itself. The learning and reporting system is much simpler. And there's no need for debugging the "where did I miss the context setting this time" problem in deployment. I can deal with both and either one is needed. But selinux simply wastes my time way too often.

mook 10y ago

I agree that the UX is bad, and I think that's because they were wearing heavily SELinux-tinted glasses when they designed it. As an example, even if you correctly expanded `chcon` to "change context" the name of the command itself tells you nothing about it being SELinux related. In contrast, `aa-enforce` and friends hint that they're all AppArmor commands. (This is more useful when trying to remember the name of the command you typed a few months ago.) This is of course difficult to get right - one would need to be aware of what everything does detail, but still know what it would be like to use it with no prior knowledge.