Introduction: Understanding SEAndroid and Its Role in Android Security

SEAndroid (Security-Enhanced Android) is a mandatory access control (MAC) system that builds upon the Linux kernel’s Security-Enhanced Linux (SELinux) module. Its primary purpose is to confine privileged processes and limit the damage that can be done if a process is compromised. Unlike discretionary access control (DAC), where access is determined by user and group IDs, MAC policies dictate access based on security contexts (type, user, role, sensitivity) assigned to processes and objects (files, sockets, IPC, etc.). While SEAndroid significantly hardens the Android ecosystem, misconfigurations, design flaws, or kernel vulnerabilities can lead to policy bypasses, enabling privilege escalation.

This guide delves into the methodologies for identifying and exploiting SEAndroid policy weaknesses to achieve privilege escalation on Android devices. We will cover fundamental concepts, analytical tools, and a practical, illustrative scenario.

SEAndroid Fundamentals: Contexts, Types, and Domains

At the core of SEAndroid are security contexts. Every process, file, and IPC mechanism on an Android device has an associated security context. A typical context looks like u:object_r:system_file:s0 for files or u:r:untrusted_app:s0 for processes. Key components include:

• User (u:): Identifies the SELinux user. Typically u for unprivileged, system_u for system processes.
• Role (r:): Defines the role, often object_r for objects and r for processes.
• Type (t:): The most critical component. It defines the kind of object or process. E.g., system_file_t, untrusted_app_t, init_t. Policies specify rules based on types.
• Sensitivity (s0): Used for multi-level security (MLS), less common in Android’s standard policy enforcement.

A domain is essentially the type assigned to a process. For instance, an application running in the browser sandbox might be in the webbrowser_t domain, while a standard app runs in untrusted_app_t. SEAndroid policies define what interactions are allowed between domains and between domains and object types.

Example Contexts:

$ adb shell id -Z # Process context of current shellu:r:shell:s0$ adb shell ls -Z /data/local/tmp/foo.txtu:object_r:shell_data_file:s0 /data/local/tmp/foo.txt$ adb shell ps -Z | grep mediaserveru:r:mediaserver:s0 mediaserver

Common SEAndroid Policy Bypass Vectors

Exploiting SEAndroid policy often involves identifying where the policy grants more permissions than necessary or where a less privileged domain can influence a more privileged one. Common vectors include:

• Misconfigured Policy Rules

  Policies can be overly permissive, either intentionally for debugging/development or due to oversight. For example, a rule might allow an untrusted_app_t to write to a file type that a higher-privileged service later reads or executes.

• Type Confusion / Incorrect Labeling

  If a file or IPC object is incorrectly labeled, a less privileged domain might gain access it shouldn’t have. This can happen during file creation if the creating process’s context or directory context leads to an unintended type.

• Service Vulnerabilities (IPC Exploitation)

  A privileged system service (e.g., a Binder service or a custom HAL) might have a vulnerability (e.g., arbitrary file write, code execution) that can be triggered by a less privileged client. If SEAndroid allows the less privileged client to connect to this service, then exploiting the service’s vulnerability can lead to privilege escalation *within* the service’s domain.

• Policy Logic Errors

  Sometimes, the logic of the policy itself can be flawed. For example, a chain of operations, each individually permitted, might collectively lead to an unintended privilege escalation.

Step-by-Step Guide: Identifying and Exploiting a Policy Weakness

Let’s walk through a hypothetical scenario to illustrate the process. Our goal is to gain arbitrary file write access from an untrusted_app_t context, leveraging a flaw in a custom system service.

Phase 1: Reconnaissance and Target Identification

Assume we’ve found a way to execute code in the untrusted_app_t domain (e.g., via an app vulnerability). We’re looking for a higher-privileged service that might expose an exploitable interface or interact with objects in a vulnerable way.

We can use ps -Z and ls -Z to identify interesting processes and files. Let’s say we find a custom service, com.example.SystemConfigService, running in the system_server_t domain (or a custom my_service_t domain) and noticing it periodically reads configuration from /data/misc/custom_config/.

$ adb shell ps -Z | grep 'custom_service_process_name'u:r:my_service_t:s0 com.example.custom_service.MyServiceProcess$ adb shell ls -Z /data/misc/custom_config/config.jsonu:object_r:my_service_data_file:s0 /data/misc/custom_config/config.json

Phase 2: Policy Analysis

Our goal is to write to /data/misc/custom_config/config.json. First, we need to understand the permissions. We can analyze the SEAndroid policy. On a rooted device or with AOSP tools, we can use sesearch or sepolicy-analyze.

Using sesearch (available in AOSP or by compiling SELinux userspace tools):

$ sesearch -A -s untrusted_app_t -t my_service_data_file -c file -p writeFound 0 allow rules.$ sesearch -A -s untrusted_app_t -t my_service_data_file -c dir -p add_name,createFound 0 allow rules.

This indicates untrusted_app_t cannot directly write to `my_service_data_file` or create files in the directory.

However, let’s say during our investigation, we find an interesting log message or documentation snippet for our custom service that indicates it *also* processes config files from /data/local/tmp/ if they exist, possibly for