Why do we hate SELinux?
-
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 it.
-
setenforce 0is much cleaner, I have found.A mandatory part at the beginning of every Ansible playbook!
-
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?
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.
-
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?
Docker container can't read a bind mount. Permission issue? No, it's SELinux, again. And I didn't even install it explicitly, it just got pulled in by another package.
-
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?
Security is much more effective and adopted when it is simple. My understanding is that SELinux is not.
This means not only will fewer people use it and more people turn it off if something doesn't work, it means more people are at risk of misconfiguring their system to allow something they didn't intent to.
This is somewhat mitigated from the fact that, from my experience, Linux Security Modules cant ever make you less secure than without it. But it still can provide a false sense of security if you misconfigure it.
-
setenforce 0is much cleaner, I have found.They my go to to quickly triage a problem being caused by SEL or not.
-
Docker container can't read a bind mount. Permission issue? No, it's SELinux, again. And I didn't even install it explicitly, it just got pulled in by another package.
Isn't that trivially simple to address though? Just add
:zto the end of the mount value string, and restart the container. -
Security is much more effective and adopted when it is simple. My understanding is that SELinux is not.
This means not only will fewer people use it and more people turn it off if something doesn't work, it means more people are at risk of misconfiguring their system to allow something they didn't intent to.
This is somewhat mitigated from the fact that, from my experience, Linux Security Modules cant ever make you less secure than without it. But it still can provide a false sense of security if you misconfigure it.
Yep. Android modding prior to Magisk and Google overcomplicating things was the first step "selinux permissive".
-
Security is much more effective and adopted when it is simple. My understanding is that SELinux is not.
This means not only will fewer people use it and more people turn it off if something doesn't work, it means more people are at risk of misconfiguring their system to allow something they didn't intent to.
This is somewhat mitigated from the fact that, from my experience, Linux Security Modules cant ever make you less secure than without it. But it still can provide a false sense of security if you misconfigure it.
SELinux isn't really meant to be a user space "utility," for lack of a better term. It's meant to be an expert focused security framework for those with the expertise to both understand and implement robust security policies. Your average user daily driving Linux or even running a few self hosted services doesn't really need complex security policies, and is definitely better served by some simpler tools.
-
Security is much more effective and adopted when it is simple. My understanding is that SELinux is not.
This means not only will fewer people use it and more people turn it off if something doesn't work, it means more people are at risk of misconfiguring their system to allow something they didn't intent to.
This is somewhat mitigated from the fact that, from my experience, Linux Security Modules cant ever make you less secure than without it. But it still can provide a false sense of security if you misconfigure it.
I think this is where the confusion happens.
I use SELinux at my job. I admit that I'm not a Linux expert, neither am I an SELinux guru. The only interaction I have with SELinux is:
- Oh, my app keeps dying even after I chown the relevant directories.
- Looks at SELinux AVCs
- Creates new policy and puts in the home directory for the application - example: I just did it for HAProxy this week.
- If I fucked something up and I know the other apps have their policy modules in their place, I just do a restorecon and spend 5 minutes going through the policies whilst reprimanding myself for my stupidity.
I'm being honest that is literally what's it's been like to use SELinux. For context, AppArmour is exactly the same situation but now I need to edit a file (I can be lazy and keep appending rules to it but that will bite me later). If we're going down the path of SELinux being complex for daily usage, then all MAC has the same problem.
I admit that I would find it daunting to do this for a desktop environment. It's there that I want a pre-configured SELinux policy OOTB. On servers though? It's not a big deal for me.
Or maybe I missed something.
-
Docker container can't read a bind mount. Permission issue? No, it's SELinux, again. And I didn't even install it explicitly, it just got pulled in by another package.
SELinux is installed by default on RHEL derivatives like AppArmour is on Debian derivatives. Sure maybe it's annoying to see a package you didn't download explicitly but I still don't see why it's a big deal. I guess having to delve into SELinux in the middle of configuring another app will cause some pain
-
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
-
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
-
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, 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
-
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.
-
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
-
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, 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.
It's probably a french guy who makes setroubleshooter
-
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?
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 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, 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.
Is it not possible to run it in audit mode in dev and have it tell you what the would have blocked?
-
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.
