Introduction

Android’s security architecture is robust, built upon several layers designed to protect user data and maintain system integrity. At its core, the app sandbox isolates applications, preventing them from accessing each other’s data or critical system resources without explicit permission. Complementing this is SELinux (Security-Enhanced Linux), a Mandatory Access Control (MAC) system that further refines what processes can access which resources, even for privileged users like root. While these layers are crucial for security, they present significant challenges for mobile forensics, data recovery, and advanced debugging. This hands-on lab will guide you through understanding Android’s SELinux enforcement and demonstrate practical techniques to bypass these restrictions to gain unrestricted access to sandboxed application data on a rooted device.

Understanding Android SELinux and the App Sandbox

What is SELinux?

SELinux operates on the principle of least privilege, assigning security contexts (labels) to every file, process, and system resource. It then uses a policy to determine whether a process with a specific context is allowed to perform an action (like read, write, execute) on a resource with another specific context. On Android, this means even if a process runs as root, SELinux can still deny its access to files if the process’s context is not explicitly permitted by the policy to interact with that file’s context. This granular control prevents many traditional root-based attacks and enhances overall system security.

The Android App Sandbox

Each Android application runs in its own isolated environment, known as the app sandbox. This isolation is primarily achieved through Linux user IDs (UIDs) and group IDs (GIDs), where each app is assigned a unique UID. This prevents one app from directly reading or writing another app’s data. SELinux adds a critical layer to this sandbox. Even if you gain root privileges on the device, the shell process (or any other process you might launch as root) often runs with a restricted SELinux context, such as u:r:shell:s0. This context is typically not permitted to directly access files labeled with an app’s data context (e.g., u:object_r:app_data_file:s0), creating a barrier even for root users.

Prerequisites for This Lab

• Rooted Android device: A device rooted with Magisk is highly recommended, as it provides a robust and manageable root environment.
• ADB (Android Debug Bridge): Installed and configured on your workstation.
• Basic Linux shell familiarity: Knowledge of commands like cd, ls, cp, tar, and su.
• A target application: Any installed application on the device will serve for testing purposes (e.g., a simple notes app, a game, or a browser).

Identifying Target App Data and SELinux Contexts

Before attempting to bypass SELinux, we need to know where the target app’s data resides and what its SELinux context is.

Locating App Data

Android applications store their private data, such as databases, shared preferences, and internal files, within specific directories. The primary location is typically /data/data/<package_name>.

adb shell
pm path com.android.chrome
# Example output: package:/data/app/com.android.chrome-abcdefg==/base.apk

# Now, let's explore its data directory
adb shell
su -c 'ls -laZ /data/data/com.android.chrome/'

The ls -laZ command lists the files and directories along with their SELinux contexts. You’ll likely see contexts like u:object_r:app_data_file:s0, indicating app-specific data.

Understanding SELinux Contexts

An SELinux context typically follows the format: user:role:type:sensitivity. For instance, u:object_r:app_data_file:s0 indicates:

• u: The SELinux user.
• object_r: The role (here, indicating an object like a file or directory).
• app_data_file: The type, which is the most critical part for policy decisions. This identifies the resource as belonging to an application’s private data.
• s0: The sensitivity level (often not strictly enforced on Android for app data).

The key takeaway is that a process running with the shell type (e.g., u:r:shell:s0) is generally forbidden from directly interacting with resources labeled app_data_file, even with root privileges.

Hands-On Lab: Bypassing SELinux for Data Acquisition

Our