Beyond Denials: Crafting Custom SELinux Policies to Achieve Sandbox Bypass on Android

Introduction: The Android Security Model and SELinux

Android’s robust security architecture relies heavily on a multi-layered approach, with SELinux (Security-Enhanced Linux) serving as a critical mandatory access control (MAC) mechanism. Introduced in Android 4.3 and strictly enforced since Android 5.0, SELinux complements traditional discretionary access control (DAC) by defining fine-grained permissions for all processes and files. It dictates what subjects (processes) can do to objects (files, sockets, IPC mechanisms), effectively sandboxing applications and system components to mitigate the impact of vulnerabilities.

For security researchers, exploit developers, and Android enthusiasts, understanding and manipulating SELinux policies is paramount. While most exploits focus on achieving code execution within an app’s sandbox, a true “sandbox bypass” often implies escaping these SELinux constraints to access resources or perform actions outside the intended domain. This article delves into the expert-level process of analyzing existing SELinux policies, identifying weaknesses, and crafting custom rules to achieve specific sandbox bypasses, moving beyond simple denial logs to active policy modification.

SELinux Fundamentals on Android

To effectively bypass SELinux, a solid grasp of its core concepts is essential:

• Subjects and Objects: Processes are subjects, and resources like files, directories, network sockets, IPC objects, and devices are objects.
• Security Contexts: Every subject and object has a security context (e.g., u:r:untrusted_app:s0 for an application, u:object_r:wifi_data_file:s0 for a Wi-Fi configuration file). This context comprises user, role, type, and sensitivity level. The “type” field is the most significant for policy decisions.
• Type Enforcement (TE): The primary mode of SELinux. Rules specify what types can access what other types, and with what permissions.
• Classes and Permissions: Objects belong to specific classes (e.g., file, socket, binder). For each class, a set of permissions exists (e.g., read, write, execute, call).
• Policy Rules: The heart of SELinux. Common rules include:
  • allow S T:C P;: Grants subject type S permission P to object type T of class C.
  • dontaudit S T:C P;: Prevents denials for this rule from being logged, useful for reducing noise.
  • neverallow S T:C P;: A critical rule that explicitly forbids specific access and is enforced during policy compilation. Circumventing neverallow rules is significantly harder, often requiring changes to the AOSP source or a deep understanding of policy enforcement.

The Sandbox Challenge: Why SELinux Matters for Exploitation

Traditional memory corruption vulnerabilities (like buffer overflows or use-after-free) often grant an attacker arbitrary code execution within the compromised process’s context. However, on Android, this is often insufficient for a full system compromise. Even with root privileges, SELinux might prevent a process from accessing files, interacting with critical services, or modifying system configurations, due to its MAC policies. This is where a targeted SELinux bypass becomes crucial.

Consider an `untrusted_app` that achieves arbitrary code execution. Without an SELinux bypass, it remains confined. Any attempt to read sensitive system files, modify a core system property, or inject into another process will likely trigger an AVC (Access Vector Cache) denial, logged by the kernel:

avc: denied { read } for pid=1234 comm=

        
        
        

            

                
            
            

                
Android Mobile Specs & Compare Directory
                
Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!
                Compare Devices Specs →