2.4 Access Decisions

     

The SELinux security server makes two basic kinds of decisions:

Access decisions

Access decisions determine whether a given subject is allowed to perform a given operation on a given object.

Transition decisions

Transition decisions, also called labeling decisions , determine the types assigned to newly created objects, particularly processes and files.

This section explains access decisions ”the more frequently made and important of the two kinds of decisions ”and the following section explains transition decisions.

Conceptually, each object class has an associated bitmap called an access vector , containing one bit for each action defined for the class. Figure 2-3 shows a simplified bitmap for the file class. An actual bitmap for the file class would include each of the more than one dozen actions defined for the file class, rather than merely the common actions shown in the figure.

Figure 2-3. A simplified access vector for the file class

As explained earlier in this chapter, the SELinux security server makes access decisions by considering the security context of the subject and object of the action, the security class of the object, and the action requested . When the security server has made the access decision, it returns an access vector that indicates the allowed actions. More precisely, if the security server finds one or more policy rules matching the request, it returns three related access vectors, as shown in Figure 2-4. In the figure, the server has granted the subject permission to append to the object or create the object.

Figure 2-4. A simplified access vector resulting from an access decision

The three access vectors have the following functions:

Allow

The allow access vector identifies operations that the subject is permitted to perform on the object. No log entry is made of the operation.

Auditallow

The auditallow access vector causes a log entry to be made when the indicated operation is performed. Despite its name , it doesn't allow any operation; only the Allow vector does so.

Dontaudit

The dontaudit access vector identifies operations that the subject is not permitted to perform on the object, but that don't cause the denial to be logged.

Three rules govern access to objects:

• A requested action is denied unless the security server returns allow . Therefore, requests that have no matching policy rule are denied.

• If an action is denied, a log entry is made unless the security server returns dontaudit .

• If the security server returns auditallow , a log entry is made.

Table 2-3 summarizes the rules governing access to objects.

Table 2-3. Access to objects

Result	Access permitted	Result logged
No matching policy rule	No	Yes
allow	Yes	No, unless auditallow also specified
auditallow	No, unless allow also specified	Yes
dontaudit	No	No

To improve the efficiency of its operation, the security server caches access vectors in a data structure called the access vector cache (AVC).