Introduction: The Imperative of SEAndroid Policy Analysis

SEAndroid, Google’s implementation of SELinux for Android, stands as a critical pillar in the platform’s security architecture. It enforces Mandatory Access Control (MAC) policies, strictly limiting what processes can access, preventing traditional Linux discretionary access control bypasses. For exploit developers, understanding and ultimately bypassing SEAndroid policies is paramount for achieving sandbox evasion and privilege escalation. This deep dive will guide you through the process of reverse engineering SEAndroid policies, identifying weaknesses, and exploring common bypass techniques crucial for advanced exploit development.

Understanding SEAndroid Fundamentals

At its core, SEAndroid operates on a principle where every resource (files, processes, sockets, etc.) and every action is assigned a security context. Policies define what interactions are permitted between these contexts. Key concepts include:

• Security Contexts: Labels like u:r:system_app:s0 assigned to processes and resources. These contexts are composed of user, role, type, and sensitivity. The ‘type’ (e.g., system_app) is the most frequently used component in policy rules.
• Domains: Process types, e.g., untrusted_app_25_domain for sandboxed apps, init_t for the init process.
• Types: Labels for files, directories, sockets, etc., e.g., device, system_file, app_data_file.
• Policy Rules: Expressed as allow source_domain target_type:class { permissions }. For instance, allow untrusted_app_domain app_data_file:file { read write } would permit an untrusted app to read and write its own data files.
• Type Enforcement (TE) Language: The human-readable language used to write policies before compilation into binary format.

SEAndroid operates in either enforcing mode (blocking all unauthorized actions) or permissive mode (logging violations but allowing them). Exploitation efforts are typically aimed at devices in enforcing mode.

Obtaining and Decompiling SEAndroid Policy

The first step in reverse engineering is to obtain the policy itself. This can often be found in the boot.img or directly on a rooted device.

1. Extracting the Binary Policy

On a rooted device, the active policy is usually located at /sys/fs/selinux/policy.

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

Alternatively, if you have a boot.img, you can extract the kernel and ramdisk, where the policy might reside. Tools like AOSP-tools/split_bootimg.py can help with this.

2. Decompiling the Binary Policy

The raw binary policy needs to be converted into a human-readable format, typically CIL (Common Intermediate Language) or TE (Type Enforcement).

• Using secilc: The official SELinux policy compiler/decompiler. You’ll need to compile it from SELinux userspace source or find a pre-compiled version.

# Assuming secilc is in your PATH and sepolicy.raw is the extracted policyadb shell secilc -M -P sepolicy.raw -o sepolicy.cil

This command attempts to decompile the binary policy (`sepolicy.raw`) into CIL (`sepolicy.cil`). Note that `secilc` might require specific versions or dependencies.

• Using sepolicy-analyze: A powerful tool often found in SELinux development environments.

sepolicy-analyze -p sepolicy.raw info

While sepolicy-analyze doesn’t directly decompile to TE/CIL, it provides invaluable insights into the policy structure, types, rules, and more, which is crucial for identifying potential weaknesses.

Identifying Policy Weaknesses and Bypass Techniques

Once you have a decompiled or analyzed policy, the goal is to find rules that can be abused by a lower-privileged domain to gain higher privileges or access restricted resources.

1. Permission Mining: Searching for Overly Permissive Rules

Start by identifying the domain you want to escape (e.g., untrusted_app_domain) and look for unusual permissions it holds.

• Searching for sensitive permissions: Look for `execmem`, `setuid`, `setgid`, `dac_override`, `chown`, or extensive `write` access to system-controlled files.

# Example: Searching sepolicy.cil for 'execmem' permission granted to untrusted_app_domaingrep 'allow untrusted_app_domain .* { .*execmem.* }' sepolicy.cil

While `execmem` is rare for untrusted apps, similar searches for file operations on sensitive system directories (e.g., /data/misc/, /dev/, /proc/) can yield interesting results.

2. Type Transition Exploits

type_transition rules are designed to automatically assign a specific security context to newly created files or objects under certain conditions. If a low-privileged domain can create a file that automatically transitions to a more privileged type, this can be exploited.

• Syntax: type_transition source_domain target_type:class default_type;

Example Scenario: Imagine a rule like:

type_transition untrusted_app_domain app_data_file:file app_temp_file;

And later, a different rule allows a privileged service to perform sensitive operations on app_temp_file:

allow privileged_service_domain app_temp_file:file { execute };

If the untrusted_app_domain can control the content of a file it creates which then transitions to app_temp_file, and a privileged service later executes it, this becomes a path for privilege escalation. The attacker would create an executable file with malicious payload in the designated location, relying on the type transition and subsequent privileged execution.

3. Domain Transition Exploits

domain_transition rules allow a process running in one domain to transition to another, often more privileged, domain when executing a specific binary.

• Syntax: domain_transition source_domain target_domain:process { execute };

Example Scenario: A rule like:

domain_transition untrusted_app_domain system_app_domain:process { execute };

combined with an entrypoint rule:

entrypoint untrusted_app_domain system_app_exec_file:file;

This would imply that if `untrusted_app_domain` executes a file labeled `system_app_exec_file`, it transitions to `system_app_domain`. The exploit would involve finding a way for the untrusted app to write to a location that gets labeled as `system_app_exec_file` (perhaps via a `type_transition` issue or a file labeling mistake) and then executing that file.

4. File Context/Labeling Issues

Incorrectly labeled files or directories are a common source of vulnerabilities. If a sensitive file or directory has an overly broad context (e.g., writable_file_type) that allows a low-privileged domain to write to it, an attacker can substitute malicious content.

• Analyzing `file_contexts`: This file (often in `sepolicy/file_contexts`) maps file paths to their security contexts.

# Example entry in file_contexts/data/local/tmp(/.*)? u:object_r:app_data_file:s0

If a critical system executable (e.g., `update_engine`) is found to have a file context that allows modification by an untrusted app (highly unlikely in modern Android, but serves as an illustration), this is a critical bypass.

5. Service Manager Interaction Exploits

Android’s Binder IPC system relies on the Service Manager, and SEAndroid policy governs which domains can register, add, and call services. Misconfigurations here can allow unauthorized service interactions.

• Policy rules for services: Look for `add`, `find`, `call` permissions related to the `service_manager` class.

# Example: Checking which domains can 'add' a serviceallow untrusted_app_domain service_manager_type:service_manager { add };

If an untrusted app can add a service that is then called by a privileged domain with inadequate input validation, it could lead to vulnerabilities. Similarly, if an untrusted app can call a sensitive internal service without proper policy restrictions, it might expose functionality intended for privileged components.

Conclusion

Reverse engineering SEAndroid policy is an intricate but essential skill for advanced Android security research and exploit development. By systematically obtaining, decompiling, and analyzing the policy, and by understanding how permissions, type transitions, domain transitions, and file contexts interplay, attackers can identify the subtle misconfigurations that lead to powerful sandbox escapes and privilege escalations. The constant evolution of SEAndroid makes this a continuous learning process, emphasizing the need for meticulous analysis and creative thinking in an ever-hardening environment.