Introduction to SELinux and Its Modes

In the realm of Linux and Android security, SELinux (Security-Enhanced Linux) stands as a formidable guardian, enforcing Mandatory Access Control (MAC) policies that go far beyond traditional Discretionary Access Control (DAC). Its primary purpose is to confine programs and limit the damage that can be done by a compromised application or a malicious user. SELinux operates in one of three primary modes: enforcing, permissive, or disabled.

While disabled mode leaves your system completely exposed, the distinction between enforcing and permissive modes is often misunderstood, leading to a false sense of security. Permissive mode, seemingly innocuous, acts as a ‘hidden door’ – one that allows all actions to proceed while merely logging the violations. For attackers, this hidden door is a golden opportunity, enabling them to test and execute exploits that would otherwise be blocked, making it a critical vulnerability that must be understood and addressed.

The Mechanics of SELinux: A Quick Primer

Labels and Contexts

At the core of SELinux are labels (also known as security contexts). Every file, process, port, and other system resource has an associated SELinux label. These labels describe the security attributes of the resource, typically in a format like user:role:type:level. For instance, a web server process might run with the httpd_t type, and its files might have the httpd_sys_content_t type.

You can observe these labels using the -Z option with commands like ls:

ls -Z /var/www/html/index.html
-rw-r--r--. root root unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html

Policies and Rules

SELinux policies are sets of rules that define what interactions are allowed between different labels. For example, a policy might state that processes with the httpd_t type are allowed to read files with the httpd_sys_content_t type, but not to write to files with the etc_t type. These rules are compiled into a policy file loaded by the kernel.

Permissive Mode: A Double-Edged Sword

When SELinux is in permissive mode, the kernel continues to apply the SELinux policy, but instead of blocking disallowed actions, it merely logs them as ‘denials’. From a user or application’s perspective, the operation succeeds. This makes permissive mode incredibly useful for policy development and debugging, allowing administrators to identify necessary permissions for new services without causing immediate outages.

However, this diagnostic utility becomes a severe security liability in production environments. While the denials are logged, the malicious action itself is completed successfully. This means that a privilege escalation attempt, a sandbox escape, or an unauthorized file modification will proceed unimpeded, despite SELinux ‘knowing’ it’s wrong. The system provides the illusion of security because SELinux is active, but its enforcement mechanism is disarmed.

The Exploiter’s Playground: How Permissive Mode Enables Attacks

Bypassing Sandboxes and Containment

Modern operating systems heavily rely on sandboxing to contain compromised applications. A browser, for instance, might be confined to a specific set of resources. If an attacker manages to exploit a vulnerability within that sandboxed application, SELinux enforcing mode would typically prevent the application from accessing resources outside its allowed context (e.g., writing to system binaries, accessing sensitive user data). In permissive mode, these restrictions vanish. The attacker can then freely interact with the system, testing various post-exploitation techniques without immediate failure, eventually finding a path to greater privileges or data exfiltration.

Facilitating Privilege Escalation

Consider a scenario where an attacker has gained a low-privilege shell on a system. Their next step is often privilege escalation. They might attempt to exploit a vulnerable SUID binary, or perhaps manipulate configuration files for a service running as root. In an enforcing SELinux environment, if the low-privilege process attempts an action (like writing to /etc/passwd or executing a binary from an unauthorized location) that violates policy, SELinux will block it immediately. The exploit attempt fails. In permissive mode, however, these actions succeed. The attacker can use this ‘successful failure’ to identify potential attack vectors, test different payloads, and ultimately achieve root access or elevate privileges to a more potent context, all while the system silently logs the violations without preventing them.

Stealth and Persistence

Permissive mode also aids attackers in maintaining stealth and persistence. Malware can test various system modifications, privilege escalation attempts, or communication channels without immediate detection by SELinux. Since actions are not blocked, the malware won’t crash or trigger obvious alerts that might indicate a security mechanism is at play. Instead, it can quietly map out the system’s weaknesses and establish persistent footholds, making it harder for security teams to detect and respond to the intrusion in a timely manner, relying solely on log analysis that might be overlooked in a noisy environment.

Identifying and Auditing SELinux Status

Checking the Current Mode

Before you can secure your system, you need to know its current SELinux status. You can do this using the getenforce command:

getenforce
Enforcing

This command will output either Enforcing, Permissive, or Disabled. For more detailed information, use sestatus:

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 (strict)
Max kernel policy version:      33

Pay close attention to Current mode and Mode from config file. Ideally, both should be ‘enforcing’.

Understanding Audit Logs

Whether in enforcing or permissive mode, SELinux logs all policy violations. These logs are crucial for understanding what SELinux is preventing (or would prevent). On Linux distributions, these logs are typically found in /var/log/audit/audit.log (if auditd is running) or in the kernel messages (dmesg). On Android, you’d typically look in logcat.

You can search for SELinux denial messages, often indicated by