Security Enhanced Linux (SELinux) is a kernel module intended to increase security by enforcing the Mandatory Access Control. This concept gives you the control to ensure that users and applications are only able to access the things that they absolutely need to in order to complete the tasks they are designated to perform. While firewalls help protect the system against intrusion from the outside, SELinux helps prevent resources on the inside from doing things that they aren't supposed to be doing. This may sound vague, because it is how SELinux is used, and how you can benefit from it depends solely on how you implement it. Want to prevent a user from making a very private file world-readable? Sure, you can do that. Perhaps ensure Apache cannot access files outside of /var/www? You can do that too. Without SELinux, you would be relying solely on group and user permissions. SELinux helps you put more granular security restrictions in place by adding an additional layer of security to the mix.

SELinux is not exclusive to any one distribution, though you'll most commonly find it installed on Red Hat, Fedora, and CentOS systems. In a system such as Debian, you would need to install selinux if you wish to utilize it. Unfortunately, at the time of this writing, SELinux doesn't function properly in Debian due to the fact that a required package (selinux-policy-default) contained bugs that weren't fixed in time for Jessie's release, so this package was omitted in the official Debian 8.x "Jessie" repositories. However, the process for installing SELinux in Debian (should this package become available after publication) comes down to installing that package along with selinux-basics. After those packages are installed, you should be able to finish your SELinux installations by running the following commands and rebooting the system:

# selinux-activate
# systemctl enable selinux-basics.service

SELinux works with policies to determine whether or not an action is allowed. Policies are created with tools that exist in something known as the SELinux userspace, and the actual checking is done at the kernel layer. Each distribution that implements SELinux by default, will typically ship with a tested and supported set of policies, such that all the services you would reasonably expect to work will function as they should. Without a default set of policies, configuring SELinux by hand can be a real pain (if it even starts). As mentioned earlier, Debian's policies package is currently not a part of the main repository, so enabling SELinux in Debian may be chaotic at this time. In the case of CentOS though, everything you need to utilize SELinux will be working out of the box. In fact, unless you've disabled it, you're already using it!

There are three modes of operation for SELinux and those are enforcing, permissive, and disabled. By default, most installations I've seen lately are set to enforcing, but you can see which of these three yours is set to, by executing sestatus.

Output from sestatus on CentOS

With enforcing, SELinux is configured with its policy enabled and will act on anything that goes against that policy. If a violation occurs, SELinux will prevent the action and log it. In permissive mode, actions are not blocked but everything is still logged so you can audit your server yourself later. The disabled state is self-explanatory; in that mode, SELinux will not block or log anything while it is disabled. It's quite common that administrators will simply disable SELinux, assuming it to be too much of a burden if it gets in the way of a legitimate use case. But disabling SELinux isn't recommended unless you absolutely have to, as it's another layer of security that you could otherwise be benefiting from. At the very least, you may want to benefit from the permissive mode so that you would have more information available within your logs should something suspicious start to happen on your server.

To change the mode of operation for SELinux on the fly, use the setenforce command. For example, use setenforce Enforcing to change the mode to enforcing. Changes made via setenforce are not permanent. Once you reboot your machine, the mode will switch back to its default or whatever you have configured in its configuration file. The configuration file to change the mode permanently is the /etc/sysconfig/selinux file in Red Hat style distributions, or /etc/selinux/config in Debian. This file allows you to configure the two main settings to determine how SELinux is configured, the mode and the type. To change either permanently, update this file and restart the server. We already discussed the mode (it can be set to enforcing, permissive, or disabled), and the type is where we configure which policy we would like SELinux to use. This can be set to targeted, minimum, or multi-level security (mls).

In regards to updating the policy, targeted is the process that is in use by default on new installations (at least when it comes to Red Hat/CentOS), and it is fully supported by Red Hat. With this policy, every process runs in a type called unconfined_t, which is actually not restricted at all. Instead, processes will run under the Linux native DAC (short for Discretionary Access Control), which sandboxes them from other processes to help contain anything that may have been compromised. MLS, or Multi-Level Security, applies a sensitivity rating to objects, designated by s0, when it's enabled. (By executing sestatus, you can see whether or not MLS is enabled). We'll see some examples of context output shortly. With the minimum type, only processes we explicitly select will be safeguarded.

Every resource in a SELinux-enabled system contains a label, which is how SELinux identifies a resource and understands how to police it. You can see these labels (also known as contexts) yourself by using the -Z parameter with one or more commands, such as ls, id, or ps. This special parameter is available to these commands only when a system is configured to utilize SELinux, and it allows you to view the context as part of the normal output. For example, you can use the -Z parameter with the ls command on a SELinux system and you would see an output like this:

-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 myfile

Normally, the output of the ls command would contain fields such as the modification date and size when viewing output of a command such as ls. But again, the -Z parameter is special. It implies that you would like to see the output of the command as it pertains to SELinux, rather than the output you would normally get. You can also try it with id (id -Z), and ps (ps auxZ) to have the output of those commands show you their SELinux context as well.

The label contains multiple fields. In the output from the ls command I pasted, we can see the fields unconfined_u, object_r, admin_home_t, and s0. To better understand this, look at the last few characters of each. The _u designates the user, _r designates the role, and _t represents the type. Therefore, we can see from the previous output that the file called myfile has a user context of unconfined_u; it's assigned the role of object_r and a type of admin_home_t. Let's look at another example. In the output of ps auxZ on my CentOS system, I see the following line for my SSH session:

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 jay 20575 0.0  0.0 135216 2080 ? S 10:40   0:00 sshd: jay@pts/0

Looking at the beginning of the line, we again have context for user, role, and type. In this case, each are named unconfined, but we can tell which is what by the last two characters.

The type is the most important part of the output, because this is how SELinux does its enforcing. Given the type, SELinux knows how to restrict (or not to restrict) the object. In the first example, we have admin_home_t, and we have unconfined_t in the second example. From this, we can gather that SELinux isn't enforcing anything with my SSH session (unconfined_t) but has a specific policy in place for my home directory, which is where the output of the file came from. Another context we have seen in the example output is the role, designated by a suffix _r. When applying a role, SELinux is able to group together various contexts and apply them to a user object with one call. This makes it easier to designate what users are able to do and how they're allowed to interact with other objects.

There are several commands that can be used to relabel the context information of an object. To begin, there's the chcon command. The chcon command is used with the -t parameter, which designates the type you would like to change the object to, followed by the name of the object:

# chcon -t admin_home_t myfile

Using -R, we tell the chcon command to make the changes recursively, which is great if you're changing the context of a directory. In addition, you can also use -r if you'd like to change the role instead of the type. If you make a mistake or you'd like to revert your changes, restorecon does exactly that. The restorecon command will revert an object to its default state, as defined in its policy. Another command for managing SELinux is semanage. With this command, we can make permanent changes to how objects are treated and labeled. It's important to note that changes via chcon might not always persist. While changes via chcon will likely survive a reboot, they persist if the filesystem gets relabeled. The semanage command allows us to make these changes more permanent. Using semanage, we can make changes to file contexts, user mappings, as well as user contexts.

First, an example of mapping user jdoe to the sysadm_u SELinux user:

# semanage login -a -s sysadm

Next, here's an example of using fcontext along with semanage, we can change what types file objects belong to:

# semanage fcontext -a -t  admin_home_t myfile

See the man pages for semanage for even more examples. SELinux is a large subject matter for which entire books have been written. A complete walkthrough of SELinux would take multiple chapters, but the information given here should serve as an adequate primer. When implemented properly, it can greatly enhance security on your servers.