Docs/Drafts/SELinux User Guide/SELinux Implementation Phase/Introduction

Introduction

On Linux® operating systems, everything is represented as a file. For example, hard disk drives are represented as /dev/hdax and /dev/sdax files, and processes, such as Mozilla® Firefox® and the Apache HTTP Server, are represented as files in the proc file system (/proc/). Files are called objects, and processes (including users) are called subjects. Linux operating systems use a Discretionary Access Control (DAC) system that controls how subjects interact and access objects. On systems using DAC, users control the permissions of objects (files and directories) that they own. They could, for example, make their home directories world-readable, giving subjects (users and processes) access to potentially sensitive information.

The following is an example of permissions used on a Linux operating system that does not run SELinux. Use the ls -l command to view object (file) permissions:

-rwxrw-r-- 1 user1 group1 0 Aug 18 10:08 file1

The first three permission bits, rwx, control the access the Linux user1 user (in this case, the owner) has to the file1 object. The next three permission bits, rw-, control the access the Linux group1 group has to the file1 object. The last three permission bits, r--, control the access everyone else has to the file1 object. This includes all subjects (users and processes). By default, when a new object (a file) is created, everyone has read permissions. If objects have read permissions, and their parent folder allows everyone read and execute permissions, all subjects (users and processes) have read access to these objects. This is not desirable. Note: on Fedora 10, by default, home directories only allow read, write, and execute permissions to the owner. Other subjects, excluding the Linux user root, do not have access. Also, the permissions in these examples may differ from your system. These examples purposely change the permissions to differentiate between the permissions of the owner, group, and everyone else.

Security-Enhanced Linux (SELinux) adds Mandatory Access Control (MAC) to the Linux kernel. Stepping beyond traditional UNIX® permissions, MAC systems add fine-grained controls for defining a user's access to objects, such as files and directories. On systems running SELinux, all objects, and therefore everything on the system, are labeled with an SELinux context, that contains additional information, which is used to make access control decisions, for example, whether a subject (a process) has access to open an object (a file).

The following is an example of the additional SELinux information used on Linux operating systems that use SELinux. This information is called the SELinux context, and is viewed using the ls -Z command:

-rwxrw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0      file1

In this example, SELinux provides a user (unconfined_u), a role (object_r), a type (user_home_t), and a category (s0). This information is used to make access control decisions. On DAC systems, only the Linux user and group ID are used to make access decisions. SELinux allow and denying rules are checked after DAC rules. SELinux allow and deny rules are not used if DAC rules deny access first.

Linux and SELinux users

On systems running SELinux, there are standard Linux users, as well as SELinux users. SELinux users are part of the SELinux context (the additional labels on subjects and objects), and are mapped to regular Linux users. To avoid confusion, this guide uses "Linux user" and "SELinux user" to differentiate between the two.

Benefits of running SELinux

SELinux provides:

• An additional layer of security: a system where subjects (processes) are separated from each other by running in their own domains, and rules define how subjects interact and access objects (files). Actions, such as a subject opening an object, are only allowed if a rule exists that specifically allows it.

• Fine-grained access control. SELinux allow and deny rules are not used if DAC rules deny access first.

• Type Enforcement®. All subjects and objects are labeled with a type. Rules define how types interact and access each other. Access is only allowed if a rule exists that specifically allows it.

• Prevention against privilege escalation. Since subjects run in domains, and are therefore separated from each other, and rules determine how subjects access objects, if a service is compromised, the attacker only has access to the normal functions of that service, and to files that the service has been configured to have access to. For example, if the Apache HTTP Server is compromised, an attacker is unable to read files in user home directories, unless a specific rule was added or configured to allow such access.

SELinux is not:

• Antivirus software.

• A replacement for passwords, firewalls, or other security systems.

• An all-in-one security solution.

SELinux is an addition to DAC rules. It is designed to enhance existing security solutions, not replace them. Even when running SELinux, continue to follow good security practices, such as keeping software up-to-date, use hard-to-guess passwords, firewalls, and so on.

Examples

The following examples demonstrate how SELinux increases security:

• The default action is deny. If a rule does not exist to allow a subject access to an object, access is denied.

• Confining users: SELinux can confine Linux users. A number of restricted SELinux users exist. Linux users can be mapped to restricted SELinux users to take advantage of confined SELinux users. For example, mapping a Linux user account to the SELinux user_u user, results in a Linux user that is not able to run (unless configured otherwise) set user ID (setuid) applications, such as /usr/bin/sudo and su. Also, if configured, you can disable the execution of objects in user home directories for Linux users that are mapped to the SELinux user_u user.

• Subject (process) separation. Subjects run in their own domains. This prevents other subjects from accessing objects (files) used by other subjects. For example, when running SELinux, unless otherwise configured, an attacker can not compromise a Samba server, and then use that Samba server to read and write to objects used by other subjects, such as files comprising a website that is read by the Apache HTTP server.

• Help limit the damage done by configuration mistakes. For example, an administrator may forget to limit zone transfers when running ISC BIND; however, the default SELinux context for zone files does not allow them to be updated by zone transfers, or written to by named (the ISC BIND daemon) and other subjects.

SELinux Architecture and Performance

SELinux is a Linux kernel module. Part of this module is the SELinux security server. The security server contains policy rules, which define what access is allowed. When a subject attempts to interact with an object, for example, a process opening a file, a hook in the Linux kernel intercepts the system call the process makes to open the file. The hook communicates with the security server, to check if access should be allowed or denied. Decisions made by the security server are cached by an Access Vector Cache (AVC). This decreases how often SELinux rules in the security server need to be checked, which increases performance. SELinux has no effect if DAC rules deny access first.

SELinux has three modes: permissive, enforcing, and disabled. When running in enforcing mode, certain actions cause SELinux to deny access, and denials are logged. When running in permissive mode, access rules are checked; however, when an action occurs that would cause a denial, the denial is logged, and access is allowed. There is no noticeable performance decrease when running SELinux in permissive or enforcing mode. There is no performance decrease when SELinux is running in disabled mode, as the SELinux module is not registered with the Linux kernel.