Gentoo Wiki


This article is part of the Security series.



Before SELinux can be deployed, understanding it is required. However, SELinux is incredibly complicated, and can be difficult to grasp even for an expert. SELinux introduces new concepts and definitions, and the official documentation is hard to read. The article will digest to present into an easier-to-understand guide.

This article will not deal with implementation of SELinux of command used, how to write policies, troubleshooting, and so forth. The SELinux handbook or HOWTO SELinux

Core SELinux Concepts and Definitions

SELinux Mandatory Access Control (MAC) rules are applied AFTER the Discretionary Access Control (DAC) rules. The core form of MAC used by SELinux is Type Enforcement (TE).

SELinux can only further restrict access: If access is denied via DAC, the MAC rules are not evaluated and access is denied.


An object is the (potentially) protected stuff: files, directories, sockets, pipes, kernel structures, IP addresses, or memory regions. Abstract objects are allowed as well - like TCP connections or streams. This does not include processes, however. This is the thing being "acted on" in the SELinux access evaluation.


Subject is just another name for a process. It is the "actor" in the SELinux access evaluation. (The "verb" would be the "action" being taken on the object by the subject: read, write, connect, change permissions and so forth.)


A label is metadata (often a string) applied to an object. An object may have multiple labels. Example labels are writer_t, slacker_r, user_u, and clown_exec_t.


A type is a label used to determine who is permitted access to an object. This is the most important concept in SELinux, as all security decisions are type-driven. Type labels are conventionally named typename_t.


A domain is the type of a running process. Domain labels are conventionally named domainname_exec_t, and are usually similar to the type they act on. [What does this mean? Who acts on what, and what is the similarity?]


An SELinux identity is a label, applied to a user, that contains a list of roles that may be used. Unlike a user, identities do not normally change thought the session, and multiple users may share one identity. Identity labels are conventionally named identity_u.


An role is a label, applied to to an identity. Each role contains a list of domains the identity is allowed to transition to. Role labels are conventionally named rolename_r.

Security Context

The security context is the identity, role, and type 3-tuple of an object. If the object is a process, then domain replaces type. Security contexts may be are conventionally named user_u:role_r:type_t (for non-processes) or user_u:role_r:domain_exec_t (for processes).

Domain Transition

A domain transition is a (possible) change of domain, when a process does an exec(). The success of domain transition is determined by 2 things

  1. The current role - if the current role must be allowed to be in the new domain
  2. The current domain - the security policy must allow the current domain to switch to the new domain

If either fails, the exec() is denied, the transition does not occur and the new processs does not run.

Security Policy

The security policy defines all

And controls:

Multi-Level Security (MLS) Concepts and Definitions

Multi-Level Security (MLS)

Multi-Level Security or MLS - adds a new label to the security context: The MLS Range, which consists of 2 parts: A hierarchical sensitivity level and a non-hierarchical compartment, which can be further restrict access.

The Sensitivity Level and compartments an object is in or a user can accesss it set by the administrators. Users (typically) cannot change either the Sensitivity Level or compartments an object.

Before a user will be granted access, the DAC and TE rules are evaluated first. If either fails, the MLS rules are NOT evaluated.

For the theory behind this, see Multilevel Security and Bell-LaPadula Model

MLS Security access table


Sensitivity Level

Sensitivity Levels is part of the MLS Range label - sometimes known as a classification or clearance. Sensitivity Level labels are conventionally named sn, like s7. 16 sensitivity levels are typical.


Compartment is part of the MLS Range label - sometimes known as a "need to know", or category. It may be specified alone, as a comma-sperated list, or a range. Compartment labels are conventionally named cn(singly) or cn1,cn2,cn3... (list) or cn1.cn2 (range) like c0 or c1,c37,c201 or c34.c250. 256 Compartments are typical.

MLS Range

The MLS Range is a label that consists of 2 parts - the sensitivity level and compartment. The compartment part is optional. MLS Range labels are conventionally named min sensitivity level- max sensitivity level :compartment(s), mixing and matching any of the formats above alone, list or range syntaxes. Examples include s0, s1-s8, s1:c0, s1:c1,c37,c201, s1,c34.c250, s0-s12:c19, s4-s6:c12,c46,c1110,c125, and s8-s12:c9.c26.


SystemLow is the MLS Range range label with no compartments and lowest sensitivity level: s0.


SystemHigh is the MLS Range range label with all compartments and highest sensitivity level: s16:c0.c255 (using the typical 16 sensitivity levels and 256 compartments).

Multi-Category Security (MCS) Concepts and Definitions

Multi-Category Security (MCS)

Multi-Category Security or MCS is a subset of Mutli-Level Security (MLS). The difference between them:

  1. Compartments are renamed to categories.
  2. The sensitivity level is unused (it is always s0).
  3. Typically, there are 127 categories as opposed to 256.
  4. Administrators decide which categories users are in, but users can add or remove objects they own to any category they are in.
  5. DAC and TE rules are evaluated first, if either denies access,the MCS rules are NOT evaluated.
  6. In order to access an object, the categories the user is in must be the same as, or a (proper) superset of the categories of the object.


A category is simply another name for compartment.

Other SELinux concepts

Access Vector Cache (AVC)

The Access Vector Cache (or AVC), remembers previous access decisions by SELinux. This speeds things up as SELinux access decisions can be quite complex, especially when using MLS.

Targeted Policy

The targeted policy applies SELinux policies to only the system daemons and services. User process follow standard DAC rules. As the system daemons are typically privileged and deterministic, this can provide a lot of protection with minimal problems.

Strict Policy

The strict policy applies SELinux policies to all application, including user processes. This offers greater security and greater customization, but as users actions are much less deterministic, its less convenient and more difficult as well.

See also


Implementation Guides

Retrieved from ""

Last modified: Fri, 05 Sep 2008 20:52:00 +0000 Hits: 12,053