With the arrival of kernel version 2.6, a new security system was introduced to provide a security mechanism to support access control security policies.
This system is called SELinux (Security Enhanced Linux) and was created by the NSA (National Security Agency) to implement a robust Mandatory Access Control (MAC) architecture in the Linux kernel subsystems.
If, throughout your career, you have either disabled or ignored SELinux, this document will be a good introduction to this system. SELinux works to limit privileges or remove the risks associated with compromising a program or daemon.
Before starting, you should know that SELinux is mainly intended for RHEL distributions, although it is possible to implement it on other distributions like Debian (but good luck!). The distributions of the Debian family generally integrate the AppArmor system, which works differently from SELinux.
SELinux (Security Enhanced Linux) is a Mandatory Access Control system.
Before the appearance of MAC systems, standard access management security was based on DAC (Discretionary Access Control) systems. An application, or a daemon, operated with UID or SUID (Set Owner User Id) rights, which made it possible to evaluate permissions (on files, sockets, and other processes...) according to this user. This operation does not sufficiently limit the rights of a corrupted program, potentially allowing it to access the subsystems of the operating system.
A MAC system reinforces the separation of confidentiality and integrity information to achieve a containment system. The containment system is independent of the traditional rights system and there is no notion of a superuser.
With each system call, the kernel queries SELinux to see if it allows the action to be performed.
SELinux uses a set of rules (policies) for this. A set of two standard rule sets (targeted and strict) is provided and each application usually provides its own rules.
The operation of SELinux is totally different from traditional Unix rights.
The SELinux security context is defined by the trio identity+role+domain.
The identity of a user depends directly on his Linux account. An identity is assigned one or more roles, but to each role corresponds to one domain, and only one.
It is according to the domain of the security context (and thus the role) that user's rights on a resource are evaluated.
The terms "domain" and "type" are similar. Typically "domain" refers to a process, while "type" refers to an object.
The naming convention is: user_u:role_r:type_t.
The security context is assigned to a user during their connection, according to their roles. The security context of a file is defined by the chcon (change context) command, which we will see later in this document.
Consider the following pieces of the SELinux puzzle:
The subjects
The objects
The policies
The mode
When a subject (an application for example) tries to access an object (a file for example), the SELinux part of the Linux kernel queries its policy database. Depending on the mode of operation, SELinux authorizes access to the object in case of success, otherwise it records the failure in the file /var/log/messages.
The rights of a process depend on its security context.
By default, the security context of the process is defined by the context of the user (identity + role + domain) who launches it.
A domain is a specific type (in the SELinux sense) linked to a process and inherited (normally) from the user who launched it. Its rights are expressed in terms of authorization or refusal on types linked to objects:
A process whose context has security domain D can access objects of type T.
Most important programs are assigned a dedicated domain.
Each executable is tagged with a dedicated type (here sshd_exec_t) which automatically switches the associated process to the sshd_t context (instead of user_t).
This mechanism is essential since it restricts the rights of a process as much as possible.
The restorecon command restores the default security context (the one provided by the rules):
restorecon[-vR]directory
Example:
sudorestorecon-vR/home/
Options
Observations
-v
Switch into verbose mode
-R
Apply recursion
To make a context change survive to a restorecon, you have to modify the default file contexts with the semanage fcontext command:
semanagefcontext-aoptionsfile
Note
If you are performing a context switch for a folder that is not standard for the system, creating the rule and then applying the context is a good practice as in the example below!
After the execution of a command, the system gives you back the command prompt but the expected result is not visible: no error message on the screen.
Step 1: Read the log file knowing that the message we are interested in is of type AVC (SELinux), refused (denied) and the most recent one (therefore the last one).
The message is correctly isolated but is of no help to us.
Step 2: Read the isolated message with the audit2why command to get a more explicit message that may contain the solution to our problem (typically a boolean to be set).