While SELinux supports a variety of access control policy models [21], the main focus of SELinux policy development has been an extended Type Enforcement (TE) model [1,5,20]. In this section, we provide a brief overview of the SELinux policy model concepts, focusing only on the concepts that are relevant to the analysis that we perform. A number of other concepts are represented in the SELinux extended TE model, such as roles and identity descriptors, that we do not cover here. A detailed description of the SELinux policy model is given elsewhere [20].
The traditional TE model has subject types (e.g., processes) and object types (e.g., files, sockets, etc.), and access control is represented by the permissions of the subject types to the object types. In SELinux, the distinction between subject and object types has been dropped, so there is only one set of types that are object types and may also act as subject types.
The SELinux extended TE model is shown in Figure 1. All objects are labeled with a type. All objects are an instance of a particular class (i.e., data type) which has its own set of operations. A permission associates a type, a class, and an operation set (a subset of the class's operations). Thus, permissions associated with SELinux types can be applied independently to different classes. For example, different rights can be granted to a user's files than to their directories. In fact, since the objects are of different classes, they have different operations. Should the administrator want to give different access rights to two objects of the same class, then these objects must belong to different types.
Permission for a (subject) type to perform operations on a(n) (object) type are granted by the allow statement. Any element of the permission relationship can be expressed using this statement, so the expression of least privilege rights is possible. The dontaudit statement provides a variation on the basic permission assignment. A combination of allow statements result in a union of the rights specified, whereas a combination of dontaudit statements on the same type pair and class are intersected.
In addition, the extended TE model also has type attributes that represent a set of types (i.e., all the types with that attribute assigned). Type attributes enable assignment to multiple types at a time. For example, a permission can be assigned to each subject type with that attribute or a subject can be assigned permission to each object type with that attribute.
Containment is enforced by limiting the permissions accessible to a subject type (as described above), limiting the relabeling of object types, and limiting the domain transitions that can be made by a subject type. Relabel rights are controlled in SELinux by limiting access to relabelfrom and relabelto operations. As the names indicate, relabelto enables objects to be relabeled to that type and relabelfrom enables objects of a particular type to be relabeled.
Domain transitions can occur when a subject type executes a new program. Again, SELinux defines an operation, called transition, to perform these transitions. A subject type must have a transition permission for the resultant subject type in order to affect a domain transition.
The SELinux model also has statements for type transition and type change. Type transition statements are used by SELinux to automatically compute transitions, but are not necessary for control (i.e., transition permissions are always necessary). Type change statements alter the type of an object upon access by the specified subject type. Such statements are useful when a system administrator logins in using a user's tty. Type change statements transition the object type of the tty to prevent users from altering input.
In order to simplify the task of expressing policies, the SELinux extended TE model also includes a large number of macros for expressing sets of policy statements that commonly occur together. We do not examine the policy macros in detail because policy analysis requires us to understand the policy at the level of the type enforcement model statements (i.e., which subject types can perform which operations on which object types).