The Flask architecture is sufficiently general to support many models of mandatory access control. A particular model must be chosen for every implementation of the security server. Once selected, a security server is constructed that makes all security relevant decisions in the context of that model. The security server is cleanly separated from the rest of the kernel, hidden behind a well-defined interface. This section describes the security server that was implemented for SELinux.
In choosing the security model for a security server implementation, care should be taken to ensure that it is sufficiently expressive to meet whatever security objectives are expected. The flexibility of the Flask architecture allows the security server to be modified, or even replaced, to alter the supported security model to meet additional requirements. The complete encapsulation of the security policy logic within the security server makes this possible without any impact on the rest of the system.
The content and format of labels used in the system depend on the particular security model implemented by the security server. Security decisions within the security server are based on security contexts which represent security labels. A security context is a policy independent data type that can be handled by different parts of the system but should only be interpreted by the security server. It contains all of the security attributes associated with a particular labeled object that are relevant to the policy decision logic.
Security contexts are usually not bound directly to objects. A second policy-independent data type called a security identifier (SID) is bound to each object that requires a label. SIDs are nonglobal and nonpersistent opaque objects that are mapped to security contexts. This mapping is created at run time and maintained by the security server. When an object is created, the security server decides which SID to use as a label. SIDs associated with objects are passed into the security server and used as the basis for security decisions.
The mandatory access controls of SELinux are implemented as permission checks that have been inserted at control points throughout the Linux kernel. Approximately 140 fine-grained permissions, grouped into 28 object classes, have been defined to allow the control of nearly every system operation. Examples of permissions are the transition and signal permissions in the process class or create and write permissions in the file class. Permission checks are made between a source SID and a target SID for a particular permission in some object class. Usually, but not always, these are the SIDs associated with a calling process and some object, like a file, that is being accessed. To respond to permission checks, the security server's policy logic uses the security relevant attributes contained in the security contexts associated with the source and target SIDs to determine if a permission can be granted.