I don't think I agree. I've been running things with SELinux enabled for more than a decade, haven't really had problems.
The issue with SELinux is that it's security, and security is a complex issue that requires understanding what you're doing and why. It's not a problem domain that's friendly to the approach of poking at random until somehow things start working.
It's not really different from filesystem permissions actually. Why not 'chmod 777 /etc/shadow' to get yourself out of a problem? That question can only be properly answered by knowing what /etc/shadow is for, and why it's a bad thing for everyone to read and write it.
SELinux just forces you to have to understand the system in terms of what operations a program should be able to do on what. Should Apache serve your ssh private key files? Should a random tool be able to listen on port 8080? There's really no instant answers to questions like that. You have to understand what Apache is, what ssh keys are, and who is supposed to access them.
If you have a compromise, you may need to do some forensics and figure out what happened, and that will require answering such questions anyway, at a most inconvenient time. Where did they get in? How did they escalate privileges? How did they get their hands on your data? Is there still a backdoor somewhere on the system? Why is that process listening on that port?
And by the way, audit2allow produces text files, which it proceeds to automatically compile for you. Right next to the binary blob there's a text file with the policy, you can read that.
Ok, let's look into this in more depth.
> At the heart of the problem is that the SELinux policies themselves are sort of magical. The policies have probably been provided by the maintainers of your Linux distribution, e.g., Fedora Linux. There’s nowhere on the system where you can view the policies and look up why something might or might not work.
Yeah there is, you can install the policy's source and look at it all you want. It's complex, granted, but it's very much there.
There's also tooling to examine the current one, like sesearch.
> The SELinux denial audit log messages are too vague. You’re told that a label was denied reading from another label. Okay, what do those labels mean? Which programs? Which files, sockets, or whatever?
You do have that information. It's specified as an inode number for performance reasons, which isn't terribly user friendly. Which is why there's tooling to turn those obscure log entries into something much more readable, such as the mentioned sealert. It's even mentioned in the logs.
> So, you run the audit2allow command as instructed, and end up with some policy blob files.
> God only knows what changes the blobs do; you can’t be expected to, nor are you given enough information to evaluate them.
Wrong, the information is right there in text. audit2allow compiled it into a binary, true. But right next to it you'll find the source, in the .te file. And for most cases, it's a short, quite understandable one.
> Then what do you do? You don’t know what the module did, where it was installed, or how to remove it.
That seems like a problem of not reading the docs. I mean, there's the semodule command for that.
The blog author's problem is that they're trying their best to do the absolutely minimum possible. Which in a way I understand, but doesn't make them informed on the subject matter. It's like writing code by randomly changing stuff without understanding until the compiler finally shuts up. Yeah, sometimes it gets your assignment a bit closer to done, but most of the time the result is crap because randomly messing with stuff isn't a replacement for understanding.
Most of what they complain about have tooling, documentation and solutions. They're just not using them.