Since the content and format of security labels are dependent on the particular security policy, the Flask architecture defines two policy-independent data types for security labels: the security context and the security identifier. A security context is a variable-length string representation of the security label. Internally, the security server stores a security context as a structure using a private data type. A security identifier (SID or security_id_t) is an integer that is mapped by the security server to a security context. Flask object managers are responsible for binding security labels to their objects, so they bind SIDs to active kernel objects. The file system object manager must also maintain a persistent binding between files and security contexts. Since the object managers handle SIDs and security contexts opaquely, a change in the format or content of security labels does not require any changes to the object managers.
The Flask architecture merely specifies the interfaces provided by the security server to the object managers. The implementation of the security server, including any policy language it may support, are not specified by the architecture. The SELinux example security server defines a security policy that is a combination of Type Enforcement (TE) [8], role-based access control (RBAC) [11], and optionally multi-level security (MLS) [7]. The example configuration for the TE and RBAC policy components is described in Section 5. The SELinux example security server defines a security context as containing a user identity, a role, a type, and optionally a MLS level or range. Roles are only relevant for processes, so file security contexts have a generic object_r role. The security server only provides SIDs for security contexts with legal combinations of user, role, type, and level or range. The individual attributes of the security context are not manipulated by the object managers.
The user identity attribute in the security context is independent of the ordinary Linux user identity attributes. Modifications to the Linux login program and cron daemon are provided to set this new user identity attribute appropriately for login sessions and user cron jobs. By using a separate user identity attribute, the SELinux mandatory access controls remain completely orthogonal to the existing Linux access controls. SELinux can enforce rigorous controls over changes in its user identity attribute without affecting compatibility with existing applications.