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

It either works for you with whatever defaults the distro comes, you have the CV-worthy, professional skill of grogging it or you are completely lost and nobody can fault you for disabling it. Horrible user experience.

That said, here are the spells to fix fedora 36:

# disable it

sudo setenforce 0

# kill bugged modules

sudo semodule -X 200 -r snappy -r container -r flatpak -X 400 -r pcpupstream -r pcpupstream-container -X 100 -r pcp

# reinstall them

sudo dnf reinstall selinux-policy

sudo dnf reinstall \*-selinux

# reenable it

sudo setenforce 1

I had that login bug two years ago. First time I ever encountered SELinux was after it locked me out of my laptop. Gnome just dropped me back on the login screen after logging in. Took forever to troubleshoot. I still don't know what I did to anger the policy Gods.

Your title is clickbaity! 😒 but ... it's probably the right title for the article. I agree with you. SELinux isn't user friendly. It's so user unfriendly it's not even funny!

I never thought about not knowing what the policies are but you're right. I don't know the policies! Hacker News (idiots) suggest reading the source code but that's a poor excuse for the lack of documentation.

I had a terrible time getting Apache to talk with php-fpm. It's not a super uncommon setup but SELinux kept getting in my way. Dozens of 10-year-old posts listed incantations, as you call them, but no one explained what was going on or how to inspect the policies. I just want a config file! The denial logs were detailed but unintelligible. I don't need to know the inode number, I need the file path!

I know the fundamentals of SELinux. Tons of good explanations. But I don't know the tools or what the policies on my system are. No one has explained what the default policies are or how to adjust them. There's no documentation! I just have to abide by some rules without knowing what they are. It's an insane setup now that I reflect on it.

I installed the Fedora 36 beta yesterday on a clean system. I've been looking at a steady stream of "New SELinux Security alert" notifications since the second time I booted the system. I've not investigated it yet but it looks like there's some 90 000 log messages in a few hours. *sigh*

You're not being completely fair on SELinux but I think that might be on purpose to drive home your point. You seem to know how it works but discuss it from the perspective of someone with less knowledge?

If I'm not mistaken, your point is that the documentation absolutely suck! The selinux manpage says it was updated in 2005! Fedora has no current documentation other than the policy package source code.

I've run Fedora on my laptop and home server for years. SELinux is enforcing but I don't know what's it enforcing. I've never thought about it, but yes, there must be some default policies somewhere. Google doesn't seem to know anything about it. All I find are explanation about the basics just like you first paragraphs.

> 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

This is completely untrue, just go and read: https://github.com/fedora-selinux/selinux-policy

Very nice article and perfect argumentation, I totally agree with you.

That's why I much prefer "apparmor", if I have to make a choice. Not perfect, maybe less robust, but at least it's much more comprehensive and easier to configure.

A better MAC has yet to be designed, however...

SELinux is complex, I give you that. But saying that it is not worth a week of study actually reflects the existing problem of "I don't find it in StackOverflow, I'm doomed'.

SELinux provides several tools to dig into the policy. It's true, there aren't plain text files, but the policy can be converted into something legible. Tools like seinfo or sesearch are designed to dump the content into a format that can be filtered, understood, and eventually manipulated either with semanage or by creating your own policy. Tools like ausearch can also help in debugging issues - I know, another service (auditd) to learn.

Understanding the difference between chcon and restorecon might save you from problems in the future. And if you are in a rush, you always have the possibility of stopping enforcing a whole domain (httpd_t in your case).

Don't underestimate the value of understanding a topic rather than applying random commands you find online. Especially when the security of your environment depends on it.

There's a coloring book (aka ELI5) on how it all works. Telling people to just disable SELinux is irresponsible at best. I suppose if it's just your laptop, that's one thing. But a public-facing server should have all security features enabled, given the rate of zero-day exploits being found/announced/exploited. SELinux can give a big assist in helping to block a lot of exploit paths.

https://people.redhat.com/duffy/selinux/selinux-coloring-book_A4-Stapled.pdf

Hey there, fulltime linux-sysadmin here. this is soooo much true. thanks for sharing your thoughts.

reading this makes it clear that if you're in infosec or a system engineer position, your management should reconsider your employment. even the smoothest of brains could manage selinux; your arguments have no weight.

the default policies in Fedora and EL systems generally just work. if people are trying to do things outside the norm, they deserve to be punished by the security of the system. I stand by this.

and no, containers are not better than selinux. it has been proven a million times over and over that there are vulnerabilities, a lot of them unfixed, in container technology. and I know this is hard to believe, but selinux does mitigate container security holes. as an aside... containers wouldn't be anything without seccomp. also the same argument that selinux is too complicated can be used for containers. don't blame the tools for your inability to learn something, let alone the inability to read. blame yourself.

to some of the commenters, there has been plenty of documentation on selinux. man pages are a starting point, but not the end. and the same could be said about other things.

I have to say that I strongly disagree with the arguments made and the advice. Disabling SELinux is a terrible idea, it will increase the attack surface of your system by magnitudes. I'll be addressing arguments made (paraphrased, not direct quotes).

A) "SELinux documentation is too complicated and geared towards policy makers, not end users"

This is because the documentation's target demographic are system administrators using the tools to write policies. This is like complaining that a carpenter handbook aimed at professionals is too complicated for end users. You want to be looking at either the documentation for the software (Docker for example tells you how to get around permission errors with mount, or setting the appropriate bool for httpd servers) or reading the error message that tells you exactly what to do (run audit2why, file a bug report so the distro maintainers can take a look at it).

B) "You should disable SELinux"

Would you disable your home security system because it's too complicated to figure out? If there is a genuine bug in the policy, then it should be reported, not disable the entire thing.

C) "Start from a clean slate and write your own policies"

The policies are written by those who are intimately familiar with SELinux and how it operates within the context of the distro. Again as said earlier, if there's an issue, report it upstream. Trying to write your own policies, especially if you're unfamiliar with SELinux, will result in an insecure application/system. Most errors are easily solved by google or running the appropriate command.

D) "It's too complicated for end users; use Docker instead"

I see this argument a lot, but it makes no sense within the context of IT. The end user and system admin are two different groups of people. Why does it matter if it's too complicated for end users when the audience are other IT professionals? Docker also is NOT a replacement for SELinux. Docker is secured BY seccomp profiles, by itself it is actually significantly more insecure than people think. This shows a fundamental misunderstanding of the threat model of containers and what benefits SELinux provides.

Most comments on HN agrees with you. The few that don't have 10+ years of experience managing RHEl. A couple of people tell you to read the f*ing manual (but I haven't found it and they don't include any links).

I think I'm in the same boat as you. I know the fundamentals about how SELinux works but I also don't know how to lookup the active policies or manage the system. The management programs "do stuff" but I don't know what changes they do to my system

I was an early adopter of Fedora's SELinux implementation. I learned all about it. Checked each policy error. Tweaked policies as needed, for about 9 years. Then I realized that not one of the issues was security related, just packaging and policies that SELinux needed to know about. That told me that my existing security practices were good enough; SELinux wasn't buying me anything. Since about 2014, I've been running with SELinux disabled (not permissive).

Read the logs it tells you exactly what the corrective action is. It s not nearly as difficult as you make it out to be.

Does a comprehensive front end UI need to be written to make it manageable?

SELinux for mere mortals was all I ever needed, check it out on youtube

DKF: a front end or much better documentation. I need somewhere or something that can turn a path, context/label, or module into a list of what other stuff it can interact with. How do I go from a binary to seeing what it’s allowed to do? Or from a regular file and seeing what programs can interact with it?

There are currently eight videos on YouTube titled “SELinux for mere mortals”. Which one did you mean?

Thank you :)

This is why I've disabled SELinux for the past 16 years.

And never had an issue... it's simply an unmanageable mess.

This guide is useful for dealing with the silent errors when SELinux doesn't log anything to the audit log.

https://ahelpme.com/linux/selinux/selinux-permission-denied-and-no-log-in-audit-log/

It's an absolutely stupid system.

I've just wasted three hours on resolving an SELinux denial that wasn't logged. The crappy logging just makes it a hundred times more frustrating. It's a contractual requirement to have it enabled in our environment. However, it gives us so much grief constantly! We've got an internal wiki with the commands and troubleshooting steps but the faults are always incredibly subtle and difficult to diagnose. I really wish I could turn off the entire damned thing!

Funny, just my thoughts.

Just did a yum update on a rhel 7.9 system. Everything smooth. Then after boot freezes because not being able to load a policy. Forcing permissive mode, goes further and keeps looping in starting and crashing login service.

Now, forums and stuff... al kinds of tips and commands. Do an autorelabel. Does not work. fixfiles onboot ... isn't that just autrelabel? Well, whi knows, so did that. Made no doffewrence.

Al inds of other stuff ... does not work because selinux is OFF. But I can't turn it on because then I cannot enter my system.

F**k selinux.

Funny :).

I'm not a sysadmin, just an old computer user. I started before Linux existed. At that time I remember there was ms dos and later Windows on home computer. Sometimes (often?) Windows would crash with some cryptic message telling that the crash was due to -complicated stuff in hex. Nobody read it. You just power off power on. Your selinux logs reminds me of this.

Later internet connection became common and every user started to have personal firewall. I put some on my friends and family and I noticed it didn't work. Reason? Either the firewall keep asking for every single move "do you want to allow this?" and the user would say "yes" all the time since they didn't know what to answer (therefore the firewall was of no use). Or they would say no or the firewall would not ask and I was called by family and friend because "the firewall you put broke my internet!". :D The firewall was not conceived with the end user in mind.

Seems SELinux is a bit like those old days firewall.

It's probably great stuff, but the people who conceived it forgot the end user had not a free full year, not often even a free week to learn how it works.

I know we are in a gnu system and all the great philosophy but when I read people writing "just read the source code and you'll understand everything", well, that is unrealistic. That would (may?) be a great thing to do but my boss will never understand that I tell him "sorry, I need one year to learn the subtleties of selinux, won't be available for anything else". From my boss point of view, every second I spent doing anything else from my work, such as learning new things, is lost money. I know, he's wrong, but all the boss I've met are quite like him. In fact, I was once fired in one of my first job when I took the time to try to read the source code to understand why the software was not working: to long to solve the problem, Boss said.

I've read comments saying selinux is the only safe stuff.

Well, if so, it's a very sad thing the creator of selinux took so much time creating a perfect system but not making it easy to use. Because the only situation I may be able to convince my boss I need time to learn the full stuff is if we had critical nuclear bomb like stuff to protect. Even then, I'm not sure he would accept.

To summarize: don't forget the end user when you conceive software that is supposed to be use in real life situation. And don't forget the human parameter when creating safety stuff.

PS: sorry for broken English, not my native language.

I have to disagree with "There are very few good documentation sources available that describe SELinux and how to manage it."

How can you say that? There is so much online for SELinux: docs, guides, books, forums, SuSE docs, RHEL docs, YouTube and last but not least, Dan Walsh.

As someone that spend well over a week trying to get my head around SElinux, I ended up with even more questions, and less understanding, there IS a way to disable selinux for a speciflc program / label whatever, but I cant find even a whisper of how to do it online anymore.

I run permissive and know that one day, ill have to re learn it and hopefully grasp it better.

Just like LDAP, if youre fine with having a vague understanding of how it works, and not knowing what to do when it breaks, then crack on.