Section 5.1. Type Enforcement

5.1. Type Enforcement

The majority of a SELinux policy is a set of statements and rules that collectively define the type enforcement (TE) policy. A well-defined, strict TE policy can contain tens of thousands of TE rules. The large number of TE rules is not surprising because they express all the allowed access to resources exposed by the Linux kernel. This means, for example, that every access attempt by every process to every file succeeds only if there is at least one TE rule allowing that access. If we think about the number of processes and resources on a modern Linux system, we will understand why TE rules can be numerous. When we add the audit configuration and labeling controlled by TE rules, it is not uncommon for a highly restrictive SELinux policy to contain tens of thousands of rules, although smaller policies are also common. In Part III, we discuss methods for managing and building this large set of rules; for now let's understand how the TE rules work.

The sheer number of TE rules can make understanding SELinux policies challenging, but the rules themselves are not complex. There are a relatively few varieties, and they all fall into two basic categories: access vector (AV) and type rules. We use AV rules to allow or audit access between two types. We use the type rules to control default labeling decisions under certain circumstances.

As their name implies, TE rules operate on types, which are associated with all resources via a security context. The policy language includes additional statements that allow us to define types and related policy components.

An important concept of SELinux is that TE rules associate privileges and accesses with programs, not users. All the SELinux policy language features we discuss in this chapter deal with the access of subjects (normally running programs) to objects (files, dir, sockets, and so on). This focus on programs for access control decisions is important and one of the primary benefits of SELinux. It allows the SELinux policy author to make decisions about access based on the function and security properties of programs in addition to the total access that a user needs to accomplish tasks. A program can be restricted to the minimum access permissions required to function properly, so that even if it malfunctions or has been exploited, the security of the system as a whole is not necessarily compromised. For example, if the policy for a Web server prevents it from modifying the files it displays, then even if the server is exploited, the TE policy can prevent the exploited server from changing those files. This limits the threat of defacing a Web site through a vulnerability in the Web server. The security of the system in this example is largely maintained even in the face of an exploited application. Only the exploited application is affected, and it is limited to the access we defined in the policy.

Users are not entirely ignored by SELinux. It is possible for the policy to specify multiple domain types (and thus differing sets of privilege) for the same program based on the user who runs the program. This allows for the concept of roles, which we discuss further in Chapter 6, "Roles and Users." Nonetheless, the level of access control is still based on the program's domain type and not the user's privileges.

The implications of the shift of focus from users to programs can hardly be understated; it allows us to address some of the fundamental challenges in computer security. The benefits are clear, but it does require thinking about access control in a way that is new to many people. As you read this chapter, it will help if you keep the focus on program access in mind. Additionally, if you are uncertain about the basic concepts of type enforcement, you should review Chapter 2, "Concepts," before continuing. In this chapter, we provide the details necessary to enable you to write TE rules; we assume that you understand the basic concepts of SELinux and type enforcement as discussed in Chapter 2.