This is not a troll post. I’m genuinely confused as to why SELinux gets so much of hate. I have to say, I feel that it’s a fairly robust system. The times when I had issues with it, I created a custom policy in the relevant directory and things were fixed. Maybe a couple of modules here and there at the most. It took me about 15 minutes max to figure out what permissions were being blocked and copy the commands from. Red Hat’s guide.
So yeah, why do we hate SELinux?
You must log in or register to comment.
The only thing I know about SELinux is that the NSA made it, and that you need to add :z to docker volumes to fix permissions.
setenforce 0is much cleaner, I have found.They my go to to quickly triage a problem being caused by SEL or not.
A mandatory part at the beginning of every Ansible playbook!
openSUSE tumbleweed changed to using it and I think it works well.
SELinux is complex
MAC is generally more complex than simple Unix permissions. Whether SELinux is more complex than AppArmour is more up to preference in my opinion
I don’t hate it, I know that it adds a lot of security to a system, it’s just that it’s not user friendly and it can sometimes leave you scratching your head wondering what the hell happened.
To be honest I had the exact same situation with AppArmor, and since then I have grown to like MAC. I know they’re doing it to keep me safe so I don’t complain. Honestly if people find MAC to be a hassle they should also in theory find file permissions and ACLs a hassle
Oh the people who dislike MAC probably do dislike file permissions too, ha.
chmod -R 777 somedirand such.
I definitely do not hate SELinux, I think it’s a great system. But my experience mostly (at home, anyway) comes from managing servers running Kubernetes clusters and, like, just using podman do deploy containers. In both these cases SELinux is a on “just works” basis, for the most part.
Then in enterprise environment that doesn’t run everything on containers, you usually have a very standardized way of applying SELinux policies. At my last place of work we did it via a rather Ansible role. It was simple and easy.
But I can imagine using SELinux at home, where you maybe don’t have these things, might be a rather “mysterious” experience. It’s not the most obvious system.
But learning to write your own policies (even if just trough se2allow or whatever it’s called) does de-mystify SELinix pretty quick.
Its just complex.
I hate it for my Android device maintainer role much more than my Linux admin role…
On Android, its a fucking mess between vendor stuff and system stuff. But not for selinux itself, but for the mess that vendors often do.
Yeah I think it’s a much bigger pain on Android
Its just complex
When a security mechanism becomes more complex to manage than what it is supposed to protect, it becomes a vulnerability itself.
If you had a minimal system that you built from the ground up yourself and wanted to only have that system function in very specific ways, SELinux would be perfect. I would go so far as to say it would be nearing perfection in some ways.
Sorry, but in the real world, ain’t nobody got time for that shit. If you use auto configuration tools or pre-canned configs for SELinux on a system you are unfamiliar with, it’s more likely to cause application issues, create security gaps and will likely be shut off by a Jr. admin who really has no fucking clue what he is doing anyway.
It’s just easier to keep your system patched and ensure basic network security practices anyway.
It’s not impossible to manage these days. In the early days it was, but most everything is automagic now. If I am not mistaken, SELinux can be enabled to ‘log only’ which would give you data better handled by a HIPS anyway. (Don’t quote me on that.)
I fully agree with you…
Sorry if it sounded like my rant was directed at you as it absolutely wasn’t. Your comment triggered me, because I absolutely fully agreed with yours as well. ;)
For many years I installed Fedora from scratch (almost as if my PC was a Linux container and then added a kernel setup) to be exactly as I wanted it no cruft, no bloat. I did that with other distros as well, Debian didn’t recommend SELinux.
Last year I installed it from scratch using the installer and that included SELinux. With changes in SELinux policy, I found an installed flatpak which successive iterations didn’t like SELinux or tried to operate outside it. Fixing it was easy but I didn’t do so until I understood why it was violating.
I had unknowingly subscribed to the FUD about SELinux, I doesn’t get in my way. Maybe I’m not as elite as I thought I was!
I think hate is a strong word. It can be a pain when admin’ing machines that get a rule introduced that breaks something that previously worked, but I think most people never even realize it’s there.
If you’ve used something like AppArmor, you’ll see how SELinux is overly complex.
I have and I’ve been left scratching my head both times. AppArmour just deals with files whilst SELinux has contexts - that’s the only operational difference I’ve needed to notice. I create custom policies and am on my way.
Because in even ‘permissive’ mode, it blocks some fairly routine things.
It’s more work to get things to work. You have to be more explicit as a dev.
Personally I really like it, and wish there was more support for MLS features it has in Userland
For me it’s not so much hate as just not really having experience with it, so most of the time if it causes an issue I either just find a command that sets the policy correctly, or more likely disable it.
I should spend some time figuring it out, but it’s just one more seemingly esoteric and arcane system that feels at first like it merely exists to get in my way, like systemd, and I’m left wondering do I really need this headache, and what is it really giving me anyway?
Do you feel that way about all MAC or just SELinux? AppArmour is similarly arcane when you’re in the zone configuring your application. TBH RedHat has troubleshooting instructions in their docs, I just Copts paste and edit as necessary and it doesn’t take that long. I guess I just spent more time at it
The only real permissions systems I’m familiar with are the basic octal permissions in *NIX and NTFS permissions. I know those aren’t really quite the same but they’re the closest I have actual experience with to be able to have an opinion about.
At one point I also knew a little iptables but that was over fifteen years ago now.
As said, I really should spend some time with them, I just need the motivation.
ACLs are pretty good and have come in handy for me multiple times
ACLs are literally what makes up NTFS permissions, too, they just aren’t as clear about it
I think it depends who you ask.
As a linux admin, I don’t mind it and actually really appreciate it. It’s a robust system like you said and though a bit persnickety on resolving things, does its job well.
As a home user, I find that mostly you shouldn’t know it ever exists anyhow. The one time you might would be podman volume issues (when you forget or don’t know to append a z/Z) or when you’re doing something odd. I can see how some would dislike it in that case.
But in any case I fully recommend running it and just learning how to use it. Kind of like IPv6. It’s misunderstood, too often disabled, and should be more widespread. They both are really improvements to what came before. Just technology that takes a little more time to learn is all.
Here is a helpful video explaining it- https://youtu.be/_WOKRaM-HI4
SRE here and I agree with you. I’m basically a glorified Linux admin lol
I don’t hate it, but as a PC/phone user it’s security features are almost never helpful and always cause issues so I just have it disabled.
I never have any issues with it in fedora
I don’t hate it. What’s SELinux?
In the time it took you to type that comment here, you could have typed it in Google and gotten an immediate response
Some people like to talk to each other. Like people who are people?
That’s true. “define chair” is a great conversation starter.
An elevated platform that is raised on one side (forming a “back”) designed with the intent of sitting… No “back” = stool
Thanks!
Was trying to start a discussion, my bad.
Internet users like you are the worst.
Yep, we’re right up there with lazy people who literally ask strangers to Google things for them and then sit back and wait for the response to be delivered to them personally. The worst.
This is an online DISCUSSION
Stfu
Exactly. You tell em! This is a discussion! It’s not a place to ask for definitions.
U mad tho
No U mad
If they brought up SELinux I’d assume they had no need to Google it.
I would agree until they asked what it is
SELinux is an access control system for Linux. Traditionally Linux uses Dynamic Access Control (DAC) which basically means the person who creates a file can determine who can access that file. Thats pretty fine for day to day use but there are some problems with this model in terms of security. One I can think of is that it’s more vulnerable to privilege escalation (a hacker getting access to a higher level account like admin through a lower level account) because it puts the onus on the user to define who can access the file. SELinux was invented by our good friends at the NSA to remedy these kinds of problems. It’s an example of Mandatory Access Control. It works on top of DAC by creating policies that work to prevent things like privilage escalation. It’s also a lot more comprehensive than DAC. It allows for things context based access, taking into account the broader security context of an access attempt, the user’s role, etc.
I’m actually not entirely sure why some people don’t like it. Understandably, some people are wary of anything the NSA let’s out into the public. But as it’s open source and has been integrated into a number of Linux distros like Fedora, it’s unlikely they’ve backdoored it. If I was to hazard a guess, I’d say some people don’t like it for the same reason they don’t like systemd: Linux has often been an OS where user’s like a big degree of control through simple traditional systems and those don’t like the idea of losing some of that control to the complexity overhead involved in these new systems.
