Introduction

Android’s security architecture is built upon a layered defense mechanism, with SELinux (Security-Enhanced Linux) serving as a critical pillar for Mandatory Access Control (MAC). While SELinux significantly reduces the attack surface, misconfigurations or overly permissive rules within its policy can introduce critical privilege escalation vectors, offering pathways for zero-day exploitation. This article delves into the expert-level process of reverse engineering Android SELinux policies, providing a structured methodology to uncover these latent vulnerabilities and reinforce MAC hardening strategies.

Understanding and dissecting the SELinux policy is paramount for security researchers and penetration testers. It allows us to move beyond superficial vulnerabilities and identify fundamental flaws in the system’s access control, enabling the discovery of high-impact escalation paths that bypass traditional security boundaries.

Understanding Android SELinux Fundamentals

The TE Model and Policy Files

SELinux operates on the Type Enforcement (TE) model, where every process (domain) and object (file, socket, IPC) is assigned a type. Access decisions are then made based on rules defining which domains can interact with which types in what manner. Android’s SELinux policy is compiled into a binary format (`sepolicy`) and loaded at boot time. Key components of the policy include:

• sepolicy: The main policy file containing all type definitions, attributes, and access rules (allow, neverallow, dontaudit).
• file_contexts: Maps file paths to their SELinux types. This is crucial for understanding how files on the filesystem are labeled.
• genfs_contexts: Defines contexts for pseudo-filesystems like proc and sysfs.
• service_contexts: Maps Binder services to their SELinux types.
• hwservice_contexts: Maps Hardware Binder services to their SELinux types.
• property_contexts: Maps Android system properties to their SELinux types.

Permissive vs. Enforcing

SELinux can operate in two primary modes: permissive and enforcing. In permissive mode, access denials are logged but not enforced, allowing the operation to proceed. This is often used during development. In enforcing mode, denials are both logged and blocked, actively preventing unauthorized access. Zero-day discovery typically focuses on devices running in enforcing mode, as this reflects the production environment.

You can check the current SELinux mode on a device via adb shell:

adb shell su -c 'cat /sys/fs/selinux/enforce'

A value of 1 indicates enforcing mode, while 0 indicates permissive.

Essential Tools for SELinux Policy Analysis

Effective SELinux policy analysis relies on a suite of specialized tools:

• adb: For interacting with the Android device (pulling files, executing commands).
• checkpolicy: A utility from AOSP for compiling and disassembling SELinux policies. The -d flag is crucial for disassembling.
• sepolicy-inject: A powerful tool for modifying, analyzing, and even injecting rules into a policy.
• sesearch: From the SELinux userspace tools, it allows querying the policy for specific rules or permissions.
• apol: A policy analysis tool that provides a structured view and can compare policies.
• grep/awk/sed: Standard Unix tools for parsing and filtering text output from disassembled policies.

The first step involves obtaining the policy from the target device:

adb pull /sys/fs/selinux/policy .

This command pulls the live, currently loaded SELinux policy binary from the device to your local machine.

Reverse Engineering the SELinux Policy

Extracting and Disassembling

Once you have the policy file, the next step is to disassemble it into a human-readable format. The checkpolicy tool, usually available in the AOSP source tree or as a standalone binary, is used for this purpose:

checkpolicy -d policy > sepolicy.conf

This command disassembles the binary policy file into sepolicy.conf, which will contain all the policy definitions, rules, and types in a text format. This file can be very large, often tens of thousands of lines.

Navigating the Disassembled Policy

The sepolicy.conf file is organized into various sections. Key elements to focus on include:

• Type Definitions: type domain, domain_type; or type file_type;. These define the labels used.
• Attributes: attribute domain; or typeattribute type attribute;. Attributes group types, allowing rules to apply to multiple types simultaneously. For instance, untrusted_app is an attribute for all user-installed applications.
• Access Vector Rules: These are the core of SELinux policy and dictate allowed interactions. The primary rule types are:
  • allow source_type target_type:class { permissions };: Grants specific permissions.
  • neverallow source_type target_type:class { permissions };: Explicitly forbids permissions, often used to prevent common attack vectors. If violated, policy compilation fails.
  • dontaudit source_type target_type:class { permissions };: Suppresses logging of denial messages for specific accesses. This can hide potential issues.

For example, an allow rule might look like this:

allow untrusted_app system_file:file { read execute getattr };

This rule permits applications labeled as untrusted_app to read, execute, and get attributes of files labeled as system_file.

Identifying Privilege Escalation Vectors

Searching for Overly Permissive Rules

The primary goal is to identify allow rules that grant excessive permissions to lower-privileged domains, particularly untrusted_app, platform_app, or similar domains that attackers might initially compromise. Focus on dangerous permissions and classes:

• Dangerous Classes: file, dir, socket, process, service_manager, binder, capability, system.
• Dangerous Permissions: write, read (on sensitive files), execute, setattr, link, mount, bind, call, transfer, setcap, dac_override, dac_read_search.

Use grep to search the disassembled policy for suspicious patterns. Start broadly and then refine your search:

grep -E

        
        
        

            

                
            
            

                
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 →