Introduction to Android Sandboxing and Linux Namespaces

Android’s security model heavily relies on its application sandbox, where each app runs under a unique UID/GID, providing basic process and data isolation. While effective for typical user applications, this model has limitations for advanced use cases such as security research, fine-grained application virtualization, or running untrusted binaries with minimal host impact. This is where Linux Namespaces offer a powerful, lower-level mechanism to achieve deeper isolation, creating a custom sandbox environment that goes beyond Android’s default security.

Linux Namespaces allow a process or a group of processes to have an isolated view of certain global system resources. By creating a new namespace, a process can perceive that it has its own independent instance of a resource, such as process IDs, mount points, network interfaces, or user IDs. This article will delve into leveraging user, pid, and mount namespaces to construct a highly isolated Android sandbox.

Understanding Key Linux Namespaces for Android Isolation

To build our custom sandbox, we’ll focus on three critical namespaces:

User Namespaces (CLONE_NEWUSER)

User namespaces are arguably the most powerful for sandboxing. They allow a process to have a set of user and group IDs that are distinct from those in the parent (initial) user namespace. Crucially, a process can be granted root privileges (UID 0) *within* its user namespace without having root privileges on the host system. This means a sandboxed process can perform actions requiring root (like mounting filesystems or creating devices) without compromising the entire Android system.

The process of setting up a user namespace involves:

1. Creating a new user namespace.
2. Mapping UIDs and GIDs from the parent namespace to the child namespace. For instance, the host’s root (UID 0) could be mapped to an unprivileged user (e.g., UID 1000) in the child namespace, while an unprivileged user (e.g., UID 1000) on the host could be mapped to root (UID 0) within the child namespace.

PID Namespaces (CLONE_NEWPID)

PID namespaces isolate the process ID space. A process that is the first process in a new PID namespace will have PID 1 within that namespace, independent of its PID in the parent namespace. This effectively hides other host processes from the sandboxed environment and allows for independent process management, including the ability to run an init-like process within the sandbox without affecting the main Android init process.

Mount Namespaces (CLONE_NEWNS)

Mount namespaces provide an isolated view of the filesystem hierarchy. Processes within a new mount namespace will not see changes to the filesystem made in other mount namespaces, nor will changes made within the new namespace affect the host filesystem (unless explicitly propagated). This is fundamental for controlling what the sandboxed application can access and modifying its perceived root filesystem (`/`) without impacting the main Android system.

Building the Sandbox: A Conceptual and Practical Approach

Creating a robust sandbox requires a rooted Android device with kernel support for these namespaces (most modern Android kernels support them). The primary tools will be unshare and nsenter, typically available via busybox or a custom build on a rooted device.

Step 1: Setting up User and PID Namespaces

We’ll start by creating a new user and PID namespace. The unshare utility is perfect for this. We’ll use the -U flag for a user namespace, -m for a mount namespace (essential for the next step), -p for a PID namespace, and -r to make the current process root in the new user namespace. The --mount-proc flag is crucial to mount a new /proc filesystem within the new mount namespace, which is necessary for the new PID namespace to function correctly.

adb shell
su
unshare -Umpf --mount-proc /system/bin/sh

After running this, you’ll be inside a new shell. If you type id -u, you should see 0, indicating you are root within this new user namespace. If you type ps, you’ll likely see a very sparse process list, indicating the PID namespace is active.

Next, we need to map UIDs and GIDs. This step is critical to ensure that permissions are correctly interpreted inside the namespace relative to the outside. This mapping is done by writing to /proc/self/uid_map and /proc/self/gid_map from within the new namespace. For security, we map an unprivileged host user (e.g., shell user with UID 2000) to root (UID 0) inside the namespace, and map host root (UID 0) to a high-numbered unprivileged UID inside the namespace:

echo "0 2000 1" > /proc/self/uid_map
echo "0 2000 1" > /proc/self/gid_map
echo "1 0 1" > /proc/self/uid_map
echo "1 1000 65535" > /proc/self/uid_map
echo "1 0 1" > /proc/self/gid_map
echo "1 1000 65535" > /proc/self/gid_map

This mapping states: