Introduction to SELinux on Android

Security-Enhanced Linux (SELinux) is a mandatory access control (MAC) system that provides a robust layer of security on Android devices, operating beyond traditional Discretionary Access Control (DAC). Implemented since Android 4.3, SELinux ensures process isolation, enforces granular permissions for file access, network operations, and inter-process communication (IPC), and significantly strengthens the sandboxing model. While DAC relies on user/group IDs, SELinux assigns security contexts to every file, process, and system resource, then uses a policy database to determine access. Successfully compromising an Android device often requires bypassing these SELinux restrictions, making an understanding of its mechanisms and common bypass techniques crucial for security researchers and exploit developers.

Understanding SELinux Fundamentals

Security Contexts and Types

At the core of SELinux are security contexts, which are labels assigned to every subject (process) and object (file, socket, IPC, etc.). A context typically takes the form user:role:type:sensitivity, with type being the most significant component for policy enforcement. For processes, the type is often referred to as a ‘domain’. For files, it’s a ‘file context’.

For example:

• u:object_r:app_data_file:s0: Data file belonging to an application.
• u:r:untrusted_app:s0: An untrusted application process domain.
• u:object_r:system_file:s0: A system binary or library.

SELinux policy rules dictate what actions a process in a specific domain (source type) can perform on an object with a given type (target type), for a specific class (e.g., file, process, socket), and with specific permissions (e.g., read, write, execute, bind).

Access Vector Cache (AVC) Denials

When an SELinux-enabled kernel blocks an action, it logs an Access Vector Cache (AVC) denial. These denials are invaluable for understanding policy enforcement and identifying potential bypasses or misconfigurations. AVC denials are typically visible in the kernel log buffer, accessible via dmesg or logcat -b kernel.

A typical AVC denial looks like this:

avc: denied { read } for pid=1234 comm="my_app" name="secret_file" dev="dm-0" ino=5678 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:app_data_file:s0 tclass=file permissive=0

This log indicates that the process my_app (with source context untrusted_app) was denied read access to secret_file (with target context app_data_file). Analyzing these denials systematically helps in mapping out the restrictions and identifying where a policy might be overly permissive or exploitable.

Practical SELinux Bypass Techniques

1. Type Transition Exploitation

Type transitions allow a process to change its security context when it executes a specific program. This is a legitimate mechanism for processes to gain necessary privileges, for example, when init transitions to zygote. However, misconfigured policies can allow a less privileged process to transition into a more powerful domain. The key is to find an executable that, when run by a low-privileged domain, is allowed to transition to a higher-privileged domain.

Consider a policy rule like:

allow untrusted_app system_file:file { execute_no_trans };

This allows untrusted_app to execute a system_file but *without* changing its domain. If instead, you find:

type_transition untrusted_app su_exec:process su;

and a corresponding rule:

allow untrusted_app su_exec:file { execute };

This means if untrusted_app executes a file labeled su_exec, the new process will transition into the su domain, which is typically highly privileged. An attacker could place a malicious binary with the su_exec context (if writable paths with such contexts exist or can be manipulated) and trigger a privilege escalation.

2. File Context Manipulation and Misconfigurations

SELinux enforces access based on file contexts. If an attacker can control the context of a file, or if a sensitive file is given an overly permissive context, it can lead to bypasses.

• Writable Sensitive Contexts: Discovering directories writable by a low-privileged process (e.g., untrusted_app) that are labeled with a context typically associated with higher privileges (e.g., system_file_type, vendor_file_type). If an attacker can write a malicious script to such a location, and a privileged process later executes it, escalation is possible.
• Arbitrary File Context Changing: In rare cases, vulnerabilities might allow a low-privileged process to relabel files. If an attacker can relabel their own malicious binary to a context like init_exec or system_server_exec, and then cause a privileged process to execute it (e.g., through a path traversal vulnerability or by exploiting a vulnerable service), they could achieve arbitrary code execution in a privileged domain.

Example using restorecon (requires root/special capabilities):

# Assume malicious_exploit.sh is written to /data/local/tmp/malicious_exploit.sh (untrusted_app_data_file) # If a policy misconfiguration allowed: allow untrusted_app system_file_type:file { setattr }; # Malicious app could change context: chcon u:object_r:system_file:s0 /data/local/tmp/malicious_exploit.sh

This is generally highly restricted, but specific vulnerabilities in tools or services that handle file contexts could be leveraged.

3. Service Manager Interaction Abuses

Android’s Binder IPC mechanism relies heavily on SELinux to control which processes can interact with specific services. The servicemanager acts as a registry. SELinux rules govern who can add, find, or call services.

An attacker looks for:

• Overly Permissive binder_call rules: If an untrusted_app is allowed to call a method on a highly privileged service (e.g., system_server, hwservice_manager) that it typically shouldn’t, and that method has a vulnerability, it can lead to escalation.
• Service Registration Abuse: If a low-privileged app can register a service under a privileged name, it could trick legitimate components into communicating with a malicious service.

Example policy snippet to look for (if some_privileged_service is exploitable and untrusted_app can call it):

allow untrusted_app some_privileged_service:binder { call };

This allows an untrusted app to invoke methods on some_privileged_service. If a method within some_privileged_service performs a sensitive operation without proper checks, a bypass could occur.

4. Exploiting Policy Inadequacies and Bugs

The complexity of SELinux policies, especially those found in custom Android ROMs or vendor implementations, can introduce subtle bugs or inadequacies. These can manifest as:

• Broad allow Rules: General permissions granted to a broad type, e.g., allow untrusted_app *:{ file folder } *; (highly unlikely, but illustrative). More subtle: allow untrusted_app some_device:chr_file { ioctl read write }; if some_device controls a sensitive hardware component that an untrusted app shouldn’t access.
• Unintended Object Access: A policy might correctly restrict direct file access, but inadvertently allow a side-channel attack through a different object type, like accessing device nodes that manage hardware.
• dontaudit Rules Hiding Issues: While necessary for reducing log spam, dontaudit rules can hide legitimate policy issues or potential attack paths. Removing or selectively disabling dontaudit rules during security audits can reveal hidden denials.

5. Leveraging Capabilities Beyond SELinux

Linux capabilities provide fine-grained control over root privileges, allowing a process to perform specific privileged operations without having full root access. While SELinux is designed to work in conjunction with capabilities, an oversight in either system can create an exploit chain.

For instance, if a process running in a specific SELinux domain is granted a powerful capability like CAP_DAC_OVERRIDE (bypass file read/write/execute permissions) or CAP_SYS_ADMIN (perform a range of system administration operations), and SELinux doesn’t sufficiently constrain how these capabilities can be used, it might lead to a bypass.

Analyzing capabilities for a process:

cat /proc/PID/status | grep Cap

If an attacker gains control of a process with certain capabilities, they can leverage them to bypass SELinux if the policy for that domain doesn’t specifically block the sensitive actions permitted by those capabilities.

Methodology for Finding Bypass Opportunities

Identifying SELinux bypasses is an iterative process:

1. Policy Analysis: Obtain the device’s sepolicy files (often found in /sys/fs/selinux/policy or unpacked from boot.img). Use tools like sepolicy-analyze, sesearch, and AOSP’s audit2allow (with caution) to understand the policy structure and permissions.
2. Denial Monitoring: Continuously monitor dmesg and logcat -b kernel for AVC denials while interacting with the target application or system components. This highlights exactly where SELinux is enforcing restrictions.
3. Fuzzing and Input Manipulation: Actively try to trigger different code paths and input types in target services or applications, observing how SELinux reacts.
4. Code Review: Examine the source code of privileged services and applications for logical flaws in their interaction with the file system, IPC, or system calls, which might be exploited even under strong SELinux policies.

Conclusion

SELinux on Android is a formidable security barrier, but it is not impenetrable. By understanding its core mechanisms – security contexts, types, and AVC denials – and by systematically exploring common weaknesses such as type transition vulnerabilities, file context misconfigurations, Binder interaction abuses, and subtle policy bugs, security researchers can identify pathways for privilege escalation. A comprehensive approach combining policy analysis, denial monitoring, and targeted fuzzing is essential for uncovering these sophisticated bypasses and ultimately strengthening Android’s security posture.