Should i turn off selinux

As you might have guessed, Permissive mode is great for troubleshooting. While it won't prevent your app or service from running, it will give you plenty of information as to why it would have been prevented, if SELinux were in enforcing mode.

It's perfectly fine to set SELinux to Permissive mode while testing, but once you've figured out the problem, it's time to set the security system to enforcing. Simply put: Security. Remember, SELinux is a Linux kernel security module that provides the necessary mechanism for access control policies, which includes Mandatory Access Controls. With SELinux in place, you the admin have more control over who or what has access to your system by way of security policies.

It's a very granular approach to system security, but as many have discovered, it's not exactly the easiest system to configure--it's still worth the time and effort to understand. That's not the place to take the easy route.

With SELinux in place, if you deploy a web server that allows an attacker to gain access, SELinux will prevent that attacker from accessing any file the web server isn't supposed to see. I get it--I really do. I needed things to work and SELinux did a very good job of preventing those things from working.

On top of which, when you only have so much time in the day, you can't constantly be giving time to troubleshooting a security system that seems to always be in the way. Because of that, the easy route is sometimes the only viable route.

After all, you have a metric ton of tasks to take care of. In the near future, I'll be doing a series on SELinux, to hopefully make the system a bit easier to understand. Until that time, don't cave to the complication. Keep SELinux set to enforcing mode on your production machines. If you're working on a test environment, Permissive or Disabled is fine, so long as the goal is to finally have your software or services running in enforcing mode.

SELinux can be a serious challenge to work with, but the added security gained from the effort is very much worth the trouble. Take the time, do the research and your systems will enjoy a higher level of security in the end.

Strengthen your organization's IT security defenses by keeping abreast of the latest cybersecurity news, solutions, and best practices. Apart from Oracle, what other vendors give trouble supporting systems with SELinux enabled? I mean, strict would be awesome, but I don't that is even remotely possible yet, so let's stay with targeted first ;-. RedHat turns SELinux on by default because its safer.

Nearly every vendor that uses Redhat-derived products turns SELinux off because they don't want to have to put in the time and therefore money to figure out why the thing doesn't work. They care about their security and the security reputation of their product, which is a totally different thing. If you can make it work, then go for it. If you can't, then don't expect a lot of assistance from the vendors out there. But from companies like Oracle -- well, SELinux doesn't really factor in to their business plan.

Typically you're better off running SELinux in Permissive rather than disabling it entirely. You can then check via audit2why after a while to see what kinds of violations would have been denied during your regular usage, and build custom policies via audit2allow if those 'violations' are false-positives for your setup.

I worked for a company that had SELinux enabled, in enforcing mode, on every system. The key for us was understanding and using the audit2allow program which can be used to create new context rules.

This builds the module from the template. We used Puppet for our configuration management system, and we wrote configuration for Puppet to manage all this.

However we don't turn it off now. We nearly always keep it running. I do occasionally turn it off to quickly verify if SElinux is a problem or not. It' much easier to debug now, especially if you make yourself familir with audit2allow.

You don't really need to understand it with audit2allow, but you can some times end up opening thins up wider than you think with audit2allow. Having said that some SELinux is better than none. I'm by no means an SELinux expert and have only been using it for a couple of years. I still don't really understand the basics, but I know enough to get apps running, btoh those included with the distro and random stuff compiled of the 'net. The main thing I've had to use are the ls -lZ show selinux context , audit2allow , chcon , semodule , getenforce , setenforce and booleans.

I find one of he big problems with debugging SELinux problems,, is simply remebering to check for SELinux problems when I have other wise inexplicable problems. It usually takes me a little wile to go "h! According to the bind man page SELinux is far safer than running bind in a chroot jail. A lot of other people who have far more clue than I also recommend it so I run it blindly now. And suspect despite the occasional problem it is probably worth doing.

There is no reason to turn it off when you can run it in Permissive mode. It will not interfere with the running application and it will still provide useful security logging. The only exception is about the user contexts: if you are changing between different users living inside another linux instance running in a chroot you could have issues. SE Linux is not as hopelessly unfriendly as it used to be, at least it's not in commercially supported distros like RHEL5.

For the most part you can leave it on, and it'll be fine with anything provided by RedHat. If you liked this article, then do subscribe to email alerts for Linux tutorials.

If you have any questions or doubts? Related Posts. This article proved quite useful to me. Thank you! The only thing you left out is why. Why would you do this? Got something to say? Join the discussion. Cancel reply Have a question or suggestion?