Security contexts

SELinux enforces policy that is based on the relation of attributes of a subject to attributes of a object. These attributes are referred to as security contexts. Security contexts are a set of properties that are attached to objects and subjects. These property fields are: user, role, type, security level/security category. The combination of these fields is the security context.

Example of a simple security context:
user_u:role_r:type_t:s0

User Field:
This is the first of the four fields that make a security context. The user field has a SELinux user group. If a user is a member of the user_u user group than this field will be set to user_u. Processes that are started by the system will have a security context starting with the system_u field. Custom SELinux user groups can be created. For example if you want a user domain group to have access to specific roles than you can create a SELinux user group and define which roles this user domain should be able to transition to. On many SELinux systems, the default user_u group is not allowed to transition to any other role. User_u is reserved for unprivileged users.

Role Field:
This is the second of the four fields that make a security context. The SELinux role field has a SELinux role. Roles are only used by user domains and not by application domains. Therefore you will see a generic placeholder if you look at the role field in security contexts for objects. The role field for a user domain process may vary, as defined SELinux user groups are able to assume a new role. The role for a user domain that is member of the user_u SELinux user group may well be user_r. The role for a application domain is system_r. Security decisions based on this field are referred to as RBAC or role based access control.

Type Field.
This is the third of the four fields that make a security context. The SELinux type field has a SELinux type or domain. Types are assigned to objects, while domains are assigned to user domains and application domains. By default SELinux security is based on enforcing types. This is called TE or Type Enforcement. Access is determined on the relation of the source type field to the target type field. A Source is a domain and a Target is a type, because subjects operate on objects.

Security Level Field.
This is the last of the four fields that make a security context. The SELinux security level field has a security level. This field is, atleast at the moment, only used by multi level security policy used by government. But often support for MLS policy is enabled. If you do not use a specific MLS policy than you can disregard this field. With MLS policy, user domains get partitioned. This means that user domains operating on different security levels can not interact with each other. This is used to maximize integrity of data. On a default SELinux configuration with MLS enabled (but not necessarily a MLS policy loaded), this field may have a type of s0 which relates to the default security level 0 on which the system operates. This level is also referred to as SystemLow.

Multi level security also uses a model called multi category security. MCS will allow administrators to further confine user domains on that operate on security levels by using compartments.

For example: user_A operates on security level: 1 in compartment: office, while user_B also operates on security level :1 but in a different category: factory. Although both user domains operate on a same level, each user domain is also member of a different compartment. If a user is not a member of a compartment than access to objects in that category is denied, even when a user does operate on the same security level.

An example of a security context:
secret_u:user_r:user_t:s1:c0

This is a fictional user on a SELinux system with a MLS policy enforced. This user is part of the SELinux user group secret_u, the role of this user is a user role. This role has no privilege to change roles in a MLS invironment. The type field of this user domain is derived from the role field: user_t. This user operates on a non default security level 1 (called secret) and on that level this user domain has access to compartment c0. Where c0 could be office. This user operates on a secret security level in the office compartment of the security level.