Section 7.1. A Closer Look at the Access Decision Algorithm

7.1. A Closer Look at the Access Decision Algorithm

To understand the purpose of constraints, let's revisit the SELinux Linux Security Module (LSM). Recall the SELinux kernel architecture discussed in Chapter 3, "Architecture," the salient portion of which is depicted again in Figure 7-1.

Figure 7-1. Review of the SELinux LSM module

We want to take a closer look at how the access decision logic works within the security server. The access vector cache (AVC)^[1] is keyed by a triple of source security identifier (SID), target SID, and object class. SIDs are internal references to security contexts (see the sidebar on page 151).

^[1] See linux-2.6/security/selinux/avc.c.

Security Contexts and SIDs

SELinux implements the Flask security architecture, which provides a framework for implementing enhanced access control but remains security policy neutral. This means that the AVC and its interfaces with the LSM hooks are not specifically tied to type enforcement (TE) and the other security policies SELinux implements. As far as the AVC is concerned, a security identifier is an opaque unique reference to a set of security credentials. The AVC caches access decision results indexed by source and target SIDs as well as object class identifier.

The SELinux security server applies semantic meaning to SIDs by internally associating security contexts with SIDs. Thus, SELinux can use SIDs to find type, user, and role identifiers while the AVC and the LSM hook interfaces can remain ignorant of these details.

In the source code, you can see the policy-neutral portions of the SELinux LSM module, including the AVC, in linux-2.6/security/selinux/*.c and the policy-specific portions (that is, the security server) in linux-2.6/security/selinux/ss/*.

When the SELinux LSM hooks ^[2] ask for an access decision, they provide the SIDs of the subject (source) and object (target) and the object class. The AVC uses the SID-SID-class triple to look up allowed access, which is stored as a bit mask.

^[2] See linux-2.6/security/selinux/hooks.c.

When a cache miss occurs, the AVC calls the security server function security_compute_av()^[3] to determine allowed access. This function has two basic steps in its access decision logic: 1) create a mask representing the object permissions allowed according to the TE allow rules for the type-type-class triple, and 2) remove from the allowed mask those permissions disallowed by any constraint. This second step allows a constraint to be a means to restrict permissions that otherwise would be allowed by the policy.

^[3] See linux-2.6/security/selinux/ss/services.c.

The primary purpose of constraints is to enforce global restrictions for certain permissions regardless of the allow rules in the policy. All constraints are checked each time the security_compute_av() function is called before returning the allowed access mask to the AVC. So, as you can see, constraints further limit the access allowed in an SELinux policy.

SELinux has two types of constraints. The constrain statement is the most common constraint and enables you to further restrict access based on the user, role, and/or type of the source and target security contexts. The validatetrans statement is a more recent addition to SELinux and enables you to further restrict access for security context change events based on the old, new, and process security context.

Note

At the time of this writing, the apol tool does not support constraints. Therefore, you cannot view these statements with that tool. Support for constraints is planned and should be available in the future.