Up to this point in the book, we’ve looked at the functions SELinux provides and the configuration files that direct its operation. However, we’ve merely glanced at the SELinux policy language that’s used to specify the SELinux security policy. Our situation is akin to that of a 15th or 16th century explorer who has studied maps of the New World and dreamed of the exotic sights that may be found there but has not yet ventured to sea. In this chapter, we at last embark upon our sea voyage.
In this chapter and the following two chapters, you’ll find a detailed explanation of the SELinux policy language and several related languages, such as those used to specify file and security contexts. This chapter explains the SELinux role-based access control policies, Chapter 7 explains the SELinux type-enforcement policies, and Chapter 8 explains other elements of the SELinux policy. Of course, most likely your goal is not merely to understand the SELinux policy language or SELinux security policies themselves, though such skills are useful to the SELinux system administrator. Instead, it’s more likely that you want to be able to specify new and modified SELinux security policies. If that is your goal, Chapter 6 through Chapter 8 won’t quite take you to the end of your voyage, though you’ll make landfall near the end of Chapter 8. Then you’ll be ready for Chapter 9, which explains how you can customize existing SELinux policies and implement your own policies.
As explained in previous chapters, the SELinux security model is based primarily on a mechanism called type enforcement (TE). Type enforcement assigns processes to domains and restricts the operations each domain is permitted to perform. The SELinux policy, which can be customized by a system administrator, specifies the available domains and the operations that processes within them are authorized to perform. Chapter 7 explains the SELinux type-enforcement model in detail.
SELinux also includes a second security model, called role-based access control (RBAC). Role-based access control works alongside type enforcement: intended operations are prohibited unless they’re explicitly authorized by both type enforcement and role-based access control. Of course, intended operations must also satisfy any requirements imposed by ordinary Linux discretionary access control mechanisms, such as file permissions.
Role-based access control works fairly simply and has three parts. First, each user is authorized for a set of roles. A user cannot enter a role other than one for which the user is authorized. Second, transitions between roles are authorized. A process can transition to a new role only if transitions between its current role and the new role are authorized. Finally, each role is authorized for a set of domains. Any attempt to enter a nonauthorized role or domain is prohibited by the SELinux security engine. Let’s consider some concrete examples.
Users are assigned roles by the
user
statement. For instance, the following statement assigns the roles
staff_r
and sysadm_r
to the
user bill
, permitting the user to enter either
role:
user bill roles { staff_r sysadm_r };
Transitions between roles are governed by
allow
statements. For instance, the following allow
statement authorizes processes running in the
staff_r
role to transition to the
sysadm_r
role:
allow staff_r sysadm_r;
Roles are authorized to enter domains by the
role
statement.
For instance, the following statement authorizes the role
sysadm_r
to enter the
ifconfig_t
domain:
role sysadm_r types ifconfig_t;
A domain can include multiple role
statements,
each authorizing one or more roles to enter the domain. Unless a
role
statement authorizes a particular role to
enter a domain, processes running in that role cannot enter the
domain.
Both type enforcement and role-based access control work by inspecting security contexts. Recall that SELinux assigns a security context to each process, as well as to each instance of other objects, such as files. A security context includes three elements:
A user
A role
A type (domain)
Thus, at any time, the security context of a process indicates its
user identity and role identity, the characteristics considered by
role-based access control. A process can change its user or role
identity, but only if the current SELinux policy enables the specific
transition. For instance, SELinux policies typically permit changing
from the staff_r
role to the
sysadm_r
role, but prohibit other roles (such as
user_r
) from changing to
sysadm_r
.
Similarly, SELinux policies restrict access to domains, allowing only
processes running in specified roles to enter them. For instance, the
ifconfig_t
domain is authorized to perform various
operations that concern network interfaces, which ordinary users
should not generally be allowed to perform. Thus, entry to the domain
is restricted to processes running in the sysadm_r
role, which includes only users designated as system administrators.
Role-based access control governs processes rather than files or
other objects. So the security contexts of files and other objects
are simplified. Although these security contexts contain the three
elements common to all security contexts, the role associated with
objects other than processes is object_r
, which is
basically a mere placeholder.
The statements that express the SELinux role-based access control policy provide more elaborate options than shown in the preceding examples. To fully explain them, the following section introduces a visual representation of syntax: the railroad diagram.