Securing Linux: Basic SELinux Security Concepts

SELinux, or Security-Enhanced Linux, is an additional mechanism which protects the security of your system (Linux).

In a way it can be thought as a parallel permissions system to the standard permissions system. In the regular permissions models, processes run as users, and the files and other resources on the system are labeled with permissions that control which users have what access to which files.

SELinux adds a parallel set of permissions, in which each process runs with a SElinux security context, and files and other resources on the system are also labeled with a security context. The difference from normal permissions is that a configurable SELinux policy controls which process contexts can access which file contexts. Red Hat provides a default policy which most people use.

Another difference with SELinux, is that to have access to a file, you have to have both regular access and SELinux access. So, even if your process is running as the superuser, root, it may be denied access to a file or resource based on the SELinux security context of the process and of the file or resource!

This allows us to limit the scope of security compromises on the system, even to the root account, by ensuring that processes are confined by the SELinux policy and their security context into only being able to do things that they should normally authorized to do.

Normal Apache server

Here is an example of a normal system that does not have SELinux turned on, which is running Apache HTTPD server :

 The web server is available to remote access over the internet. That means that malicious people can try to break into the system through a security bug in the web server. If they succeed, they will have control of a process running as user apache and group apache. Anything readable by that user can now be accessed by that attacker. This includes files and directories that the web server normally has no business working with. A further local-only security bug in one of those may enable the attacker to gain superuser access.

So How can SELinux change this?

Apache Server secured by SE-Linux

This is the same system, with SELinux turned on. By default, the SELinux policy denies all the access, unless rules are included in the policy which permits certain processes contexts to access certain file and resource contexts. (The reference policy provided by REDHAT has a carefully tuned set of rules for production systems provided for you.)

The web server’s httpd process are labeled with SELinux context System_u:system_r:httpd_t. the important part of the context is the third colon–separated field, the SELinux type :httpd_t.

The files and resources on the system are also labeled with SELinux contexts, and again the important part is the SELinux type. For example, files in /var/www/html have the type httpd_sys_content_t. Files in /tmp and /var/tmp normally have the type tmp_t.

The SELinux policy has a rule that allows processes running as httpd_t to access files labeled as httpd_sys_content_t. There is no rule allowing those processes to access files labeled tmp_t, so those access will be denied, even if regular file permissions indicate that they should be allowed.

In order for a process to access a file, it must be permitted both by regular permissions and by the SELinux types and policy. If either regular permissions or SELinux block access, access is denied.

Note that even if you are logged in as a root! Even though root is always allowed access under regular permissions, the process may be running as a context which is blocked by SELinux.

One of the goals of SELinux is to protect the user data from system services that have been compromised. This extends even to the root account.

SELinux has a special type, unconfined_t,that ignores all SELinux restrictions. When you log in to root on the system, you are normally running as unconfined_t, allowing you to ignore all normal permissions (since you are root) and all SELinux restrictions (since you are in unconfined_t). The id command will show you your Shell’s current context instead of unconfined_t, based on the type with which the program’s executable file has been labeled.