SELinux requires a security context to be associated with every process (or subject) and object that are used by the security server to decide whether access is allowed or not as defined by the policy.
The security context is also known as a "security label" or just label that can cause confusion as there are many types of label depending on the context (another context!!).
Within SELinux, a security context is represented as variable-length strings that define the SELinux user, their role, a type identifier and an optional MCS / MLS security level as follows:
|user||The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.|
|role||The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.|
|type|| When a type is associated with a process, it defines what processes (or domains) the SELinux user (the subject) can access.
When a type is associated with an object, it defines what access permissions the SELinux user has to that object.
|level|| This optional field can also be know as a range and is only present if the policy supports MCS or MLS. The entry can consist of:
These components are discussed in the Security Levels section.
However note that:
- Access decisions regarding a subject make use of all the components of the security context.
- Access decisions regarding an object make use of all the components of the security context, however:
- a) the user is either set to a special user called system_u or it is set to the SELinux user id of the creating process (as it serves no real purpose other than it can be used for audit purposes within logs).
- b) the role is not relevant to security decisions and is always set to a special SELinux internal role of object_r.
Therefore for an object, the type (and level for MLS) are the only relevant security fields that are used in access decisions.
Examples of using system_u and object_r can be seen in the file system after relabeling and running the ls -Z command on various directories.
The examples below show security contexts for processes, directories and files (note that the policy did not support MCS or MLS, therefore no level field):
Example Process Security Context:
# These are process security contexts taken from a ps -Z command # (edited for clarity) that show four processes: LABEL PID TTY CMD user_u:unconfined_r:unconfined_t 2539 pts/0 bash user_u:message_filter_r:ext_gateway_t 3134 pts/0 secure_server user_u:message_filter_r:int_gateway_t 3138 pts/0 secure_server user_u:unconfined_r:unconfined_t 3146 pts/0 ps # Note the bash and ps processes are running under the # unconfined_t domain, however the secure_server has two instances # running under two different domains (ext_gateway_t and # int_gateway_t). Also note that they are using the # message_filter_r role whereas bash and ps use unconfined_r. # # These results were obtained by running the system in permissive # mode (as in enforcing mode the gateway processes would not be shown).
Example Object Security Context:
# These are the message queue directory object security contexts # taken from an ls -Zd command (edited for clarity): system_u:object_r:in_queue_t /user/message_queue/in_queue system_u:object_r:out_queue_t /user/message_queue/out_queue # Note that they are instantiated with system_u and object_r
# These are the message queue file object security contexts # taken from an ls -Z command (edited for clarity): /user/message_queue/in_queue: user_u:object_r:in_file_t Message-1 user_u:object_r:in_file_t Message-2 /user/message_queue/out_queue: user_u:object_r:out_file_t Message-10 user_u:object_r:out_file_t Message-11 # Note that they are instantiated with user_u as that was the # SELinux user id of the process that created the files (see the # process example above). The role remained as object_r.
- An SELinux user id is not the same as the GNU / Linux user id. The GNU / Linux user id is mapped to the SELinux user id by configuration files (via the semanage(8) command).