Basic and advanced configuration of Security-Enhanced Linux (SELinux)
Providing feedback on Red Hat documentation
We appreciate your input on our documentation. Please let us know how we could make it better. To do so:
- For simple comments on specific passages, make sure you are viewing the documentation in the Multi-page HTML format. Highlight the part of text that you want to comment on. Then, click the Add Feedback pop-up that appears below the highlighted text, and follow the displayed instructions.
For submitting more complex feedback, create a Bugzilla ticket:
- Go to the Bugzilla website.
- As the Component, use Documentation.
- Fill in the Description field with your suggestion for improvement. Include a link to the relevant part(s) of documentation.
- Click Submit Bug.
Chapter 1. Getting started with SELinux
1.1. Introduction to SELinux
Security Enhanced Linux (SELinux) provides an additional layer of system security. SELinux fundamentally answers the question: May <subject> do <action> to <object>?, for example: May a web server access files in users' home directories?
The standard access policy based on the user, group, and other permissions, known as Discretionary Access Control (DAC), does not enable system administrators to create comprehensive and fine-grained security policies, such as restricting specific applications to only viewing log files, while allowing other applications to append new data to the log files.
SELinux implements Mandatory Access Control (MAC). Every process and system resource has a special security label called an SELinux context. A SELinux context, sometimes referred to as an SELinux label, is an identifier which abstracts away the system-level details and focuses on the security properties of the entity. Not only does this provide a consistent way of referencing objects in the SELinux policy, but it also removes any ambiguity that can be found in other identification methods. For example, a file can have multiple valid path names on a system that makes use of bind mounts.
The SELinux policy uses these contexts in a series of rules which define how processes can interact with each other and the various system resources. By default, the policy does not allow any interaction unless a rule explicitly grants access.
Remember that SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first, which means that no SELinux denial is logged if the traditional DAC rules prevent the access.
SELinux contexts have several fields: user, role, type, and security level. The SELinux type information is perhaps the most important when it comes to the SELinux policy, as the most common policy rule which defines the allowed interactions between processes and system resources uses SELinux types and not the full SELinux context. SELinux types end with
_t. For example, the type name for the web server is
httpd_t. The type context for files and directories normally found in
httpd_sys_content_t. The type contexts for files and directories normally found in
tmp_t. The type context for web server ports is
There is a policy rule that permits Apache (the web server process running as
httpd_t) to access files and directories with a context normally found in
/var/www/html/ and other web server directories (
httpd_sys_content_t). There is no allow rule in the policy for files normally found in
/var/tmp/, so access is not permitted. With SELinux, even if Apache is compromised, and a malicious script gains access, it is still not able to access the
Figure 1.1. An example how can SELinux help to run Apache and MariaDB in a secure way.
As the previous scheme shows, SELinux allows the Apache process running as
httpd_t to access the
/var/www/html/ directory and it denies the same process to access the
/data/mysql/ directory because there is no allow rule for the
mysqld_db_t type contexts). On the other hand, the MariaDB process running as
mysqld_t is able to access the
/data/mysql/ directory and SELinux also correctly denies the process with the
mysqld_t type to access the
/var/www/html/ directory labeled as
To better understand SELinux basic concepts, see the following documentation:
- The SELinux Coloring Book
1.2. Benefits of running SELinux
SELinux provides the following benefits:
- All processes and files are labeled. SELinux policy rules define how processes interact with files, as well as how processes interact with each other. Access is only allowed if an SELinux policy rule exists that specifically allows it.
- Fine-grained access control. Stepping beyond traditional UNIX permissions that are controlled at user discretion and based on Linux user and group IDs, SELinux access decisions are based on all available information, such as an SELinux user, role, type, and, optionally, a security level.
- SELinux policy is administratively-defined and enforced system-wide.
- Improved mitigation for privilege escalation attacks. Processes run in domains, and are therefore separated from each other. SELinux policy rules define how processes access files and other processes. If a process is compromised, the attacker only has access to the normal functions of that process, and to files the process has been configured to have access to. For example, if the Apache HTTP Server is compromised, an attacker cannot use that process to read files in user home directories, unless a specific SELinux policy rule was added or configured to allow such access.
- SELinux can be used to enforce data confidentiality and integrity, as well as protecting processes from untrusted inputs.
However, SELinux is not:
- antivirus software,
- replacement for passwords, firewalls, and other security systems,
- all-in-one security solution.
SELinux is designed to enhance existing security solutions, not replace them. Even when running SELinux, it is important to continue to follow good security practices, such as keeping software up-to-date, using hard-to-guess passwords, and firewalls.
1.3. SELinux examples
The following examples demonstrate how SELinux increases security:
- The default action is deny. If an SELinux policy rule does not exist to allow access, such as for a process opening a file, access is denied.
SELinux can confine Linux users. A number of confined SELinux users exist in the SELinux policy. Linux users can be mapped to confined SELinux users to take advantage of the security rules and mechanisms applied to them. For example, mapping a Linux user to the SELinux
user_uuser, results in a Linux user that is not able to run unless configured otherwise set user ID (setuid) applications, such as
su, as well as preventing them from executing potentially malicious files and applications in their home directory.
- Increased process and data separation. The concept of SELinux domains allows defining which processes can access certain files and directories. For example, when running SELinux, unless otherwise configured, an attacker cannot compromise a Samba server, and then use that Samba server as an attack vector to read and write to files used by other processes, such as MariaDB databases.
SELinux helps mitigate the damage made by configuration mistakes. Domain Name System (DNS) servers often replicate information between each other in what is known as a zone transfer. Attackers can use zone transfers to update DNS servers with false information. When running the Berkeley Internet Name Domain (BIND) as a DNS server in Red Hat Enterprise Linux, even if an administrator forgets to limit which servers can perform a zone transfer, the default SELinux policy prevents zone files  from being updated using zone transfers, by the BIND
nameddaemon itself, and by other processes.
1.4. SELinux architecture and packages
SELinux is a Linux Security Module (LSM) that is built into the Linux kernel. The SELinux subsystem in the kernel is driven by a security policy which is controlled by the administrator and loaded at boot. All security-relevant, kernel-level access operations on the system are intercepted by SELinux and examined in the context of the loaded security policy. If the loaded policy allows the operation, it continues. Otherwise, the operation is blocked and the process receives an error.
SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). When using these cached decisions, SELinux policy rules need to be checked less, which increases performance. Remember that SELinux policy rules have no effect if DAC rules deny access first. Raw audit messages are logged to the
/var/log/audit/audit.log and they start with the
In Red Hat Enterprise Linux 8, system services are controlled by the
systemd starts and stops all services, and users and processes communicate with
systemd using the
systemctl utility. The
systemd daemon can consult the SELinux policy and check the label of the calling process and the label of the unit file that the caller tries to manage, and then ask SELinux whether or not the caller is allowed the access. This approach strengthens access control to critical system capabilities, which include starting and stopping system services.
systemd daemon also works as an SELinux Access Manager. It retrieves the label of the process running
systemctl or the process that sent a
D-Bus message to
systemd. The daemon then looks up the label of the unit file that the process wanted to configure. Finally,
systemd can retrieve information from the kernel if the SELinux policy allows the specific access between the process label and the unit file label. This means a compromised application that needs to interact with
systemd for a specific service can now be confined by SELinux. Policy writers can also use these fine-grained controls to confine administrators.
To avoid incorrect SELinux labeling and subsequent problems, ensure that you start services using a
systemctl start command.
Red Hat Enterprise Linux 8 provides the following packages for working with SELinux:
1.5. SELinux states and modes
SELinux can run in one of three modes: enforcing, permissive, or disabled.
- Enforcing mode is the default, and recommended, mode of operation; in enforcing mode SELinux operates normally, enforcing the loaded security policy on the entire system.
- In permissive mode, the system acts as if SELinux is enforcing the loaded security policy, including labeling objects and emitting access denial entries in the logs, but it does not actually deny any operations. While not recommended for production systems, permissive mode can be helpful for SELinux policy development and debugging.
- Disabled mode is strongly discouraged; not only does the system avoid enforcing the SELinux policy, it also avoids labeling any persistent objects such as files, making it difficult to enable SELinux in the future.
setenforce utility to change between enforcing and permissive mode. Changes made with
setenforce do not persist across reboots. To change to enforcing mode, enter the
setenforce 1 command as the Linux root user. To change to permissive mode, enter the
setenforce 0 command. Use the
getenforce utility to view the current SELinux mode:
# getenforce Enforcing
# setenforce 0 # getenforce Permissive
# setenforce 1 # getenforce Enforcing
In Red Hat Enterprise Linux, you can set individual domains to permissive mode while the system runs in enforcing mode. For example, to make the httpd_t domain permissive:
# semanage permissive -a httpd_t
Note that permissive domains are a powerful tool that can compromise security of your system. Red Hat recommends to use permissive domains with caution, for example, when debugging a specific scenario.
Chapter 2. Changing SELinux states and modes
2.1. Permanent changes in SELinux states and modes
As discussed in SELinux states and modes, SELinux can be enabled or disabled. When enabled, SELinux has two modes: enforcing and permissive.
sestatus commands to check in which mode SELinux is running. The
getenforce command returns
sestatus command returns the SELinux status and the SELinux policy being used:
$ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 31
When systems run SELinux in permissive mode, users and processes can label various file-system objects incorrectly. File-system objects created while SELinux is disabled are not labeled at all. This behavior causes problems when changing to enforcing mode because SELinux relies on correct labels of file-system objects. To prevent incorrectly labeled and unlabeled files from causing problems, file systems are automatically relabeled when changing from the disabled state to permissive or enforcing mode. In permissive mode, use the
fixfiles -F onboot command as root to create the
/.autorelabel file containing the
-F option to ensure that files are relabeled upon next reboot.
2.2. Enabling SELinux
When enabled, SELinux can run in one of two modes: enforcing or permissive. The following sections show how to permanently change into these modes.
While enabling SELinux on systems that previously had it disabled, to avoid problems, such as systems unable to boot or process failures, follow this procedure:
- Enable SELinux in permissive mode. For more information, see Changing to permissive mode.
- Reboot your system.
- Check for SELinux denial messages.For more information, see Identifying SELinux denials.
- If there are no denials, switch to enforcing mode. For more information, see Changing to enforcing mode.
To run custom applications with SELinux in enforcing mode, choose one of the following scenarios:
Run your application in the
- Write a new policy for your application. See the Writing Custom SELinux Policy Knowledgebase article for more information.
Temporary changes in modes are covered in SELinux states and modes.
2.2.1. Changing to permissive mode
When SELinux is running in permissive mode, SELinux policy is not enforced. The system remains operational and SELinux does not deny any operations but only logs AVC messages, which can be then used for troubleshooting, debugging, and SELinux policy improvements. Each AVC is logged only once in this case.
To permanently change mode to permissive, follow the procedure below:
/etc/selinux/configfile as follows:
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=permissive # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted
Reboot the system:
2.2.2. Changing to enforcing mode
When SELinux is running in enforcing mode, it enforces the SELinux policy and denies access based on SELinux policy rules. In Red Hat Enterprise Linux, enforcing mode is enabled by default when the system was initially installed with SELinux.
This procedure assumes that the
policycoreutils packages are installed.
If SELinux was disabled, follow the procedure below to change mode to enforcing again:
/etc/selinux/configfile as follows:
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted
Reboot the system:
On the next boot, SELinux relabels all the files and directories within the system and adds SELinux context for files and directories that were created when SELinux was disabled.
After changing to enforcing mode, SELinux may deny some actions because of incorrect or missing SELinux policy rules. To view what actions SELinux denies, enter the following command as root:
# ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts today
Alternatively, with the
setroubleshoot-server package installed, enter:
# grep "SELinux is preventing" /var/log/messages
If SELinux is active and the Audit daemon (
auditd) is not running on your system, then search for certain SELinux messages in the output of the
# dmesg | grep -i -e type=1300 -e type=1400
2.3. Disabling SELinux
When SELinux is disabled, SELinux policy is not loaded at all; it is not enforced and AVC messages are not logged. Therefore, all benefits of running SELinux are lost.
Red Hat strongly recommends to use permissive mode instead of permanently disabling SELinux. See Changing to permissive mode for more information about permissive mode.
To permanently disable SELinux, follow the procedure below:
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=disabled # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted
Reboot your system. After reboot, confirm that the
2.4. Changing SELinux modes at boot time
On boot, you can set several kernel parameters to change the way SELinux runs:
- Setting this parameter causes the machine to boot in permissive mode, which is useful when troubleshooting issues. Using permissive mode might be the only option to detect a problem if your file system is too corrupted. Moreover, in permissive mode the system continues to create the labels correctly. The AVC messages that are created in this mode can be different than in enforcing mode. In permissive mode, only the first denial is reported. However, in enforcing mode you might get a denial on reading a directory and an application stops. In permissive mode, you get the same AVC message, but the application continues reading files in the directory and you get an AVC for each denial in addition.
This parameter causes the kernel to not load any part of the SELinux infrastructure. The init scripts notice that the system booted with the
selinux=0parameter and touch the
/.autorelabelfile. This causes the system to automatically relabel the next time you boot with SELinux enabled.Important
Red Hat does not recommend using the
selinux=0parameter. To debug your system, prefer using permissive mode.
This parameter forces the system to relabel similarly to the following commands:
# touch /.autorelabel # reboot
If a file system contains a large amount of mislabeled objects, you might need to boot in permissive mode in order to make the autorelabel process successful.