Hacker News new | ask | show | jobs
by giancarlostoro 649 days ago
This reminds me of my college years and the one time we used Fedora and someone accidentally set it up with SELinux, we spent hours pulling our hairs out trying to figure out why nothing worked. Only to finally realize SELinux was the culprit and we needed to turn it off.
3 comments

SELinux has been enabled on Fedora for as long as I remember.

SELinux is complex, badly documented, policy code is obscure macro incantation, and basic debugging tools often aren't installed out of the box on server distros (such as audit2allow). But for the day to day administration of systems, policies are included for distribution packages and most issues can be fixed by enabling a boolean here and there, and relabeling files.

The principles, basic admin & debugging part can be learned in a couple of hours, and when you have custom service software, you can throw it in /opt and have it run unconfined (ie: not subject to SELinux rules).

"The principles, basic admin & debugging part can be learned in a couple of hours,"

In principle, yes. In reality I've gone looking for a resource that I could do this with and come up short.

(I am starting to get really annoyed at things where I can find a million "paste this bit to do that thing" and there are so darned many of those on the internet that any hope of finding a good resource that gets to the underlying structure such that I can figure out how to do these things myself is virtually nil. It seems like this is getting worse as the search engines continue their trend of taking your query as a vague suggestion of the sort of thing you're looking for.)

Maybe I'll write that guide, and then (fingers crossed) people will find it via search engines (before all search engines become just an LLM frontend).
Well, if you do, my email is in my profile and I'll be happy to be an advance proofreader if you're interested. I've got a couple of teens in a very similar position as well, so I can even provide multiple people's point of view. I have pretty much the exact right amount of experience for that; I've been in there, I've done things, even completed a couple of non-trivial projects (nothing amazing, but, more than just "a pad with a pocket in it"), I recognize I'm confused, I don't know where to proceed from there.
Scratch this, this was in error. It referred to a version of the post I never posted and I got myself confused.
I mentioned elsewhere in the thread, I (well, my employer) picked up a copy of a book on SELinux System Administration (that's the title) and it has served just this function for me.

It won't make you an expert but it takes the voodoo out of the whole process, if that makes sense. And it is reasonably short if you skip the stuff that you're (probably) never going to configure like passing labelled traffic between hosts with IPSEC.

It's baffling to me that SELinux's UI is like...the best we can apparently do?

The underlying concepts of SELinux aren't so hard but trying to manage it in any sort of coherent way is a nightmare - up to and including the provisions in it for a network based policy server component which just never appeared.

And it sucks! In theory it does so many things we really really want, and should do more. Like I as a user have a great interest in ensuring my home directory files follow sensible markings based on their content - my SSH keys, AWS keys, or banking files all exist in different logical zones of control.

And this is a concept SELinux can handle...but the tools are just so bad at surfacing it.

It's not. The (undocumented!) SBPL that Apple OS' use is easier to understand and debug than selinux, in my experience.
Reminds me of git itself, you read about its internals it sounds easy. You start trying to figure out how to map commands in a way that makes sense, it baffles you when things break.
Why would the NSA want to make something easy to use for others?
Why wouldn't they?
Because that's not their job. The NSA sponsored the development of SELinux because they needed something to solve their problems. The current state of SELinux does that. Why would they spend resources solving problems that they don't have.
Kind of a weird counter-question? Why would any business spend more effort on building a tool than is necessary to make the tool they need? The NSA doesn't care about brownie points.
I haven’t touched SELinux. How does it compare to Systemd (presently my standard for “ubiquitous despite terrible UX”).
Disabling SELinux is pretty much like doing a chmod -R 777 ., it may fix your "problem", but it's certainly not the long term solution.
I wouldn't say it's that drastic. Also, SELinux can give you a false sense of security. It's best to harden the system overall instead of relying on one security feature (however good it might be).
Yes, and SELinux is by far the most powerful tool that exists for hardening your system overall. Why would you skip it?
This has worked for me in the past, but it's not something anyone should do in production. ;)

Then again, Disabling SELinux is necessary. For example, cPanel requires disabling SELinux on CentOS, AlmaLinux OS, CloudLinux, and Rocky Linux. AppArmor is fine on Ubuntu (https://docs.cpanel.net/installation-guide/system-requiremen...).

It's not necessary, it's a stupid dick move. cPanel was just not capable to tune the selinux profiles for their services, I've worked there.

My servers all run with selinux, it's really trivial. Just the ssh client and tailscale recipes are missing by default. Selinux gives you precise choices if something is rejected.

I've had no issues for personal use. Be it Fedora or Fedora Server. When I ran into issues the logs often come with a solution.