Hacker News Reader

Comment by SteveNuts | Hacker News Reader

Disabling SELinux is a mistake, especially now that there are tools that will scan the audit.log and tell you exact commands on how to fix each thing it finds.

If you want to do something weird like allowing nginx or apache to serve your home directories, it takes maybe 5 minutes to google the correct se context to set on the directory and apply it, otherwise any standard installation works out of the box.

There's literally no reason to turn it off nowadays, other than laziness/unwillingness to learn.

View on HN

I can think of a great reason to disable SELinux; you actually use linux for a workstation and don't want fight with it every time you install a new application.

do you also do chmod -R 777 /?

That seems excessive. Why not just run as root?

Pretty sure that actually breaks stuff

This is correct.

But you don't. Almost all 'applications' run unconfined.

I can think of a great reason not to disable it, exposing $HOME to the world.

Have had SELinux for almost 10 consecutive years. $HOME has never been exposed. I've no idea what you're going on about.

Of course not, you have it enabled. Read OP properly?

Whoops, typo, I meant to say I've had it disabled all that time.

Selinux will become useful when it precisely lists out what it disables with transparent explanations for assumptions made. And clear error messages or alerts when it has just disabled something with proper logging.

Unlike with most open source software for things like selinux that disable a host of stuff by default, documentation cannot be an after thought. And why invent weird vague terminology, what is a context?

Things are complex as it is and people need to get things done. To have to waste man hours that could be used more productively more than once only to figure out its caused by selinux 'silently' without any proper error messages or logging and you do the sensible thing and disable it.

> what it disables with transparent explanations

setroubleshoot

> documentation cannot be an after thought

Take a look at selinux-policy-doc, it's extensive.

> what is a context

It's a type. But 'type' as it refers to files means something else. It's just a label that describes what kind of file it is. user_home_dir_t is user files, httpd_sys_content_t is content that can be served by apache, nfsd_fs_t are files that that can be exported by NFS.

> proper error messages or logging

Every single denial is logged and it contains all the details why it was denied. You're asking for SELinux to log why it wasn't allowed which is done by setroubleshoot but isn't possible in general.

> Every single denial is logged

Not quite true. Some need to have debug turned on. See my other comment.

How about lack of necessity? I isolate my systems in many ways, using vms, tunnels and network isolation, but SELinux just doesn't fall into that, if anything's getting compromised it's the service in question that's the problem. Just because something exists doesn't mean you have to learn it and it doesn't make you lazy for refusing to do so. Proper protections extend far beyond using tools like this.

Additionally, if you're running a desktop system and software installation is a frequent task, you'll have to deal with that constantly, often many times for the same application. At some point you're going to give up and say it's not worth it. Most people can't even stand the GUI based notifications of Outpost or ZoneAlarm in my experience.

SELinux is all about minimizing and isolating collateral damage after a service is compromised, so if you care about that at all I'd suggest leaving it on.

Also, it's probably the best protection from a zero-day exploit there is.

Yeah what I'm saying is that I've already done so myself and have no need for SELinux. Proper network and VM isolation is far better than SELinux. I don't want it forced on me and will disable it. Not out of laziness, but due the lack of a purpose.

Security is best implemented in layers. VMs are not impermeable. Case in point: the VENOM vulnerability: https://access.redhat.com/articles/1444903 , which was thwarted by SELinux's protections for virtual machines (sVirt).

That's pretty sweet, if I had to manage my own VMs I'd definitely look into SELinux for that feature.

I can see an argument for a defense in depth approach here, but if there's only one service per VM and that service is already restricted to only the stuff it needs to talk to on the network level I'm not convinced it makes much sense. As far as I know at least, SELinux won't be able to prevent kernel exploitation or the like.

It absolutely prevents kernel exploitation by stopping certain syscalls. I guess you can argue that it doesn't stop "The exploit" in syscalls it allows but it does prevent syscalls from being run.

I'm referring to remote kernel exploits - things that would introduce a new attack vector. Say a bug in a say a network driver or protocol that would already be at ring0 - SELinux does not prevent such an attack. Something that would allow a new way in to a host other than the service in question. If you have ring0 you can just disable SELinux.

If you already broke into the service and can make syscalls, well, there's really not much gain from that under my architecture at least - you can still only access what's already in that one service.

Proper vm isolation with selinux is better than either separately. What if you get a QEMU VM break out.

SELinux is quite possible and easy to disable with any local root kernel exploit. They only thing it might make harder is actual act of exploitation by shutting down syscalls and sensitive parts of file system. Compared to these, VM are rare. You typically need one of those to attempt breakout anyway.

Then again, three were a plenty exploits against general FS or common calls like poll... Things you cannot limit in this way because they are used by apps in question.

> it's the service in question that's the problem ..

But that's what selinux limits -- the "blast radius" from a compromised service.

Precisely what I'm saying, the limitation to the blast radius is already there if you've done the isolation yourself and it's only that one service that gets hit.

If your Web server is on a private network with your app server and your load balancer, there's no way it can attack your database server. Basically, policies are implemented at the network and host level rather than the process and file level.

The risk is that an app compromised could lead to local access which allows local (root/kernel) exploits.

You're entirely correct, but we've become infected with SOE-think. Eventually you are always going to have a compromised node, and defence/detection in the node is hard and constantly evolving. The kernel attack surface is still large and complicated.

In contrast, network interfaces are well controlled. If people started with 'deny all' in their fw permissions then added the minimal necessary holes then lateral movement would be a lot harder.

I think the best argument for selinux/apparmor is that a lot of application specific security hardening can be packaged into standard configs. In contrast, there is little to orchestrate this for VMs/containers/physical hosts. Inter-VM/CNTR network control seems difficult (open vSwitch).

If we could have easily configured, hypervisor enforced firewalling and encrypted tunneling then that would be more useful confinement.

Building policy by just auditing is a bad idea - you'll end up with overly general roles. Policy building is best left to the author of the applications so that they can test against it and lock it down.

So what's your suggestion? Just disable SELinux for that application if it's failing?

> There's literally no reason to turn it off nowadays, other than laziness/unwillingness to learn.

Sometimes is as simple as not having time for that. If I've urgent work to do, I can't stop my work and well my boss/client "hang on, I need to learn to configure SELinux first!".

The fact that it DOESN'T work out-of-the-box immediately and needs for me to configure it (regardless of how well documented it is) is its major pitfall. These things need to work without adding ANY burden to the user. Otherwise, they'll end up disabled.

I mostly agree with you but sometimes it is extraordinarily difficult to find out what went wrong.

audit2allow and audit2why are often helpful but at least as often they offer the wrong solution.

Did you know that some selinux violations are not even reported by default?

This was the case for me; selinux transitions are prevented by a filesystem mounted _nosuid_. The failure is not reported because transition failures are apparently so common and unimportant selinux does not report them by default.

Took me a looong time to troubleshoot this.

> Disabling SELinux is a mistake, especially now that there are tools that will scan the audit.log and tell you exact commands on how to fix each thing it finds.

If it were actually that easy, then you wouldn't need this step since SELinux would just do it for you. Clearly that isn't the case.

SELinux can't tell which of those accesses were intended, and which were actual security violations it should keep preventing. That requires human intervention.

Maybe it could be made more convenient by a tool that parses the log and automatically runs the commands when you answer the question with "y".

> SELinux can't tell which of those accesses were intended, and which were actual security violations it should keep preventing. That requires human intervention.

Right, it requires intervention by a person who doesn't actually understand the minutiae of what the software is trying to do, so obviously they can make a properly informed choice as to what is and is not a security violation. Modern operating systems are so broken...

Reply on news.ycombinator.com