Android’s security model is built on multiple layers of protection, working together to safeguard user data and the integrity of the system. One of the most powerful and fundamental of these layers is SELinux (Security-Enhanced Linux). Specifically, running SELinux in its “Enforcing” mode is a critical security feature that provides fine-grained, mandatory access control (MAC) over every single process on the device, including privileged root processes. It acts as a final line of defense, capable of mitigating even zero-day vulnerabilities in the Linux kernel.
The Problem: The Limits of Discretionary Access Control
The standard security model used in Linux and other Unix-like systems is called Discretionary Access Control (DAC). In the DAC model, access to an object (like a file or a socket) is based on the identity of the user or group that owns it. This is the familiar system of user, group, and world permissions (`rwx`).
The main weakness of the DAC model is that a compromised, privileged process gains all the privileges of its user. For example, a process running as the `root` user can, by default, do almost anything on the system: read any file, access any hardware, and modify kernel parameters. If a vulnerability is found in a root process, an attacker can exploit it to take complete control of the entire device. Even non-root processes can cause significant damage if compromised.
Android’s application sandbox provides good isolation, but a more robust mechanism was needed to lock down the system itself and limit the potential damage of a compromised system process or a kernel exploit.
Introducing SELinux: Mandatory Access Control for Android
SELinux adds a second, more powerful layer of security on top of the standard DAC model. It is a Mandatory Access Control (MAC) system. In a MAC system, access decisions are based on centrally-defined security policies, not on the identity of the user. Every single process and object on the system is assigned a security label, or “context.” SELinux then enforces a set of rules, defined in the policy, that specify exactly how subjects (processes) can interact with objects (files, sockets, etc.).
The core principle is that of default denial. If there is no explicit rule in the policy that allows an action, that action is denied.
SELinux can run in two primary modes:
- Permissive Mode: In this mode, SELinux logs any policy violations but does not actually block the action. This mode is used by developers during device bring-up to develop and refine the security policy. Running a device in permissive mode offers no real protection.
- Enforcing Mode: This is the secure mode. SELinux not only logs policy violations but also actively blocks the denied actions. A process that attempts to perform an action for which it does not have permission will be stopped in its tracks. All modern Android devices are required to ship with SELinux in Enforcing mode.
How SELinux Works Internally: Contexts and Policies
The enforcement of SELinux happens deep within the Linux kernel, specifically within the Linux Security Modules (LSM) framework.
1. Labeling Everything with Contexts
The first step is that everything on the system gets an SELinux context label. This label has a format of `user:role:type:level`. The most important part for Android is the `type` tag.
- A process has a type, called its “domain.” For example, the system server process might have the domain `system_server`. An untrusted third-party app runs in the `untrusted_app` domain.
- A file has a type. For example, camera driver files might have the `camera_device` type. App data files have the `app_data_file` type.
You can see these contexts using the `-Z` flag with common shell commands:
# See process contexts $ ps -Z LABEL USER PID PPID NAME u:r:system_server:s0 system 1234 1 system_server u:r:untrusted_app:s0:c512,c768 u0_a100 5678 1 com.example.someapp # See file contexts $ ls -Z /dev/camera0 crw-rw-rw- system camera u:object_r:camera_device:s0 /dev/camera0 2. The Policy Rules
The heart of SELinux is the policy file, which is compiled and loaded into the kernel at boot. This policy contains thousands of rules that define the allowed interactions. The rules are written in a specific format, typically `allow source_type target_type:class permissions;`.
Here are some conceptual examples:
- `allow untrusted_app app_data_file:file {read write open};`
This rule allows a standard application (`untrusted_app` domain) to read and write to its own data files (`app_data_file` type). - `allow camera_app camera_device:chr_file {read write open};`
This allows the camera application to access the camera hardware driver (`camera_device`). - `neverallow untrusted_app camera_device:chr_file *;`
This is a `neverallow` rule. It’s a compile-time check that ensures no one can ever add a rule that would allow a standard, untrusted app to directly access the camera hardware. This is a critical rule for protecting user privacy.
3. Kernel-Level Enforcement
When a process (the source) tries to perform an action on an object (the target), the request is intercepted by a hook in the Linux kernel. The kernel checks the SELinux policy to see if a rule exists that explicitly allows the source’s type to perform that specific permission on the target’s type.
- If an `allow` rule exists, the action proceeds.
- If no `allow` rule exists, the action is denied, an “avc: denied” message is logged to the Logcat buffer, and the process receives an error.
This check happens for every single system call, providing an incredibly fine-grained and comprehensive security net.
For an official, deep dive into how SELinux is implemented in Android, the AOSP documentation is the best resource.
The Impact of SELinux Enforcing Mode
- Mitigation of Privilege Escalation: This is the most important benefit. Even if an attacker finds a vulnerability in a system process that allows them to run arbitrary code, SELinux will severely limit what that compromised process can do. It might be able to corrupt its own files, but the policy will prevent it from accessing the camera, microphone, or user data from other apps. It contains the breach.
- Protection Against Kernel Exploits: SELinux can even mitigate the impact of vulnerabilities in the Linux kernel itself, which is the ultimate goal of many attackers.
- Defense-in-Depth: It provides a crucial layer of defense that complements other Android security features like the application sandbox and verified boot.
Frequently Asked Questions
How can I check if my device is in Enforcing mode?
You can check the current SELinux status on any device, without needing root, by using the ADB shell.
$ adb shell getenforce Enforcing If the command returns “Enforcing,” your device is secure. If it returns “Permissive,” the device is not enforcing the security policy. All commercially available Android devices must ship in Enforcing mode to pass Google’s compatibility tests.
Why do some custom ROMs or root guides tell people to set SELinux to Permissive?
This is generally a very bad security practice. Some root modifications or apps that require deep system access were not designed to work with the strict rules of the SELinux policy. As a lazy workaround, their developers tell users to switch the entire system to the insecure Permissive mode. This effectively disables a huge part of Android’s security model and leaves the device much more vulnerable to malware.
What is an “SELinux denial”?
An “SELinux denial” (or “AVC denial”) is the log message that is generated whenever SELinux in Enforcing mode blocks an action. These logs are critical for policy developers. When they see a denial, it means they need to either fix a bug in an application that is trying to do something it shouldn’t, or they need to write a new, specific `allow` rule in the policy to grant a legitimate permission that was missing.
Does SELinux affect performance?
The performance impact of a well-tuned SELinux policy in Enforcing mode is negligible for most workloads. The policy lookups in the kernel are heavily optimized and cached. While there is a tiny amount of overhead compared to running with SELinux disabled, the massive security benefits are universally considered to be worth it. A poorly written policy with too many broad rules, however, could potentially impact performance.