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

Be civil and read the entire article first. This is not a support forum. Comments from new contributors are moderated. English only.

Leave a comment

Required. Optional. E.g. your homepage, Twitter. or Email required unless anonymous. Not published or shared. Reuse to be recognized as the same commenter.
Plain-text only. Begin lines with a > character to quote.

Anonymous

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

Anonymous

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.

Glen

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.

Noah K

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!

Simon García

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.

DontTalk

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*

DontTalk

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.

Anonymous

> 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

phocean

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.

Bruce

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

Anonymous

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

Liam

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.

remyabel

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.

Anonymous

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

Mace Moneta

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

Anonymous

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.

DKF

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

Anonymous

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?

woo

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.

Discussions also happens elsewhere! Read and participate in 3 external discussions (506 comments).