How to disable SELinux

Posted on October 10, 2015, 2:00 pm by Dan

SELinux is that “thing” that breaks functionalities and makes sysadmins think there is some magical force preventing whatever process to write on a 777 permission file or connecting to a socket. Usually learning how to configure SELinux and disable particular restrictions is the best way to go, but when deploying multiple nodes for dev testing or qa behind a firewall or in a private network (virtual cloud) the fast solution is preferred.

Some typical “access denied” issues caused by SELinux are:

Configuring the database engine to access files on a different mount point (e.g. some storage freshly allocated in AWS). The database works flawlessly with data files on a certain path but after mounting the storage and putting the same file on the same path, the startup fails.
Postfix cannot deliver local mails through the LMTP socket (e.g. used by Cyrus Imap or Dovecot).
Errors with accessing paths in PHP scripts (well, not always a bad thing, this one).

Taking down SELinux is easy. The config file is /etc/selinux/config and the typical content is:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

# SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0

The obvious “fix” is to replace enforcing with any of the other 2 options. The “permissive” one will fill up a log with various warnings and would-be restrictions that can help do some proper configuration. But the real solution is to just put “disabled” in there and forget about it. ^*

Oh, and the node must be restarted:

$ sudo telinit 6

That’s it, have fun!

^* No, this is not the real solution on a security-aware environment. Learning SELinux is the actual way to go for the long term (while I agree to you that the syntax is messy and the controls are way too fine grained, which is a good and a bad thing at the same time). More reading on this topic: