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 model ”and other computer security models ”do 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 attributes ”user identity, role, and type ”together 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 .



SELinux. NSA's Open Source Security Enhanced Linux
Selinux: NSAs Open Source Security Enhanced Linux
ISBN: 0596007167
EAN: 2147483647
Year: 2003
Pages: 100
Authors: Bill McCarty

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net