I have a saying, "If it's not DNS, then it's Selinux". It blocks stuff so frequently it's a major time sink for us.

It is overly complex and difficult to understand, especially if you're developing and deploying software that does not have correct pre-rolled policies. A regular job for me is to help developers solve this - which generally means running their service, seeing what Selinux blocks on, and then applying a fix. Repeat 2-8 times until every way Selinux is trying to access a file is explicitly allowed. And sometimes, even software that comes via official repos has buggy selinux policies that break things.

Fortunately, there are tools to help you. Install setroubleshooter amd when something doesn't work, "grep seal /var/log/messages" and if it's selinux causing the problem, you'll find instructions showing you what went wrong and how to create an exception. I absolutely consider this tool essential when using any system with selinux enabled.

Nothing wrong with it

It was built years ago by the NSA but I'm sure that by now any backdoors nwould have been found

Having said that: it could use some rework to become more intuitive, especially with the error messages and how to resolve them

Security is much more effective and adopted when it is simple. My understanding is that SELinux is not.

This means not only will fewer people use it and more people turn it off if something doesn't work, it means more people are at risk of misconfiguring their system to allow something they didn't intend to.

This is somewhat mitigated from the fact that, from my experience, Linux Security Modules cant ever make you less secure than without it. But it still can provide a false sense of security if you misconfigure it.

Here is a good article showing what I am referring to, and providing a solid security tool: BSD pledge/unveil on Linux.

I don't hate it, I know that it adds a lot of security to a system, it's just that it's not user friendly and it can sometimes leave you scratching your head wondering what the hell happened.

It's more work to get things to work. You have to be more explicit as a dev.

Personally I really like it, and wish there was more support for MLS features it has in Userland

I think it depends who you ask.

As a linux admin, I don't mind it and actually really appreciate it. It's a robust system like you said and though a bit persnickety on resolving things, does its job well.

As a home user, I find that mostly you shouldn't know it ever exists anyhow. The one time you might would be podman volume issues (when you forget or don't know to append a z/Z) or when you're doing something odd. I can see how some would dislike it in that case.

But in any case I fully recommend running it and just learning how to use it. Kind of like IPv6. It's misunderstood, too often disabled, and should be more widespread. They both are really improvements to what came before. Just technology that takes a little more time to learn is all.

Here is a helpful video explaining it- https://youtu.be/_WOKRaM-HI4

I'd love to develop a muscle memory for working with it, but nowhere I've worked uses it at all. But from memory it really wasn't that complicated, and the errors it spat out into system logs basically told you exactly what command to run to get past that particular violation.

I don't hate it at all. Just, never seen it used anywhere.

I don't hate it, but as a PC/phone user it's security features are almost never helpful and always cause issues so I just have it disabled.

If you've used something like AppArmor, you'll see how SELinux is overly complex.

Because in even 'permissive' mode, it blocks some fairly routine things.

I don't hate it. What's SELinux?

For many years I installed Fedora from scratch (almost as if my PC was a Linux container and then added a kernel setup) to be exactly as I wanted it no cruft, no bloat. I did that with other distros as well, Debian didn't recommend SELinux.

Last year I installed it from scratch using the installer and that included SELinux. With changes in SELinux policy, I found an installed flatpak which successive iterations didn't like SELinux or tried to operate outside it. Fixing it was easy but I didn't do so until I understood why it was violating.

I had unknowingly subscribed to the FUD about SELinux, I doesn't get in my way. Maybe I'm not as elite as I thought I was!

Generally, we don't. I can count on one hand the number of times I've had to mess with it. Two times I had to use restorecon, and two times I had to loosen permissions for an HTTP server. Literally everything else has worked without issue.

I know some people love to bitch and moan about it, but honestly I have to ask what they're doing, because I've had zero non-trivial problems.

The only thing I know about SELinux is that the NSA made it, and that you need to add :z to docker volumes to fix permissions.

For me it's not so much hate as just not really having experience with it, so most of the time if it causes an issue I either just find a command that sets the policy correctly, or more likely disable it.

I should spend some time figuring it out, but it's just one more seemingly esoteric and arcane system that feels at first like it merely exists to get in my way, like systemd, and I'm left wondering do I really need this headache, and what is it really giving me anyway?

Docker container can't read a bind mount. Permission issue? No, it's SELinux, again. And I didn't even install it explicitly, it just got pulled in by another package.

And to be clear, the issue isn't SELinux really, but ~~unexpected~~ non standard behaviour which I never asked for (never explicitly installed it).

I definitely do not hate SELinux, I think it's a great system. But my experience mostly (at home, anyway) comes from managing servers running Kubernetes clusters and, like, just using podman do deploy containers. In both these cases SELinux is a on "just works" basis, for the most part.

Then in enterprise environment that doesn't run everything on containers, you usually have a very standardized way of applying SELinux policies. At my last place of work we did it via a rather Ansible role. It was simple and easy.

But I can imagine using SELinux at home, where you maybe don't have these things, might be a rather "mysterious" experience. It's not the most obvious system.

But learning to write your own policies (even if just trough se2allow or whatever it's called) does de-mystify SELinix pretty quick.

I only had a problem with it once, but having no experience with it really confused me.

I was mounting a directory to a docker container and i kept getting permission errors. The errors were not descriptive at all and really confused me as i already had sudo privileges and wasn't expecting any problems with permission.

openSUSE tumbleweed changed to using it and I think it works well.

Its just complex.

I hate it for my Android device maintainer role much more than my Linux admin role...

On Android, its a fucking mess between vendor stuff and system stuff. But not for selinux itself, but for the mess that vendors often do.

I think hate is a strong word. It can be a pain when admin'ing machines that get a rule introduced that breaks something that previously worked, but I think most people never even realize it's there.