Why it’s time to stop setting SELinux to Permissive or Disabled

Given the kerfuffle that has been CentOS lately, and the number of inevitable forks that will rise out of the ashes, there will probably be a large percentage of admins migrating to, or finally deploying, a Linux distribution based on Red Hat Enterprise Linux in some form or fashion. It may be Rocky Linux or AlmaLinux. It may be that you stick with CentOS Stream, or even purchase a license for Red Hat Enterprise Linux. If you’re a non-profit or another eligible organization, you might qualify for RHEL for Open Source Infrastructure.

No matter which route you take, you’ll be using a solid Linux distribution with serious security systems in place. 

However… It’s such a powerful word, “however.” It stops all natural flow of the narrative to make you wonder just what comes next.

You wait, and you wait, and you wait.

Until the inevitable: SELinux.

SEE: How to become an expert at SELinux (TechRepublic Premium)   

Your mode of choice

If you’ve used a Linux distribution based on Red Hat, and you’ve discovered SELinux is causing whatever you’re trying to work with to fail, do you:

• Spend the necessary time to make your project work with SELinux?

• Set SELinux to Permissive, to help troubleshoot the problem?

• Disable SELinux?

Trust me, I get it. I can’t tell you how many times I’ve been working on CentOS, only to find SELinux is preventing the tool I’m using from functioning properly. You’ve most likely found yourself in the same boat. After a bit of research, you discover the true complexity of SELinux. In a fit of desperation, you disable SELinux and everything finally works as it should.

The long and short of it is that while configuring SELinux isn’t easy, disabling it is.

However…

If that Linux distribution is a part of your data center, you’re going to need as much security as you can get. Disabling one of the most powerful security features in an operating system is certainly counter to that need.

The time for Disabled or Permissive SELinux settings is over. We live in an age where systems (big, important systems) are getting hacked on a daily basis–that’s only going to continue to get worse. To that end, your systems need as much protection as they can get.

The argument should end there, but it doesn’t.

But…permissive?

Now, I understand your confusion. Sure, “disabled” shouldn’t be an option for production machines. Period. What’s wrong with a little permissive now and then? Let me explain. 

When you set SELinux to Permissive mode, you disable one of the key features of the system and expand the attack surface of the operating system. Permissive mode means SELinux is running, but not enforced. You may think permissive is a good middle ground for your system, but it’s not. The only difference between Disabled and Permissive is that Permissive keeps SELinux running and logs Access Vector Cache actions. In other words, Permissive mode permits, but logs everything. 

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.

But, why?

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.

Setting SELinux to Disable or Permissive is easy, but we’re talking about the security of your server or LAN. 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.

It’s complicated

I get it–I really do. For the longest time, I set SELinux to Permissive or even disabled it altogether. 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.

Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.

Cybersecurity Insider Newsletter

Strengthen your organization’s IT security defenses by keeping abreast of the latest cybersecurity news, solutions, and best practices.
Delivered Tuesdays and Thursdays

Sign up today

Also see