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.
|
