next up previous contents
Next: Flexibility in Labeling Decisions Up: Overview Previous: Overview   Contents


Encapsulation of Security Policy

In the Flask architecture, the security policy logic is encapsulated within a separate component of the operating system with a general interface for obtaining security policy decisions. This separate component is referred to as the security server due to its origins as a user-space server running on a microkernel. In the Linux implementation, the security server is merely a kernel subsystem. The other kernel subsystems are referred to as object managers in the architecture.

The Flask architecture specifies the interfaces provided by the security server to object managers. The implementation of the security server, including any policy language it may support, are not specified by the architecture. The Linux implementation of the Flask security server defines a security policy that is a combination of Type Enforcement (TE), role-based access control (RBAC), and optionally multi-level security (MLS). The Linux security server has an associated policy language. A configuration written in this language is compiled by a separate program called checkpolicy into a binary representation read by the security server at boot time.

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) 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.

In the Linux implementation, a security context consists of 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.


next up previous contents
Next: Flexibility in Labeling Decisions Up: Overview Previous: Overview   Contents