Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ctrl.blog

Post reply on HN
Print view View original

91–100 of 461 posts

Re: SELinux is unmanageable; just turn it off if it gets in your way

#91

Post by raesene9 »

mindwok wrote: post #2

As an experienced RHEL admin, a few years ago I probably would have said this is very bad advice in any professional context, and you should spend the time to learn it because it will save you one day. Now, I think my advice would be: Put everything in a container, and learn how to run Docker or Podman (or k8s) in a secure way (ie no root containers, be very careful with volume mounts, etc). Yes, they aren’t as matur…

I'd generally agree with this, but for production use (where it'll be CRI-O or ContainerD in all likelihood) it's worth noting that using containers does increase your attack surface.

We've had container breakout CVEs in the Kernel+ContainerD+CRI-O this year, and the ContainerD/CRI-O ones were not complex at all, so you do need to stay on top of patching as well as the other good practices mentioned.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#92

Post by nix23 »

sydthrowaway wrote: post #47

How does SElinux compare to Secure Boot / SIP?

SElinux is a MAC system:

https://en.wikipedia.org/wiki/Mandatory_access_control

https://en.wikipedia.org/wiki/Multilevel_security

https://en.wikipedia.org/wiki/Security-Enhanced_Linux

Re: SELinux is unmanageable; just turn it off if it gets in your way

#93

Post by Arnavion »

kbenson wrote: post #38

I have to say, for sysadmin work I find this view sorta overblown. My experience is with RHEL and derivatives, not Fedora, and for the most part those are very straightforward and while selling does rear it's head every once in a while, it's usually not that problematic to work around. When you have something failing that you need to fix and isn't an upstream problem (i.e. your own app or some third party vendor), yo…

The three paragraphs starting with "In the best-case scenario" address exactly what you're talking about. And in my brief (hobbyist) usage of CentOS 7 with trying to run some self-written software, what TFA says was exactly my experience.

As it turned out, the hardening provided by systemd (private tmp, restricted syscalls, etc) was sufficient, and easier to understand, for my use case.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#95

Post by microtonal »

scrapheap wrote: post #80

Does anyone have any examples of where SELinux saved the day? I appreciate that some of the time you'd never know, but I am curious if anyone has any real life examples where it stopped an attacker.

https://www.redhat.com/en/blog/selinux-mitigates-container-v...

https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-s...

https://danwalsh.livejournal.com/30565.html

Re: SELinux is unmanageable; just turn it off if it gets in your way

#96

Post by bitcharmer »

TheDong wrote: post #61
bitcharmer wrote: post #45

Earlier quoted context omitted.

Container approach is not always feasible, for example when you need to stay on bare metal. There are Linux applications where selinux definitely gets in your way and there are legitimate reasons to turn it off completely. edit: I like how I'm getting down-voted for sharing factual information. No-one in high frequency trading employs containers because it doesn't help soft-realtime, low-latency goals. There are othe…

> when you need to stay on bare metal What cases can linux containers not handle? Containers can access GPUs, /dev/kvm, block devices... I'm having trouble thinking of anything they can't do. After all, they're just processes in a glorified chroot, not that different from processes on the linux host.

Ultra-low latency applications on Linux are definitely one domain were containers are a big no-no for performance reasons. In my field (HFT) you won't find any serious performance-sensitive deployments using containers. So that's one example.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#97

Post by strzibny »

This is not a good advice.

You'll basically get Ubuntu that didn't have SELinux in the first place, and most people don't care.

SELinux is difficult to build from scratch but there are decent tools to build your policy in an automated fashion.

The advice should be this: Don't have time to deal with SELinux at the moment? Switch to permissive policy and deal with it later.

I included SELinux as one big chapter in my book Deployment from Scratch rather than skipping on it.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#98

Post by prmoustache »

fargle wrote: post #34

How can I trust some opaque policy I cannot see? Not just trust that it is well intentioned not evil, (Oracle Linux?), but that it does what it says. And does what I need and that the opaque developers have correctly envisioned what I need to do. Security by obscurity is worse than none at all. Security by buying an "Enterprise" product is worse than that. What SELinux says is " real MAC security is super complicated…

> but you can't understand it or change anything"

That is not true. SELinux is not hard to understand nor change. Most of the issues you might encounter are simply solved by changing a label in a file or directory. It is just not straightforward to debug and understand if you don't know it is there. I think most people who complain about it are multi distros/OS users and just only realize after losing precious time that an issue is selinux related.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#99

Post by kbenson »

autoexec wrote: post #50
kbenson wrote: post #38

I have to say, for sysadmin work I find this view sorta overblown. My experience is with RHEL and derivatives, not Fedora, and for the most part those are very straightforward and while selling does rear it's head every once in a while, it's usually not that problematic to work around. When you have something failing that you need to fix and isn't an upstream problem (i.e. your own app or some third party vendor), yo…

> and then you use ausearch and audit2allow to generate a module for it. And bi, while the selinux audit log entries (which ausearch shows) aren't super clear, That still sounds pretty complicated for most people. I mean, I know a lot of otherwise capable people who think NoScript is too much to manage and that's something I've heard repeated online many times. That's just clicks, and only when you actually need to a…

I agree, which is why I prefaced all that with "for sysadmin work", which I think has a different standard than for regular people.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#100

Post by cube00 »

josephcsible wrote: post #23

SELinux has a horrible misfeature called dontaudit, that lets policies using it deny actions without any evidence being logged anywhere. Because of the existence of this, the only reliable way to know if a problem is being caused by SELinux is to temporarily disable it and see if the problem goes away.

After years of setting permissive on my personal machine I wanted to do the right thing and set it up properly. I watched the presentations and all seemed so reasonable. It's there to help you, audit2allow will help you out even further if you need to allow something. Look at how detailed those error messages are explaining the problem and the solutions.

I thought I was going crazy that things weren't working and there were no denials in the log. After much pulling of hair I finally found out about dontaudit, I felt so cheated, it wasn't even playing fair at that point.

For anyone else hitting this, you can use semodule to disable dontaudit in step 4 [1]

[1] https://access.redhat.com/documentation/en-us/red_hat_enterp...

Post reply on HN