next up previous
Next: Support for Policy Changes Up: Security Architecture Previous: Flexibility in Labeling Decisions


Flexibility in Access Decisions

Figure: Interface for obtaining access decisions from the security server. The input parameters are a pair of SIDs, the class of the object, and the set of requested permissions. The pair of SIDs may be subject-to-object, subject-to-subject, or even object-to-object. The granted permissions are returned as output parameters.
\begin{figure}\begin{center}
\begin{footnotesize}
\begin{verbatim}int security...
...decided,
__u32 *seqno);\end{verbatim}\end{footnotesize}\end{center}\end{figure}

Figure: AVC interface and example call to check permissions. The input parameters are the same as for security_compute_av, except for the additional aeref parameter. On its first use, the aeref parameter is set to refer to the AVC entry used for the permission check, and on subsequent checks this reference is used to optimize the lookup. The reference is revalidated on each use to ensure its correctness.
\begin{figure}\begin{center}
\begin{footnotesize}
\begin{verbatim}extern inlin...
...CKET__BIND,
&sk->avcr);\end{verbatim}\end{footnotesize}\end{center}\end{figure}

Object managers consult the AVC to check permissions based on a pair of labels and an object class, and the AVC obtains access decisions from the security server as needed. Figure 2 shows the security server's security_compute_av interface for obtaining access decisions. Figure 3 shows the AVC's avc_has_perm_ref interface for checking permissions and an example call to this interface to check bind permission to a socket.

Each object class has a set of associated permissions. These permission sets are represented by a bitmap called an access vector (access_vector_t). Flask defines a distinct permission for each service, and when a service accesses multiple objects, Flask defines a separate permission to control access to each object. For example, when a file is unlinked, Flask checks remove_name permission to the directory and unlink permission to the file.

The use of object classes in access requests allows distinct permission sets to be defined for each kind of object based on the particular services that are supported by the object. It also allows the security policy to make distinctions based on the kind of object, so that access to a device special file can be distinguished from access to a regular file and access to a raw IP socket can be distinguished from access to a UDP or TCP socket.


next up previous
Next: Support for Policy Changes Up: Security Architecture Previous: Flexibility in Labeling Decisions