Introduction to SEAndroid and Mandatory Access Control

SEAndroid (Security-Enhanced Android) is a mandatory access control (MAC) system implemented in Android, built upon the Linux Security Modules (LSM) framework and SELinux. Unlike discretionary access control (DAC), where the owner of a resource can grant or deny access, MAC enforces a system-wide security policy that cannot be overridden by individual users or processes. SEAndroid’s primary goal is to isolate applications and system services, limiting the damage an exploited component can inflict on the system.

At its core, SEAndroid labels every subject (process) and object (files, sockets, IPC mechanisms) with a security context. The SEAndroid policy then defines what interactions are permitted between these contexts. For instance, an application running in the `app_domain` context is strictly limited in what files it can access or what system services it can interact with, preventing unauthorized privilege escalation or data exfiltration.

Understanding SEAndroid Domains

Confined vs. Unconfined Domains

SEAndroid categorizes processes into various domains, each with a specific set of permissions. These domains are broadly classified into two types: confined and unconfined.

• Confined Domains: These are the backbone of Android’s security model. Most user-facing applications, system services (like `zygote`, `installd`, `mediaserver`), and core components run within highly restricted, confined domains. Their policies are meticulously crafted using the principle of least privilege, allowing only the bare minimum operations required for their functionality. For example, an `app_domain` process can only access its own private data directory and interact with a predefined set of system services.
• Unconfined Domains: In contrast, unconfined domains operate with significantly broader permissions. They are typically reserved for critical system processes that require extensive access to system resources, often during the early boot stages or for debugging purposes. The most prominent example is the `init` process, which is responsible for spawning all other processes. Other examples might include the kernel (`kernel`), `untrusted_app` (a fallback domain for apps whose contexts cannot be determined), or specific debug services on developer builds. While they might still have *some* restrictions, their default stance is much more permissive than confined domains.

The existence of unconfined domains is a necessity for system operation. However, their broad permissions make them attractive targets for attackers seeking to bypass SEAndroid’s strong isolation. A successful compromise within a confined domain often aims to transition into, or leverage the privileges of, an unconfined domain.

The Threat of Unconfined Domains

The primary threat posed by unconfined domains lies in their extensive capabilities. If an attacker can find a way for a compromised confined process to either:

1. Directly transition into an unconfined domain.
2. Interact with an unconfined process in a way that leads to arbitrary code execution or privilege escalation within that unconfined process.

…then the attacker effectively bypasses most SEAndroid restrictions. Since many unconfined domains (like `init`) also run with `root` privileges, this often translates directly into a full system compromise.

Practical Exploitation Techniques

Leveraging Misconfigurations and Transition Rules

SEAndroid policy misconfigurations can inadvertently create pathways for confined domains to escalate privileges. One such weakness involves overly permissive domain transition rules or broad file/IPC permissions granted to confined domains that interact with unconfined ones.

Consider a hypothetical `sepolicy` rule snippet:

# policy.te
type my_confined_app_domain, domain;
type unconfined_daemon_exec, exec_type, file_type, system_file_type;

init_daemon_domain(my_confined_app_domain)

# This rule would allow my_confined_app_domain to execute an unconfined daemon
allow my_confined_app_domain unconfined_daemon_exec:file { execute execute_no_trans };

# More dangerously, if it transitions without proper checks
# allow my_confined_app_domain unconfined_daemon_domain:process transition;

If a confined application (`my_confined_app_domain`) is allowed to execute an executable that starts a process in an unconfined domain (`unconfined_daemon_exec`) without proper transition rules (`execute_no_trans`), or if it can trigger a transition to an overly permissive domain, it can bypass its own restrictions. Attackers actively search for these ‘holes’ where confined processes are granted permissions that enable them to escape their sandbox.

Interacting with Unconfined Services/Processes

Attackers often look for IPC channels (Binder services, Unix domain sockets, shared memory) exposed by unconfined processes. If an unconfined service has a vulnerability (e.g., buffer overflow, arbitrary file write via input, command injection), a compromised confined process could exploit it to execute code within the unconfined context.

Steps for identifying targets:

1. Identify unconfined processes: Use `adb shell ps -AZ` to list processes with their SEAndroid contexts. Look for domains like `init`, `kernel`, `unconfined_daemon`, or contexts that appear unusually broad.
2. Analyze their exposed interfaces: For a target unconfined process, investigate what Binder services it registers (`dumpsys activity services`), what Unix domain sockets it creates (`ls -Z /dev/socket`), or what shared memory it uses.
3. Probe for vulnerabilities: If a confined app can send arbitrary data to an unconfined service, look for common vulnerabilities in the unconfined service’s parsing or processing logic.

File System Access Abuse

Even if direct code execution isn’t possible, an unconfined domain might create or interact with files in a way that allows a confined process to achieve a partial bypass. For instance, an unconfined process might create a temporary directory or file with permissive DAC permissions (e.g., world-writable) or an incorrect SEAndroid context. A confined attacker could then exploit this to:

• Symlink Attacks: Create a symlink in the permissive location pointing to a sensitive file (e.g., `/data/system/users/0/settings_secure.xml`), hoping the unconfined process will later read/write through the symlink.
• Arbitrary File Overwrite/Read: If the unconfined process writes to a predictable path, and the confined process can manipulate the content before the write, or if the confined process can read from a path an unconfined process later populates with sensitive data.

Checking contexts of common temporary directories:

# adb shell ls -Zd /data/local/tmp
drwxrwxrwt root root u:object_r:shell_data_file:s0 /data/local/tmp

In this example, `/data/local/tmp` has the `shell_data_file` context. If an unconfined process were to use this directory and not specifically relabel files it creates, there might be opportunities for manipulation.

Debugging and Diagnostic Features

Developer builds or devices rooted by enthusiasts often have more relaxed SEAndroid policies or features like `adb root` enabled. `adb root` essentially restarts the adb daemon as `root`, running in a highly privileged context, often `init` or `adbd_root`. While not a policy bypass on its own, it creates an environment where `setenforce 0` (disabling SEAndroid) or direct interaction with sensitive system components becomes possible, highlighting the power of operating in an unconfined manner.

Analyzing SEAndroid Policies for Weaknesses

Using `audit2allow` (Reverse Engineering)

When SEAndroid denies an operation, it logs an