Understanding Security Enhanced Linux

With traditional UNIX and Linux systems, when a user got root access to your computer, he owned the machine. The root user (or whoever took over as root user) could override ownership, read/write/execute permissions, and processor scheduling priorities. Likewise, an attack on a Web server (httpd daemon) could allow an attacker full privileges of the apache user account, instead of limiting the attack to a single set of virtual host resources.

Organizations such as the United States National Security Agency (NSA) recognized the need to have operating systems in secure environments be able to separate information in terms of confidentiality and data integrity. The standard security model made Linux and UNIX systems unacceptable for highly secure environments, where the risk of one exploit taking down the whole operating system was unacceptable. The mechanism that NSA recommended to implement highly-secure systems is referred to as Mandatory Access Control (MAC).

The SELinux project aims at providing MAC functionality into the Linux kernel. By implementing rules for what all operating system components can and can't do, an application that has security flaws or has been taken over for malicious intent can be contained. In other words, gaining control of one component of a system doesn't allow a cracker to take over the entire computer.

Types and roles in SELinux

The mechanisms for implementing security rules in SELinux are referred to as policies. Using policy configuration files, SELinux implements two different security models: Type Enforcement (TE) and Role-Based Access Control (RBAC).

• Type Enforcement — Under the TE model, every object in the operating system is bound to a security attribute called a type. Every process is bound to a security attribute called a domain. This approach allows for very tight control of every object in the operating system. Every user is allowed to access objects in the operating system based on the domain in which he or she is allowed to operate.

• Role-Based Access Control — Using the RBAC model, SELinux lets each user operate in a specific role. The roles are arranged in a hierarchy, with specific permissions associated with each role provided by type enforcement.

In traditional Linux, a user is assigned a specific user ID (UID) and group ID (GID), which affords that user certain access to system resources. For instance, it gives the user certain rights to read, write, or execute files and directories based on whether that user owns the file or directory or is part of a group assigned to that file or directory.

In SELinux, a data file, directory, or application can have many more attributes associated with it. Those attributes might actually give more permissions to access the component than were available in traditional Linux security. At the same time, having access to the component wouldn't necessarily give that user control of that component in a way that could be exploited beyond what the security policies allow the user to do.

Users in SELinux

The model that SELinux uses to define the rights that users have on an SELinux-enabled system can co-exist with the existing Linux user model, rather than replace it. With SELinux enabled, Linux user still have their accounts defined through definitions in the /etc/passwd file. A user that is also assigned a role in SELinux is referred to as a Defined User.

Special user identities in SELinux include the system_u (which is the user identity assigned to system processes) and user_u (which is the assignment used to indicate if general users, in particular those without specific user identities, are allowed to use the feature in question). There is also a root identity, which is retained to allow compatibility with existing file contexts to remain valid if they have root as their user identity.

Policies in SELinux

As noted earlier, with Fedora Core 3 you have the choice of either turning off SELinux or turning it on with the targeted (which is on by default) or strict set of policies enforced. The values set in the /etc/selinux/config determine whether or not SELinux is:

• enforcing — The current SELinux policy is turned on and its policies are enforced.

• permissive — The current SELinux policy is on, but not enforced (so you only see warning messages describing how the policy would be enforced).

• disabled — SELinux is off, so only standard Linux permissions are enforced (as they always were on systems not including SELinux).

Fedora Core 3 contains both a compiled policy file and the source files used to create that policy file for the two policy sets it delivers. For example, for the targeted policy set, /etc/selinux/targeted/policy/policy.18 is the compiled policy set used when that policy is active. If you want to make changes to that set of policies, the source files are contained in the /etc/selinux/targeted/src directory. (Replace targeted with strict in both cases if you are interested in the strict policy set.)

Tools in SELinux

Tools available with SELinux let you work with and change policy settings in SELinux. Tools include the following:

• system-config-securitylevel — Graphical interface for modifying SELinux settings

• seinfo — Prints policy statistics

• sepcut — Graphical policy customization tool

• sesearch — Searches type enforcement rules in SELinux policies

• seuser — Works with users and roles associated with a policy

• seuseradd — Adds SELinux features to the useradd tool for adding Linux users

• seusermod — Adds SELinux features to the usermod tool for modifying Linux user accounts

• seuserdel — Adds SELinux features to the userdel tool for deleting Linux user accounts

• seaudit — Graphical audit tool for analyzing log files for SELinux

I recommend that you go through the following procedure for getting started with SELinux. It will help you understand how SELinux works and the tools that are available.