SELinux Basics

Security-Enhanced Linux (SELinux) is a powerful security module integrated into the Linux kernel, designed to enforce mandatory access control (MAC) policies. Unlike traditional discretionary access control (DAC), where users determine access permissions, SELinux policies are defined by the system administrator and enforced by the operating system, limiting what users and processes can do. This guide provides an overview of SELinux, covering its concepts, configuration, and common usage scenarios.

Understanding SELinux

What is SELinux?

SELinux is a security architecture originally developed by the United States National Security Agency (NSA) to enforce stringent access control policies. By confining user programs and system services to the minimum privileges they require, SELinux significantly reduces the potential impact of security breaches.

SELinux Modes

SELinux operates in three distinct modes:

  • Enforcing: SELinux policies are enforced, and any unauthorized access attempts are blocked and logged.
  • Permissive: SELinux policies are not enforced, but violations are logged. This mode is useful for troubleshooting and developing policies.
  • Disabled: SELinux is turned off, and no policies are enforced or logged.

You can check the current SELinux mode with the following command:

sestatus

SELinux Policies

SELinux policies define the rules governing what actions processes can take on the system. While most policies are pre-defined by the Linux distribution, they can be customized to fit specific needs. Policies are composed of types, roles, users, and contexts:

  • Types: The core unit in SELinux policies. Every file, directory, and process is assigned a type, which dictates its access permissions.
  • Roles: Limit the actions certain users or types can perform.
  • Users: Mapped to Linux users, SELinux users define what roles a user can assume.
  • Contexts: The context of a file or process includes the user, role, and type, which together determine the permissions.

Configuring SELinux

Enabling or disabling SELinux can have unintended consequences.

Checking and Changing SELinux Mode

To check the current SELinux mode:

getenforce

To set SELinux to enforcing mode:

sudo setenforce 1

To set SELinux to permissive mode:

sudo setenforce 0

To make a permanent change to the SELinux mode, edit the SELinux configuration file located at /etc/selinux/config:

sudo nano /etc/selinux/config

Update the SELINUX= line to one of the following:

  • SELINUX=enforcing
  • SELINUX=permissive
  • SELINUX=disabled

Viewing SELinux Contexts

Every file and process on a system with SELinux enabled has an associated security context—a label that includes the user, role, type, and level. To view the context of files, use the ls -Z command:

ls -Z /var/www/html

The output will look similar to:

-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 index.html

Here, unconfined_u:object_r:httpd_sys_content_t:s0 represents the security context.

Changing SELinux Contexts

To change the SELinux context of a file or directory, use the chcon command:

sudo chcon -t httpd_sys_content_t /var/www/html/index.html

This command changes the type of the file to httpd_sys_content_t, which is appropriate for files served by the Apache HTTP server.

For more permanent changes, modify the SELinux policy or use the semanage fcontext command to ensure the change persists across reboots and relabels:

sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/html(/.*)?"
sudo restorecon -R /var/www/html

SELinux Booleans

SELinux Booleans are variables that can be toggled to modify the behavior of SELinux policies without rewriting them. They are particularly useful for enabling or disabling specific features in services like HTTPD, FTPD, or SSH.

Checking SELinux Booleans

To list all SELinux Booleans:

getsebool -a

To check the status of a specific Boolean:

getsebool httpd_can_network_connect

Changing SELinux Booleans

To change the value of a Boolean:

sudo setsebool httpd_can_network_connect on

To make this change persistent across reboots:

sudo setsebool -P httpd_can_network_connect on

Troubleshooting SELinux

SELinux logs policy violations in the audit log, typically located at /var/log/audit/audit.log. These logs are essential for diagnosing and troubleshooting issues related to SELinux.

Using ausearch and audit2why

The ausearch and audit2why tools help analyze and interpret SELinux logs.

To search the audit log for SELinux denials:

sudo ausearch -m avc -ts today

To translate a denial message into a human-readable explanation:

sudo ausearch -m avc -ts today | audit2why

Creating Custom SELinux Policies

If a legitimate action is being blocked by SELinux, you may need to create a custom policy to allow it. This can be done using audit2allow:

sudo ausearch -m avc -ts today | audit2allow -M my_custom_policy
sudo semodule -i my_custom_policy.pp

This process creates and installs a custom SELinux policy module that permits the previously denied actions.

Best Practices for Using SELinux

Start in Permissive Mode

If you are new to SELinux, start with it in permissive mode. This allows you to monitor potential issues without enforcing policies, giving you time to adjust configurations before enabling enforcement.

Use SELinux Booleans

Utilize SELinux Booleans to adjust security policies for your services quickly and easily. This approach is often simpler and safer than creating custom policies.

Regularly Review Logs

Regularly review SELinux logs to identify and address any potential security issues or misconfigurations. Understanding the events logged by SELinux will help you fine-tune your system's security.

Apply the Principle of Least Privilege

Ensure that processes and services have only the minimum necessary permissions to function. SELinux enforces this principle, which reduces the risk of exploitation.

Test Policy Changes

Always test policy changes in a controlled environment before applying them to production systems. This practice helps prevent disruptions and ensures that your changes achieve the desired security outcomes.