Baeldung - Linux

Learn about Linux in practice

What Is SELinux?
2025-06-09 04:53 UTC by Zachary Bouhannana

1. Overview

We often rely on traditional security measures, such as strong passwords, permissions, and firewalls, to protect Linux systems. However, sometimes we need more fine-grained control, such as managing the possible actions of processes. That’s where SELinux (Security-Enhanced Linux) comes in.

Originally developed by the National Security Agency (NSA) of the USA and later released to the open-source community, SELinux enables sysadmins to define specific access policies to control how processes and users interact with system resources.

In this tutorial, we’ll explore what SELinux is, how it works, and why it matters.

2. What Exactly Is SELinux?

SELinux is a security module built into the Linux kernel to provide extra access control beyond the usual Unix-style permission system. It plays a key role in protecting against privilege escalation, misconfigurations, and zero-day exploits.

SELinux matters most in environments where security is crucial. Whether running web servers, databases, or containerized apps, SELinux can mean the difference between a contained threat and a full system compromise.

To truly appreciate SELinux, it’s wise to understand how it differs from the standard Linux security models.

2.1. The Problem With Traditional Permissions (DAC)

In Linux, Discretionary Access Control (DAC) is the “read-write-execute” permissions that control who can do what with a file. These provide the standard layer of security. Simply put, the owner of a file or process can decide who gets access.

While flexible, this can be a weak point. If a malicious program manages to get control, it might be able to use those discretionary permissions to escalate the damage.

For example, if a user owns a script, that user decides who can execute it. If a privileged user (like root) or a compromised process gains control, it can potentially access or modify any resource on the system. Traditionally, a root user can bypass DAC checks.

2.2. The Solution of Mandatory Access Control (MAC)

The big shift with SELinux is how it flips the way access control works. Most administrators and users are well aware of DAC, where file owners have a say. However, SELinux adds MAC to the kernel.

Under MAC, the operating system, rather than individual users, strictly enforces a system-wide security policy defined by the admin. Every single system call, every access attempt, gets checked against this policy.

What’s more, even the root user must comply. SELinux can limit root actions if they’re outside the defined policy. In other words, this is a much tighter security. We can stop unauthorized access or modifications to files, processes, and resources, even from a superuser account.

2.3. Default Deny Principle

The SELinux MAC approach relies on the default deny principle.

In short, if the SELinux rules don’t explicitly allow a specific action or access, it’s automatically denied. This deny-by-default stance alone provides a great security advantage by reducing the attack surface.

2.4. How MAC and DAC Complete Each Other

SELinux doesn’t replace the basic file permissions that chmod or chown manage. Instead, it works alongside them in a specific order to provide deeper and mandatory control.

When a process tries to access a file, the system first checks DAC policy rules. Only if those basic permissions allow access, SELinux then steps in to evaluate its security policies (MAC).

This sequence means SELinux acts as a second checkpoint. This adds extra protection for scenarios where the DAC level might be too permissive, or when a compromised process manages to bypass it.

3. SELinux Core

A SELinux-enabled system relies on key security concepts to guide access decisions. Let’s see how these principles can improve Linux system security.

3.1. Security Context (Label)

SELinux assigns a security context (also called a security label) to every file, user, and process on the system. This context or label is a set of attributes that SELinux uses to determine access permissions. Simply put, these labels are name tags that tell what’s allowed and what’s not.

A security context consists of four parts (user:role:type:level). Let’s check what each one does:

user: maps to one or more Linux users and defines which roles a user can assume, e.g., user_u or unconfined_u (not the same as the OS user)
role: limits the actions certain users or types can perform, defining which types a user assigned to a role can access (SELinux assigns role names with the _r suffix, such as system_r)
type: domain for processes and a type for files, which defines how processes and files interact with each other (all files and running processes are assigned a type ending in _t, for example, httpd_t for the web server process or var_t for files in /var)
level (optional): range of clearance levels within Multi-Level Security (MLS) systems to set sensitivity levels, such as s0 or s1

Now, let’s run the ls -Z command on a directory with files to see some examples of what a security context may look like:

$ ls -Z
-rw-------. root root system_u:object_r:httpd_sys_content_t:s0 index.html
drwxrwxrwx. root root unconfined_u:object_r:admin_home_t:s0 backup

Here, the command lists file ownership (root) along with its rwx permissions. Moreover, the -Z switch includes the four parts of the security context of each entry (user, role, type, and security level), as in system_u:object_r:httpd_sys_content_t:s0.

3.2. Policy Rules

SELinux uses policy modules to define what each process can do. Every possible action (like process of type X reads file of type Y) needs an explicit rule allowing it, or else SELinux denies it. As we mentioned before, SELinux forbids everything by default unless we explicitly allow it.

For example, a policy rule might say “allow httpd_t processes to read httpd_sys_content_t files”. If we try an action not in the rules, SELinux blocks it and logs a denial.

To set a policy rule, we do so by following a basic syntax:

<rule_type> <subject> <object>:<object_class> <permission>;

Let’s break down what each part means:

rule_type: action SELinux should take, usually allow, dontaudit, or neverallow
subject: domain or type of the process requesting access
object: type of the resource being accessed
object_class: class of the object, like file, dir, tcp_socket
permission: action being allowed, like read, write, open

For example, we can check a simple policy rule in action:

ALLOW apache_process apache_log:FILE READ;

This rule simply allows a process labeled apache_process to read a log file labeled apache_log.

3.3. Booleans

How about if we want to turn off a rule without editing the security policy?

An SELinux boolean is an on-off switch that enables changing how rules behave without rewriting an entire SELinux policy. For example, a common boolean is httpd_can_network_connect. By default, it might be off, so the web server (httpd_t) can’t make outbound network connections.

Let’s see how we can turn it on using the setsebool command:

$ setsebool -P httpd_can_network_connect on

By setting the above boolean to on, SELinux allows access without needing to tinker with policy files. Moreover, instead of using the on–off options, we can use their equivalent numerical values 0–1.

In fact, SELinux comes with many such booleans – for actions like allowing FTP write access, using NFS, and more – to adjust rules at runtime. We can list all the rules with getsebool -a:

$ getsebool -a | less
abrt_anon_write --> off
abrt_handle_event --> off
abrt_upload_watch_anon_write --> on
antivirus_can_scan_system --> off
antivirus_use_jit --> off
auditadm_exec_content --> on
authlogin_nsswitch_use_ldap --> off
authlogin_radius --> off
authlogin_yubikey --> off
awstats_purge_apache_log_files --> off
:

Here, the output can be quite long, so it’s best to pipe it to less to scroll through it page by page.

3.4. Modes

SELinux can run in three modes, each offering different levels of security control:

enforcing (0): actively blocks violations
permissive (1): logs violations without blocking
disabled: turns off SELinux completely, with the system falling back to normal DAC permissions

We can check the current SELinux mode with getenforce:

$ getenforce
Enforcing

In this case, SELinux is in Enforcing mode.

Now, let’s use the setenforce mode to change it to Permissive:

$ setenforce 0

Here, the 0 is the MODE_ID for the Permissive mode. Conversely, 1 is the ID for Enforcing mode.

Notably, setenforce doesn’t persist after reboot. However, we can directly edit the SELinux config file (/etc/selinux/config) to make changes persist. Moreover, editing the config file is also how we can switch to Disabled mode.

4. Why Is SELinux Important?

It may seem that Linux file permissions (read, write, execute) and user ownership should be enough to keep a system secure. Of course, for simple setups, they usually are. However, once we run complex Internet-facing services, standard access permissions don’t cover every scenario.

A major advantage of SELinux is its ability to limit damage during security breaches.

Let’s say a web server (Apache httpd) is hacked. With traditional permissions, the attacker could read sensitive files in /etc, modify scripts in /var/www, and access user data.

Now, we can see a simple example of how SELinux can block access even for root users based on file labels.

First, we create a test file in the root user’s home directory:

$ echo "secret" > /root/zfile

Now let’s change the SELinux label of that file with the chcon command:

$ chcon -t admin_home_t /root/zfile

Here, we assign /root/zfile the type admin_home_t, which isn’t meant for web servers to access.

Finally, let’s check whether Apache can access the file:

$ runcon -t httpd_t -- cat /root/testfile
cat: /root/zfile: Permission denied

We use the runcon -t command to run cat /root/zfile under a different SELinux context (httpd_t), which is the domain Apache runs in. Even though cat runs as root, SELinux steps in and blocks it.

5. Conclusion

In this article, we explored what SELinux is, why it matters, and how it strengthens Linux security.

In particular, we looked at the way it works alongside traditional access permissions using labels, policies, and strict access rules. Through examples, we saw how SELinux can block unauthorized actions, even from superusers.

The post What Is SELinux? first appeared on Baeldung on Linux.