SELinux is unmanageable; just turn it off if it gets in your way

Take for instance something like xscreensaver. Something in there needs to be setuid so that it can verify your password to unlock the screen. That something is fortunately a dedicated binary, and not every single screensaver, but still, that's bad. Writing that executable is a delicate thing. Get one of them wrong, and it's a glaring hole.

And /usr/libexec/xscreensaver/xscreensaver-auth is quite the thing. It links to a whole bunch of graphical libraries and talks to X11 to read your password, so that thing has a huge potential attack surface. Far more than seems comfortable.

What we should have instead is some sort of authentication service. A program confined by SELinux to only interact with a socket and the password database, speaking a simple but well designed protocol.

With that in place we'd have much simpler security. Policies get simpler because random stuff doesn't link to PAM anymore, and so doesn't end up touching a whole bunch of critical security related files. There's one thing on the system that deals with that, and it ends up with a small, understandable policy.

And the policy for the users is now expressed in terms of "Do we want this program to be able to validate user passwords?", which is also far simpler.

With that kind of redesign over time we could have much smaller and more understandable policies, and a more secure system as a result.

Redhat has co-opted and has become an IBM of consulting firm: use obscured notation of an error code as a corporate revenue flow.

This is not a knock against SELinux nor against the inventor (NSA) thereof.

SELinux is a great privilege boundary setter at an extreme granulated level. SELinux is superior over many other system audit approaches in all area but one: that one is ease of use.

Another fault is that the Buy-ins of SELinux was placed upon the group of distro/package maintainers instead of upon the developer.

Another aspect on the ease of use is that There are no auto generation of SELinux policy given one executable file. No tools have attempted to adequately scan the code or object files for such its needed audit policy file. But this mapping of code to resource is often a skimped step of software development.

Unlike the development of apps for a GUI/WindowsManager environment, SELinux is NOT mandated by its own library to say “thou shall use all of me” or you don’t get go to heaven (or be seen on the computer).

What a great time to be a Linux system administrator.

Of course, horses for courses. That's always implied, and I always keep that in mind.

However, if there's a case which needs that level of security, telling "Nah, just disable it, we'll do containers instead" is wrong at best, very dangerous at worst.

Also, I find having a background knowledge about these technologies beneficial. Having more tools under one's belt is never a disadvantage. It'll give you abilities in the best case, and provide you perspective in the worst.

I've never had a job that would allow me to take a week to solve a production issue.