Introduction to SELinux on Android

Android’s security model is a multi-layered defense system, with SELinux (Security-Enhanced Linux) serving as a critical component for Mandatory Access Control (MAC). Introduced in Android 4.3, SELinux ensures that even if a process gains root privileges, its actions are still constrained by policy rules. This prevents applications and system components from performing operations they are not explicitly allowed to, effectively confining them within a “security sandbox.” For security researchers, exploit developers, and system integrators, understanding how to analyze and potentially bypass these policies is paramount for uncovering vulnerabilities or hardening systems.

This article delves into practical strategies for identifying and exploiting weaknesses in SELinux policies, providing an expert-level guide to navigating Android’s robust security architecture.

Understanding SELinux Fundamentals on Android

SELinux operates on the principle of least privilege, where every resource (files, processes, sockets, etc.) and every action is labeled with a security context. The SELinux policy, a set of rules defined by Google and device manufacturers, dictates what interactions are allowed between these labeled entities. Key concepts include:

• Security Contexts: Labels applied to processes and files, e.g., u:r:untrusted_app:s0 for an unprivileged application.
• Types (Domains): The most common attribute used in Android’s TE (Type Enforcement) model, defining a set of permissions for processes (domains) and files (types).
• Policy Rules: Directives like allow, dontaudit, type_transition, and neverallow that define permissible interactions.

On Android, the SELinux policy is compiled into a binary format and loaded at boot. Any attempt to violate this policy results in an Access Vector Cache (AVC) denial, which is typically logged to the kernel ring buffer. Monitoring these denials is crucial for policy analysis.

You can check the current SELinux enforcement status and review denials using adb shell:

adb shell getenforce # Should output "Enforcing" on production devicesadb shell su -c "dmesg | grep avc" # View Access Vector Cache denials

Initial Reconnaissance: Identifying Policy Weaknesses

The first step in evading SELinux is thorough reconnaissance of the active policy. This involves extracting and analyzing the policy rules to identify potential misconfigurations or overly broad permissions.

1. Extracting the Policy

The active SELinux policy can usually be found at /sys/fs/selinux/policy or /vendor/etc/selinux/precompiled_sepolicy (and similar paths for individual `.te` files). Pulling the binary policy is essential for static analysis:

adb pull /sys/fs/selinux/policy sepolicy.bin

2. Policy Analysis Tools

Once you have the binary policy, tools like AOSP’s sepolicy-analyze, audit2allow, and sesearch are invaluable. For instance, to search for specific permissions granted to a domain:

# Example using sesearch from libsepol/sepolicy-tools# Search for 'create' permissions for 'untrusted_app_t' on 'system_file'sesearch -A -s untrusted_app_t -t system_file -c file -p create sepolicy.bin# List all type transitions from 'untrusted_app_t'sesearch -T -s untrusted_app_t sepolicy.bin

Practical Strategies for SELinux Policy Evation

Evading SELinux policies often involves identifying rules that, while seemingly benign, can be chained to elevate privileges or bypass restrictions within specific contexts.

1. Type Transition Exploits

Type transitions are powerful rules that allow a process creating a new object (e.g., file, directory) in a specific location to automatically assign it a different, potentially more privileged, security type. If an unprivileged domain can trigger a transition to a type with broader permissions, it opens an avenue for attack.

Scenario: Abusing file_type_transition

Consider a rule like:

type_transition untrusted_app_t /data/data/com.example.app/files/ my_app_data_t;

This means if untrusted_app_t creates a file in /data/data/com.example.app/files/, that file automatically gets the my_app_data_t context. If my_app_data_t is configured to be readable by a privileged service (e.g., a system daemon in system_server_t domain) which it shouldn’t normally be able to interact with through untrusted_app_t directly, this could be a bypass. The key is to find shared locations where an unprivileged domain can create files that transition to a type with specific, exploitable permissions.

2. Domain Transition / Executable Exploits

Similar to type transitions, domain transitions allow a process to switch to a new security domain when executing a specific program. If an unprivileged domain can execute a binary that is configured to transition to a more privileged domain, it can gain elevated permissions.

Scenario: Exploiting exec_transition

An attacker might look for rules like:

domain_auto_trans(untrusted_app, myservice_exec, myservice_t);

This rule dictates that if a process in the untrusted_app domain executes a file labeled myservice_exec_t, the executing process will transition to the myservice_t domain. If myservice_t has more permissions than untrusted_app_t (e.g., access to sensitive system properties or files), and the attacker can write to or hijack the myservice_exec_t binary, or even just execute an existing one with vulnerabilities, it presents a significant bypass opportunity.

3. Policy Misconfigurations and Overly Permissive Rules

Sometimes, the policy itself contains overly broad `allow` rules or simply forgets to restrict certain interactions. These are often easier to identify through static analysis.

Example: Broad File System Access

An entry like:

allow appdomain { rootfs dev_t } dir { search };

While search might seem innocent, if combined with other permissions, it could enable information disclosure or path traversal attacks. More critical would be `allow untrusted_app_t { system_file } { file } { write };` which would be an egregious error.

Look for rules that grant permissions to broad sets of types or classes, or that use very general attributes (e.g., `allow domain type:class { permission };` where `type` is very broad).

4. Abusing Privileged IPC Channels (Binder)

While not a direct SELinux bypass, abusing inter-process communication (IPC) channels like Binder can indirectly lead to privilege escalation by leveraging privileged services. If a service running in a highly privileged domain (e.g., system_server_t) performs sensitive operations based on insufficiently validated input from a less privileged domain, SELinux might allow the service to perform the action, effectively bypassing the restriction on the lower-privileged app.

This technique relies on finding logical flaws in service implementations rather than policy flaws directly, but SELinux policy analysis helps identify which services might be exploitable by revealing what permissions they hold.

Developing an Exploit Strategy: A Conceptual Walkthrough

Let’s consider a hypothetical scenario where we want to gain write access to a protected system file, /data/vendor_configs/config.txt, from an untrusted_app.

1. Identify Target File Context: First, determine the SELinux context of the target file.adb shell ls -Z /data/vendor_configs/config.txt # Output: u:object_r:vendor_config_file:s0 config.txtSo, the target context is vendor_config_file_t.
2. Analyze Policy for untrusted_app_t: Use sesearch to find what permissions untrusted_app_t has on vendor_config_file_t. We’d likely find no write permissions.
3. Look for Intermediate Privileged Domains: We need to find a domain that can write to vendor_config_file_t and which untrusted_app_t can potentially transition into or communicate with. Let’s say we identify a custom service, my_custom_service, running in my_custom_service_t domain, which has allow my_custom_service_t vendor_config_file_t:file { write };.
4. Search for Type/Domain Transitions or IPC Vulnerabilities:
   
   • Type Transition: Is there a writable directory for untrusted_app_t where creating a file triggers a transition to a type that my_custom_service_t will read and act upon, or perhaps even transition to my_custom_service_t?
   • Domain Transition: Can untrusted_app_t execute a binary (e.g., a CLI tool for my_custom_service) that causes it to transition to my_custom_service_t?
   • IPC Abuse: Does my_custom_service expose a Binder interface that takes a filename as input and writes data to it without proper path validation or ownership checks? If so, the untrusted_app could call this Binder method, instructing the privileged service to write to /data/vendor_configs/config.txt on its behalf.
5. Craft the Exploit:
   

   If an IPC vulnerability is found, the exploit might involve a simple Android application making a Binder call:

   // Example (pseudo-code) in Java for an Android appimport android.os.IBinder;import android.os.Parcel;import android.os.ServiceManager;public class Exploit {    public static void main(String[] args) {        try {            IBinder binder = ServiceManager.getService("my_custom_service");            if (binder != null) {                Parcel data = Parcel.obtain();                Parcel reply = Parcel.obtain();                data.writeString("/data/vendor_configs/config.txt");                data.writeString("new_config_value");                binder.transact(0xDEADBEEF, data, reply, 0); // Assuming 0xDEADBEEF is the writeToFile code                reply.readException();                System.out.println("File write attempted.");                data.recycle();                reply.recycle();            }        } catch (Exception e) {            e.printStackTrace();        }    }}

   This example demonstrates how an `untrusted_app` could indirectly achieve privileged file modification by exploiting a vulnerability in a more privileged service’s Binder interface, with SELinux allowing the service itself to perform the action.

Conclusion

SELinux is a formidable security barrier on Android, designed to contain malicious actors even in the presence of kernel or root exploits. However, the complexity of these policies often leads to misconfigurations or unintended permission grants that can be leveraged for privilege escalation or sandbox escapes. By meticulously analyzing policy files, monitoring AVC denials, and understanding the nuances of type and domain transitions, security researchers can uncover the cracks in this otherwise robust security model. Ethical hacking and thorough policy review are critical for maintaining the integrity of the Android ecosystem.