Security Enhanced Linux

Security Enhanced Linux (SELinux) is a new feature of Fedora Core 2. As such, it is changing rapidly , and there are few tools available to help the beginner configure their system. The information in the following section may, therefore, become outdated before the rest of the book.

What Is SELinux?

SELinux is a version of Linux that has been developed by the U.S. Government's National Security Agency (NSA) that incorporates some of its research into computer security issues and implements "Mandatory Access Controls" (more on this later). Fedora Core 2 supports SELinux and comes with a usable default configuration that can be customized to suit your requirements.

SELinux enhances security by restricting the access users and processes have to files, directories, and other objects (for example, network interfaces) according to a set of security policies. A key feature of the SELinux security model is that all users are treated in the same way, including the root user; no user can bypass the security policies. This is what makes the access controls mandatory . (It is quite possible for the root user to be denied access to a file if such access would violate the security policy).

Traditional (that is, not Security-Enhanced) Linux systems are only as strong as their weakest point. Once the root account is compromised, an attacker has complete control over the machine. Figure 10-23 illustrates how dangerous this can be. The attacker (1) exploits a weakness (for example, an error in the configuration or a programming error) in one of the publicly accessible services running on the traditional Linux system. A successful attack allows them to gain root access (2). With root access, the attacker can do anything they wish, such as modifying Web pages (3) or using the compromised system to relay spam e-mail (4).

Figure 10-23

In an SELinux system, the three services in the example (Web, Mail, and Name servers) are given different types (as indicated by the heavy lines in the Figure 10-24). The security policy rules are defined so that the server processes are only allowed to access the objects (files, directories, devices, and so on) they need to perform their task. This effectively constrains each service to run within its own box on the diagram. Should an attacker successfully compromise a vulnerable service (1), they are severely restricted as to what they can do with that access (2).

Figure 10-24

So SELinux does not particularly help with removing vulnerabilities from specific programs, but it does much to limit the damage caused if a vulnerable service is compromised and offers tighter control over who can make changes to configuration files.

If you like analogies , here s one that may help. You can think of an SELinux system as being like a ship whose hold is divided up into separate watertight compartments, with locked doors in between. If the ship gets a hole, one compartment might flood, but the doors will prevent other compartments from being affected, and the ship stays afloat. On an SELinux system, a successful attack on one service does not allow other services to be affected. A traditional Linux system, however, is like a ship with a single large hold; put a hole in it and the ship will sink.

Do I Need SELinux?

Now that you understand a little about what SELinux can do for you, you can decide if it is appropriate for your situation. As in all security matters, the decision comes down to whether the benefit of SELinux s ability to enforce access controls outweighs the cost of implementing SELinux (in terms of theextra work required to learn about, set up, and maintain the security configuration).

If, for example, you have a Fedora Core 2 system that is running several services (such as the ones used in the preceding illustrations) that are accessible from the Internet, SELinux may offer considerable benefits to you. If, however, you are running a Fedora Core 2 system on a trusted network providing just a single service, the SELinux may be less appropriate.

SELinux Basics

SELinux introduces some new terms and concepts for the Fedora Core 2 system administrator. These are explained in the following table.

Term	Meaning
Subject	A process, program, or user that can perform an action.
Object	A file, directory, device, and so on, on which one or more subjects can perform actions.
Type	A security attribute that SELinux attaches to a subject or object. (In other implementations , processes are given domains rather than types. )
Context	A collection of security attributes associated with a subject or object. Contexts for files are set by labeling them with a security context. Such security contexts are persistent (that is, they are not changed by reboots and so on). A context comprises three values: the user identity, the role, and the type (or domain). These values are displayed separated by colons (:), as in the following example: system_u:system_r:ntpd_t This example has a user identity of system_u , a role of system_r and a type of ntpd_t .
Policy	A set of rules that define the permitted behavior of the system, including what actions subjects can perform on objects, what roles a user can have, and what transitions are allowed between domains. The default configuration of SELinux on Fedora Core 2 contains nearly 300,000 rules. (Fortunately, these are generated automatically from human-readable configuration files found in /etc/security/selinux/src/policy using Makefiles).
Security Identifier (SID)	An integer that maps to a security context. The SELinux code automatically assigns these integers and uses them to speed up the process of making security decisions (comparing the security contexts of a subject and object and deciding whether to allow or deny the access).
User Identity	The SELinux user space is different to the Fedora Core 2 user space. For example, a system may have 100 login users defined, but just three SELinux users (an ordinary user, an application administrator, and a system administrator).
Role	Users are authorized for a set of roles (through a User Identity), and these roles are checked against the security context of an object to determine what actions a user can perform.
Enforcing mode	SELinux denies actions that are not permitted by the security policy. This is the mode that SELinux needs to be operating in to provide enhanced security to your Fedora Core 2 system. The /etc/sysconfig/selinux file controls what mode SELinux will start in at the next boot. The command setenforce 1 turns on enforcing mode on a running system. The command sestatus shows the current mode SELinux is running in.
Permissive mode	SELinux logs actions that it would deny in enforcing mode using syslog, but the action is allowed (so there is no additional security compared to a non-SELinux system). This mode is there to help with the configuration of the security policy. The command setenforce 0 turns on permissive mode on a running system.

New and Updated Commands

There are several new commands for managing the new SELinux security environment. You have already been introduced to the setenforce command that can be used to change the mode that SELinux is operating in. Other useful new commands include chcon , for changing the context of a file ordirectory, and newrole , for switching the current shell to a different role (a sort of su command for the SELinux environment).

Many commands in Fedora Core 2 have been updated to make them SELinux aware, and there are also several new commands for managing the new security model. Often, the updated commands have a -Z or --context switch to show the SELinux context information in the output.

Try It Out Finding the Security Context

To find out the security context of your current shell, run the following command:

 id --context 

(Or id -Z , if you prefer.)

To find out the security context of the files in the current working directory, run the following command:

 ls --context 

(Again, ls -Z works, too.)

To see what security contexts the processes running on your machine have, run the following command:

 ps -e --context 

(Or ps -e -Z .)

Changing the SELinux Policy Rules

Anyone who is contemplating changing the SELinux policy should read the document Confguring the SELinux Policy by Stephen Smalley (you can find this at www.nsa.gov/selinux/papers/policy2-abs.cfm in a variety of formats). This document is an excellent introduction to the concepts found in SELinux, and the last section contains examples of adding users, permissions, and programs, as well as the more advanced tasks of creating new domains, types, and roles.

Where to Find Out More

Many useful sources of information on SELinux exist on the Internet; only a few are listed here:

• www.nsa.gov/selinux ”U.S. Government National Security Agency (the creators of SELinux)

• www.crypt.gen.nz/selinux/faq.html ”The Unofficial SELinux FAQ

• [e-mail] ”Fedora SELinux mailing list