Security-Enhanced Linux (SELinux) is a kernel level security feature that enables the use of access control mechanisms, including mandatory access controls. It’s been available since kernel version 2.6 (released 8th August 2003), but is often disabled on servers because of how complicated it can be to setup and administrate. It’s a popular security option with Red Hat, and as a result also with CentOS and Scientific Linux.

The default policies supplied with SELinux don’t normally cause too many problems, as long as OS defaults are used for everything. But, if you start making changes, it will start to flag up errors pretty quickly.

To give an example of the sort of issues you can have – a common problem encountered is the result of making changes to a site’s document root. For example, let’s assume you’ve set the document root for your website to be /mysites/web1/public_html and not made any changes to SELinux, you will get an error like this when you restart apache:

Starting httpd: Warning: DocumentRoot [/mysites/web1/public_html] does not exist

This is because apache doesn’t have permission to access this folder.

Everything (files, folders, processes) has an SELinux security context. You can view the current context using the -Z switches, e.g. -

ls -Z /mysites/web1/public_html
-rw-r–r– root root user_u:object_r:default_t /mysites/web1/public_html

Apache runs in the httpd_t domain, and does not have access to anything which isn’t in a related domain. To make this document root accessible, we need to change the security context to httpd_sys_content_t using the chcon command:

The chcon command may be used to change SELinux security context of a file or files/directories in a similar way to how ‘chown’ or ‘chmod’ may be used to change the ownership or
standard file permissions of a file.

If you’re happy to have apache access anything in /mysites, you can just recursively allow the whole folder by running:

chcon -Rv –type=httpd_sys_content_t /mysites

However, if there’s other folders in /mysites that you don’t want apache to access, you might want to just allow access to /mysites and then recursively allow only the web1 folder:

chcon -v –type=httpd_sys_content_t /mysites

chcon -Rv –type=httpd_sys_content_t /mysites/web1

Now restart apache and the warning should be gone.

Note: This barely scratches the surface of SELinux, but is a good starting point for learning how to us it, and making changes to the policies. For more information, the CentOS documentation is probably a little more straightforward than the Red Hat documents, and can be found here:

http://wiki.centos.org/HowTos/SELinux

A final thought

Various arguments have been put forward that suggest that the increased setup/support complexity and time/money spent configuring a system using SELinux, compared to the normal risk factor of a well-tuned Linux system, simply aren’t justified. The risk is already low enough, without needing to use military grade security measures, and potentially increasing your other overheads as a result. Certainly, in a non-commerce deployment, it’s probably excessive to the point of overkill.

Using SELinux definitely isn’t something to be entered into lightly, and it needs to be a consideration during the initial server build, not something that is retroactively applied to an existing server. But, if you deal in high value financial data, such as banking, SELinux is a security option you might want to investigate further.