SELinux [Electronic resources] نسخه متنی

6.1 The SELinux Role-Based Access Control Model

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.