Providing more security to Linux

Seasoned Linux administrators and security engineers already know that they need to have some trust in the users and processes on their system in order for the system to remain secure. Part of that is because users can attempt to exploit vulnerabilities found on the software running on the system, but a large part of it is because the secure state of the system depends on the behavior of the users. A Linux user with access to sensitive information can easily leak that out to the public, manipulate the behavior of the applications he launches, and can do many more things. The default access controls in place in a regular Linux system are discretionary, meaning it is up to the user's discretion how the access controls should behave.

The Linux DAC (Discretionary Access Control) mechanism is based on the user and/or group information of the process versus the user and/or group information of the file, directory, or other resource that is being manipulated. Consider the /etc/shadow file, which contains the password and account information of the local Linux accounts:

$ ls -l /etc/shadow
-rw------- 1 root root 1010 Apr 25 22:05 /etc/shadow

Without additional access control mechanisms in place, this file is readable and writable by any process that is owned by the root user, regardless of the purpose of the process on the system. The shadow file is a typical example of a sensitive file that we don't want to see leaked or abused in any other fashion. Yet, the moment someone has access to the file he can copy it elsewhere, for example, to their home directory or even mail it to his own computer and attempt to attack the password hashes stored within.

Another example of how Linux DAC requires trust from its users is when a database is hosted on the system. Database files themselves are (hopefully) only manageable by the runtime user of the database management system (DBMS) and the Linux root user. Properly secured systems will grant the additional users access to these files (for instance through sudo) by allowing these users to change their effective user ID from their personal user to the database runtime user, or even root. Those users too can analyze the database files and gain access to potentially very confidential information in the database without going through the DBMS.

But users are not the only reason of securing a system. Lots of software daemons run as the Linux root user or have significant privileges on the system. Errors within those daemons can easily lead to information leakage or might even be exploitable remote command execution vulnerabilities. Backup software, monitoring software, change management software, scheduling software, and so on, they all often run with the highest privileged account possible on a regular Linux system. Even when the administrator does not fully trust the users, their interaction with the daemons still induces a potential security risk. As such, the users still get some kind of trust in order for the system to function properly. And through that, he leaves the security of the system to the discretion of its (many) users.

Enter SELinux which provides an additional access control layer on top of the standard Linux DAC mechanism. SELinux provides a MAC (Mandatory Access Control) system that, unlike its DAC counterpart, gives the administrator full control over what is allowed on the system and what isn't. It accomplishes this by supporting a policy-driven approach on what processes are and aren't allowed to do and what not, and enforcing this policy through the Linux kernel.

The word "mandatory" here, just like the word "discretionary" before, is not chosen by accident to describe the abilities of the access control system. Both are known terms in the security research field and have been described in many other publications, including the TCSEC (Trusted Computer System Evaluation Criteria) (http://csrc.nist.gov/publications/history/dod85.pdf) standard (also known as the "Orange Book") by the Department of Defense, in the United States of America's in 1985. This publication has lead to the common criteria standard for computer security certification at (ISO/IEC 15408) http://www.commoncriteriaportal.org/cc/.

Mandatory means that access control is enforced by the operating system and defined solely by the administrator. Users and processes that do not have the permission to change the security rules cannot work around the access control; security is not left at their discretion anymore.

Linux security modules to the rescue

Consider the example of the shadow file again. A MAC system can be configured so that the file can only be read from and written to by particular processes. A user logged on as root cannot directly access the file or even move it around. He can't even change the attributes of the file:

# id
uid=0(root) gid=0(root)
# cat /etc/shadow
cat: /etc/shadow: Permission denied
# chmod a+r /etc/shadow
chmod: changing permissions of '/etc/shadow': Permission denied

This is enforced through rules that describe when the contents of a file can be read. With SELinux, these rules are defined in the SELinux policy and are loaded when the system boots. It is the Linux kernel itself that is responsible for enforcing the rules, and does so through LSM (Linux Security Modules).

High-level overview of how LSM is integrated in the Linux kernel

LSM has been available in the Linux kernel since version 2.6, somewhere in December 2003. It is a framework that provides "hooks" inside the Linux kernel on various locations, including the system call entry points, and allows a security implementation (for example, SELinux) to provide functions to be called when a hook is triggered. These functions can then do their magic (for instance, checking the policy and other information) and give a go / no go back to allow the call to go through or not. LSM by itself does not provide any security functionality, instead it relies on security implementations that do heavy lifting. SELinux is one of these implementations that uses LSM, but others such as TOMOYO Linux and AppArmor also use it.

SELinux versus regular DAC

SELinux does not change the Linux DAC implementation, nor can it override denials made by the Linux DAC permissions. If a regular system (without SELinux) prevents a particular access, there is nothing SELinux can do to override this decision. This is because the LSM hooks are triggered after the regular DAC permission checks have been done.

If you need to allow an additional user access to a file, you will need to look into other features of Linux such as the use of POSIX Access Control Lists through the setfacl and getfacl commands. These allow the user (not only the administrator!) to set additional access controls on files and directories, opening up the provided permission to additional users or groups.

Restricting root privileges

The regular Linux DAC allows for an all-powerful user: root. Unlike most other users on the system, a logged on root user has all the rights needed to fully manage the entire system, ranging from overriding access controls to controlling audit, changing user ID, managing the network, and many more. This is handled through a security concept called capabilities (for an overview of Linux capabilities, check out the capabilities manual page: man capabilities). SELinux is also able to restrict access to these capabilities in a fine-grained manner.

Due to this fine-grained authorization aspect of SELinux, even the root user can be quite confined without impacting the operations on the system. The example of accessing /etc/shadow previously is just one example of things that a powerful user as root still might not be able to do due to the SELinux access controls in place.

When SELinux was added to the mainstream Linux kernel, some security projects even went as far as providing public root shell access to a SELinux protected system, asking hackers and other security researchers to compromise the box. The ability to restrict root was welcomed by system administrators that sometimes need to pass on the root password or root shell to other users (for example, database administrators) that needed root privileges when their software went haywire. Thanks to SELinux, the administrator can now pass on a root shell while reassuring himself that the user only has those rights he needs, and not full system administration rights.

Enabling SELinux – not just a switch

To enable SELinux on a Linux system, it is not just a matter of enabling the SELinux LSM module within the Linux kernel. SELinux comprises not only of the kernel implementation, but also has libraries and utilities that are needed on the system. These libraries and utilities are called the SELinux userspace (http://userspace.selinuxproject.org/trac). Next to the userspace applications and libraries, various components on a Linux system need to be updated with SELinux-specific code, including the init system, core utilities, and the C library. And finally, we need a policy that tells SELinux how it should enforce access.

Because SELinux isn't just a switch that needs to be toggled, Linux distributions that support SELinux usually come with SELinux predefined and loaded: Fedora and RedHat Enterprise Linux (with its derivatives, for example, CentOS and Oracle Linux) are the most well-known examples. Other supporting distributions might not automatically have SELinux enabled but can easily support it through the installation of additional packages (which is the case for Debian and Ubuntu), and others have a well-documented approach on how to convert a system towards SELinux (for example, Gentoo and Arch Linux).

Throughout the book, examples will be shown from Gentoo and Fedora 19 (which is similar to RedHat Enterprise Linux). We opt to use these two because they have different implementation details, allowing us to show the full potential of SELinux.