this post was submitted on 25 Mar 2025
63 points (90.9% liked)
Linux
52353 readers
1009 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I have a saying, "If it's not DNS, then it's Selinux". It blocks stuff so frequently it's a major time sink for us.
It is overly complex and difficult to understand, especially if you're developing and deploying software that does not have correct pre-rolled policies. A regular job for me is to help developers solve this - which generally means running their service, seeing what Selinux blocks on, and then applying a fix. Repeat 2-8 times until every way Selinux is trying to access a file is explicitly allowed. And sometimes, even software that comes via official repos has buggy selinux policies that break things.
Fortunately, there are tools to help you. Install setroubleshooter amd when something doesn't work, "grep seal /var/log/messages" and if it's selinux causing the problem, you'll find instructions showing you what went wrong and how to create an exception. I absolutely consider this tool essential when using any system with selinux enabled.
Exactly. I use setroubleshoot myself and it's awesome.
I agree that creating custom policies for a bunch of apps day in day out will be tiring. But that is an argument against all MAC. I personally don't want to see Linux going the way of abandoning MAC
How do you know when you're letting through a valid access, an unnecessary one that could be a vulnerability, and an actively malicious one?
I don't think anyone is saying throw out all access control, they're just saying SELinux adds too much unproductive friction for everyday usage. You said it takes 15m to troubleshoot. But that's not a one time thing, that's 15m that scales with the amount of new programs and updates you're running. And 90% of people aren't even going to be able to tell they're looking at a malicious access if they're in the habit of always working around blocks that show up.
I think you make a good point, but it's one that affects any anti-malicious protection. How do you know that the anti-virus warning you get on Windows is legitimate and not a false alert? Or that the Apparmor block wasn't a misfire? Selinux is no better nor worse in principle than those.
In all cases, you need to stop and figure out what's actually going on. That's one benefit of all these things - they make you pause and, hopefully, think, when something is outside the norm.
And yep, they can be bypassed and they need to be able to be bypassed. If someone is lazy or not knowledgeable enough to make the right decision, or even just in a hurry, then they are at risk. No automated system can protect entirely against that.
I would go a step further and say that any time one of these MAC systems has to resort to user interaction to do its job, it's a straight up failure case: the system simply didn't have enough information to do its job, ended up doing no better than a blanket "block everything" config, and is asking the user to do 100% of the heavy lifting of determining what should happen.
So, when I hear
I hear: "every access control system is fundamentally broken". Which is fine, maybe that's true, there's a reason social engineering is so useful. So then all these systems should prioritize streamlining that failure case as much as possible: Tell the user what is accessing what, when, how, and then make it trivial to temporarily (with well defined limits), permanently, (or even volatile-y using CoW/containerization/overlay fs) grant or deny access as quickly and easily as possible.
Every other system you're comparing SELinux, AFAIK, handles this case better, which is why users tend to prefer them.
For the record, I'm not arguing that SELinux is bad at the actual access control part, I'm only answering why people don't like using it, which is how it handles the failure case part. Now it's been a while since I've used SELinux and I've never used setroubleshooter, but if you tell me it actually streamlines all of this to be smoother than every other tool, then I'll install it tonight!
Is it not possible to run it in audit mode in dev and have it tell you what the would have blocked?
Permissive mode, and yes, you absolutely can. That shows warnings but doesn't actively block. But you still benefit from running setroubleshoot to actually figure out what and why it's blocked something, and how to mitigate that.
Permissive is also good in that you can get a bunch of blocks reported at once, instead of having to step through one at a time, which can be useful.
That's what I was thinking, I know the pain of watching something run for ages, only to finally get past where it failed last time and run straight in to another stumbling block.
I don't envy you having to work in an SELinux environment with less than stellar developer understanding of policies and contexts.
Thanks for the tip! Never heard of setroubleshooter tbh.