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

2.2 Security Contexts

The discussion in the preceding section
might lead you to believe that SELinux makes security decisions based
on the identity of individual subjects and objects. In principle,
such a system could be made to work. But the system would be
unnecessarily unwieldy. Because processes related to a single program
can generally be treated the same, it's more
convenient to make security decisions based on sets or classes of
subjects and objects rather than on individual objects. For example,
every instance of the SSH server should generally be given the same
permissions, including read access to
/etc/ssh/sshd_config. Similarly, all the files
within a given directory often can be manipulated by the same
subject. For example, the DHCP service should be permitted to
manipulate any of the files in /var/state/dhcp.
To simplify decision making, similar subjects can be grouped and
similar objects can be grouped.

SELinux associates information called security
attributes with subjects and objects and bases its
security decisions on the values of these attributes. Three security
attributes are used:

User identity

The user identity indicates the SELinux user
account associated with a subject or object. In the case of a
subject, the user identity gives the SELinux user account under which
the process is running. In the case of an object, the user identity
gives the user account that owns the object.

In tracking user identities, SELinux does not use the list of user
accounts maintained by Linux in /etc/passwd.
Instead, it uses its own database and a mapping that associates
SELinux users with Linux users. This approach is consistent with the
philosophy that Linux access controls and SELinux access controls
should be completely separate, so that changes to one
don't affect the other. One important benefit of
keeping separate user account
databases is that changes to /etc/passwd
don't invalidate the SELinux security attributes of
subjects and objects. Keeping separate user databases is not as
cumbersome as it may seem, because most systems can be configured to
use only a handful of SELinux user accounts. That is, many Linux user
accounts can often be mapped to a single SELinux user account.

Role

Under SELinux, users are authorized to enter
one or more roles, each of which defines a set of permissions a user
can be granted. At a given time, a user can reside in only a single
role. A user can transition from one authorized role to another by
using the special command newrole. This command
changes the user's SELinux role similar to the way
the Linux su command changes a
user's Linux identity. SELinux establishes a special
role, sysadm_r
, used for administering SELinux
facilities.

Type

Types, which are also known as
domains, divide subjects and
objects into related groups. Types are the primary security attribute
SELinux uses in making authorization decisions. They establish the
sandboxes that constrain processes and prevent privilege escalation.
Therefore, you can think of a type as naming a related sandbox.

In SELinux whitepapers, such as those available at the NSA web site
and elsewhere, you may read that type and
domain are distinct concepts that must never be
confused. The original Flask modeland other computer security
modelsdo carefully distinguish these terms. However, in
SELinux the terms are synonymous, notwithstanding claims to the
contrary.

Types are the workhorse security attribute: an SELinux policy
typically defines only a handful of users and roles, but dozens or
even hundreds of types.

Conventions help in distinguishing names that represent users, roles,
and types. Table 2-2 summarizes the
conventions.

Table 2-2. Naming conventions for security attributes

Security attribute

Standard name suffix

Example name

User

(None)

root

Role

_r

sysadm_r

Type

_t

sysadm_t

The three SELinux security attributesuser identity, role, and
typetogether make up what's called a
security context. For convenience and
efficiency, SELinux stores security contexts in a table. A

security
identifier (SID) identifies each table entry. Earlier, I
implied that SELinux bases security decisions on security contexts.
This is approximately correct. But, more precisely, SELinux makes
security decisions based on SIDs rather than security contexts,
thereby gaining some efficiency since SIDs are represented as
integers and are therefore efficiently manipulated by the CPU.

Sometimes, a security context is loosely referred to as an SID.
Because there is a one-to-one correspondence between security
contexts and SIDs, such references are not too harmful or confusing.

During system initialization, the security context table is preloaded
with a small number of SID values. These values are called
initial SIDs.

Because subjects are active, they often can take on a variety of
roles. Objects, on the other hand, are passive and seldom have need
of roles. However, every subject or object must possess all three
security attributes (user, role, and type). Objects that have no
other need of a role are assigned the dummy role
object_r
.