No! Don’t turn off SELinux!

Thursday , 27, July 2017 10 Comments

One of the daily activities of the CentOS Community Lead is searching the Internet looking for new and interesting content about CentOS that we can share on the @CentOSProject Twitter account, or Facebook, Google +, or Reddit. There's quite a bit of content out there, too, since CentOS is very popular.

Unfortunately, some of the content gets unshared, based on one simple text search:

"SELinux AND disable"

That setting is indicative of one thing: the author is advocating the deactivation of SELinux, one of the most important security tools any Linux user can have. When that step is outlined, we have to pass sharing it and even recommend readers ignore such advice completely.

What is SELinux?

But why do articles feel the need to outright deactivate SELinux rather than help readers work through any problems they might have? Is SELinux that hard?

Actually, it's really not.

According to Thomas Cameron, Chief Architect for Red Hat, SELinux is a form of mandatory access control. In the past, UNIX and Linux systems have used discretionary access control, where a user will own a file, the user's group will own the file, and everyone else is considered to be other. Users have the discretion to set permissions on their own files, and Linux will not stop them, even if the new permissions might be less than secure, such as setting chmod 777 to your home directory.

"[Linux] will absolutely give you a gun, and you know where your foot is," Cameron said back in 2015 at Red Hat Summit. The situation gets even more dangerous when a user has root permissions, but that is the nature of discretionary access control.

With a mandatory access control system like SELinux in place, policies can be set and implemented by administrators that can typically prevent even the most reckless user from giving away the keys to the store. These policies are also fixed so not even root access can change it. In the example above, if a user had implemented chmod 777 on their home directory, there should be a policy in place within SELinux to prevent other users or processes from accessing that home directory.

Policies can be super fine-grained, setting access rules for anything from users, files, memory, sockets, and ports.

In distros like CentOS, there are typically two kinds of policies.

  • Targeted. Targeted processes are protected by SELinux, and everything else is unconfined.
  • MLS. Multi-level/multi-category security policies that are complex and often overkill for most organizations.

Targeted SELinux is the operational level most SELinux users are going to work with. There are two important concepts to keep in mind when working with SELinux, Cameron emphasized.

The first is labeling, where files, processes, ports, etc. are all labeled with an SELinux context. For files and directories, these labels are handled as extended attributes within the filesystem itself. For processes, ports, and the rest, labels are managed by the Linux kernel.

Within the SELinux label is a type category (along with SELinux user, role, and level categories). Those latter aspects of the label are really only useful for complex MLS policies. But for targeted policies, type enforcement is key. A process that is running a given context -- say, httpd_t --should be allowed to interact with a file that has an httpd_config_t label, for example.

Together, labeling and type enforcement form the core functionality of SELinux. This simplification of SELinux, and the wealth of useful tools in the SELinux ecosystem have made SELinux a lot more easy to manage than the old days.

So why is that when SELinux throws an error, so many tutorials and recommendations simply tell you to turn off SELinux enforcement? For Cameron, that's analogous to turning your car's radio up really loud when you hear it making a weird noise.

Instead of turning SELinux off and thus leaving your CentOS system vulnerable to any number of problems, try checking the common problems that come up when working with SELinux. These problems typically include:

  •  Mislabeling. This is the most common type of SELinux error, where something has the wrong label and it needs fixed.
  • Policy Modification. If SELinux has set a certain policy by default, based on use cases over time, you may have a specific need to change that policy slightly.
  • Policy Bugs. An outright mistake in the policy.
  • An Actual Attack. If this is the case, 'setenforce=0' would seem a very bad idea.

Don't Turn It Off!

If someone tells you not to run SELinux, this is not based on any reason other than supposed convenience or misinformation about SELinux.

The "convenience" argument would seem to be moot, given that a little investigation of SELinux errors using tools like `sealert` reveal verbose and detailed messages on what the problem is and exactly what commands are needed to get the problem solved.

Indeed, Cameron recommends that instead turning off SELinux altogether, run the process with SELinux in permissive mode temporarily and when policy violations (known as AVC denials) show up in the SELinux logs, you can either fix the boolean settings within existing policies to allow the new process to run without error. Or, if needed, build new policy modules on a test machine, move them to production machines and use `semodule - i` to install them, and set booleans based on what is learned on the test machines.

This is not 2010 anymore; SELinux on CentOS is not difficult to untangle and does not have to be pushed aside in favor of convenience anymore.

You can read more about SELinux in the CentOS wiki. Or see the SELinux coloring book, for a gentler introduction to what it is and how it works.

10 thoughts on “ : No! Don’t turn off SELinux!”
  • Christof Damian says:

    While I agree that turning off SELinux is a bad idea. I don't agree that there are simple fixes for most users.
    For some problems even experienced users can have a hard time figuring them out.

    One example: https://bugzilla.redhat.com/show_bug.cgi?id=1402083
    The problem can be fixed with a simple relabel of the correct file, but it is very difficult to find this out. And people are still adding to this bug even though it is closed.
    The problem was caused by the nfs-server package itself, which was also written by experienced developers.

  • Doctor Dbx says:

    Selinux is a great concept but is fundamentally broken when default configurations from official repos trigger violations.

    It's not 2010 and this shouldn't happen!

  • this really needs to be explore...thanks for the such a useful and knowledge based post

  • Michael Nielsen says:

    While SE linux is a great concept, it is in no way easy to work with. Especially if you need to something other than what the developers has defined as a standard installations - eg all web pages must live in /var/www, as an example..

    So cleaning the system - (separating data and operating system) and moving things to other locations is a pain to maintain, and when you finally get it fixed, it then get's broken when SELinux is updated.

    There is a need more informative and intuitive tools for working with SE linux. There is nothing like having something fail, and spend hours trying to figure out why, and suddenly you figure out that it is a SELinux viloation, that is blocking everything, but as SELinux tools support is very poor, the problem is hard to diagnose.

    Currently the tools are good for those who pretty much always work with SELinux, but are a pain for anyone else.

  • Roly says:

    Don't forget that you can put individual domains, in SELinux, into permissive mode rather than the whole filesystem. I find this very handy in troubleshooting individual issues while retaining the overall security of the box

  • Yubby McFly says:

    SELinux serves no purpose, and does not function with vendor-provided software. As per its security value, any 'hack' that obtains 'root' or 'root-process' access, simply executes 'selinux disable' and it's 'game over'. Any user that sets '777' (or '666') permission values on ANY file/directory is to be fired immediately. Any developer who attempts to access a server (and/or uses the term 'devops') is to be fired immediately. ('those' are the security practices to be followed). Use 'sudo' to execute scripts that deploy to 'app owned' areas (which is then logged).

  • Bruno Lavoie says:

    Hard to keep it in enforcing mode when you install a product that needs to be supported and the first install requirement is to disable SELinux... 🙁

  • Mike Wolff says:

    "This is not 2010 anymore; SELinux on CentOS is not difficult to untangle and does not have to be pushed aside in favor of convenience anymore" - Well, sure. However, most of the direction I get to turn off SELinux comes from the developers of open source software that I may or may not need to customize, but always compile myself, and there has been zero support for SELinux because of all of the free time developers have had since 2010 to go back and retrofit their code with the additional burden of building it to be supported 'out of the box' with SELinux turned on. Beauty is in the eye of the beholder, and from a security perspective, I like and want to run under the blanket of SELinux, but the amount of additional time to invest to use is inhibits this. It isn't as 'easy' as it is made out to be, and has been a very time consuming obstacle where I'm batting about .500 in succeeding with an end result of source-built packages (with our without customization) function as desired with SELinux turned on. In the real world where we are expected to deliver results and have it done yesterday, nobody has time to fool with something as clunky as SELinux is.

  • Justin Coffman says:

    SELinux IS actually very easy to work with, despite what a lot of these comments would have you believe. Check out the audit2why and audit2allow commands. I regularly take software that claims to be wholly incompatible with SELinux and make it work perfectly with just those two commands. Proper security takes WORK, and SELinux is an excellent tool.

  • Please give us your valuable comment

    Your email address will not be published. Required fields are marked *