Hacker News Reader

Comment by reidrac | Hacker News Reader

You're absolutely right. The problem is that it really doesn't matter if it is amazing an works fine out of the box: people won't use it because SELinux is generally perceived as a technology that is too complicated and will break things if you don't disable it.

At this point, very few people will bother to learn the few bits you need to know to troubleshoot and fix any issues you might encounter; and any benefits you get from using it are not worth the effort.

I used Fedora from 12 to 21 (? I think) and always left SELinux enabled, and it just works. The few things that failed (I remember two issues, one with an experimental build of Chromium and another one with OpenVPN and certificates in $HOME), I submitted a bug report and created my own rule to workaround the issue.

If I managed to run a desktop system with SELinux on, it should be possible (and potentially easier) to use it properly on a server.

View on HN

> people won't use it because SELinux is generally perceived as a technology that is too complicated

It's amazing how bad things have got with the majority of developers and admins that they refuse to learn things that are difficult and instead simply turn it off. It's not like all of them are too young to remember when nothing in their system was easy and they actually had to learn about what they were doing.

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.

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.

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.

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

There is a line between something being difficult and something causing any part of the system to randomly stop working with no explanation whatsoever except -if you're lucky- a single log line somewhere that will give no result when searched for on google.

Well - devs and admins spend the minimum effort required to reach their primary goal. And I believe most of the time that it is in line with their employer's policy.

I'm too young to remember how it was in the old times (would be glad to hear a story or 2), but since my very first job, the internal policy (the real one - not the one presented to customer or auditors) has always been "scew firewall, selinux, principle of least privilege. Disable everything so it works right now and grant the dev team root access to the prod environments - they need it for an urgent customer issue!".

Humans are designed to obtain their goals while conserving as much energy as possible. As a rule, people will always take the lowest-effort route to get what they want. At a macro scale, this can only be counteracted by designing systems that strongly discourage specific low-effort-but-harmful routes, and even then, there will always be some sector of the population that doesn't grok the downside of taking the "easier" way.

I think one of the big things that has impacted SELinux adoption is that everyone has sort of seen it as a proactive booster rather than a really necessary part of a secure environment. I'm sure a lot of that is because lots of people are used to administering systems that were around before SELinux (and similar) was. For something that's perceived as a bonus point, it interferes far too often.

Most people don't realize SELinux is on until it does something really bad like stopping a database from restarting correctly or otherwise harming what's supposed to be a stable environment. When those are the stakes, SELinux does not have, or at least does not make immediately clear, a sufficient value proposition to incentivize the admin to fix the rules rather than just turning the whole thing off.

For example, to contrast with the OP, when SELinux stops Docker from doing something, the impulse is not going to be "Yay, SELinux stopped Docker from doing something dangerous! Thank you glorious SELinux!" Instead, it will be "Ugh, SELinux again getting in the way of stuff. I just need to disable that. I get enough headaches from Docker as-is and SELinux probably just isn't modern enough to handle my uber-charged stack with all of it's new-fangled features. Disabling!"

I agree with your post, except for one point: system design shouldn't be focused on strongly discouraging harmful low effort routes, but on ensuring that the good routes are less effort than the harmful ones. That is, while it can be achieved by raising the effort of the harmful routes, it can also (and might be better) achieved by lowering the effort of the desired routes. For example, if journalctl showed the relevant AVC messages when showing the log of a failing unit, it would remind the administrators they may need to adjust it. (Except actually mention SELinux in the message, nobody knows what AVC is.)

A lot of this seems driven by IT departments cut to the bone or outsourced for minimum bid offshore.

In either case, enterprise IT doesn't have the benefit of spending time fiddling that used to exist.

To be fair, documentation on SELinux sucks. Git is also complex, but there is a lot of good documentation. When I first tried to develop an SELinux policy it took me a month to learn. Too many things are undocumented, or are documented but not clear where.

Selinux creates a lot of extra work for very little visible benefit.

Hopefully posts like this one help make the benefit more visible.

And much of the extra work is one-time work, not ongoing effort.

> that they refuse to learn things that are difficult and instead simply turn it off.

I wish I could do this with our Logstash cluster. It requires so much hand-holding, and troubleshooting can be quite opaque. Last night the logstash indexing service had 'just stopped', and was sending 57000-character-long json loglines into its own log.

And if they do fix a bug, you can't just upgrade one component, you have to upgrade logstash and elasticsearch and kibana... and maybe whichever beats you're using.

"I used Fedora from 12 to 21 (? I think) and always left SELinux enabled, and it just works."

I've had all sorts of weird errors over the years when I set up new CentOS machines.. one thing or the other. And then I remember to turn off SELinux, and it suddenly works. Over and over again.

It's going to take a lot of convincing to get me to leave SELinux on when it's caused so many problems over the years.

Did you consult the audit.log? Did you pump it through audit2allow? The audit2allow tool will even tell you if the issue can be fixed by setting a boolean on the SELinux config. Most of the stuff I have run into recently can be fixed by setting a boolean.

Yeah, SELinux does require learning it, but it adds a lot. I recently helped a friend of mine fix his PHP CMS because it was hacked. The PHP was high jacked and it started attacking other instances in hosting providers network. If only he had not turned off SELinux, it would have prevented outgoing connections from the http server.

Reply on news.ycombinator.com