UID Sandbox & App Isolation

Android leverages the standard Linux user-based protection facility to identify and isolate application resources. This fundamental concept, often called the Application Sandbox, ensures that applications cannot arbitrarily read or modify each other's data or interfere with system processes.

Every App Runs as a Unique UID

In a standard Linux desktop environment, a single user (e.g., alice) runs multiple applications (browser, text editor), and all those applications share the same User ID (UID). They can generally read and write to the same files in /home/alice.

Android flips this paradigm. In Android, each application is treated as a distinct "user" from the kernel's perspective. When an app is installed, the Android system assigns it a unique, persistent Linux UID. For example, App A might be assigned UID 10045, and App B might be assigned UID 10046.

Process Isolation via UID

Because each app has a unique UID, the Linux kernel's Discretionary Access Control (DAC) seamlessly enforces isolation.

1. Filesystem Isolation: When App A's process creates a file in its private data directory (/data/data/com.example.appa/), the file is owned by UID 10045. The default permissions (rwx------) prevent App B (UID 10046) from reading or writing to that file.
2. Process Isolation: The kernel prevents App B from sending signals (like SIGKILL) or attaching debuggers (ptrace) to App A's processes, because they are owned by different UIDs.

This mechanism is robust because it relies on the deeply tested core security features of the Linux kernel, rather than a custom userspace sandbox.

Shared UID Use Cases

While isolation is the default, there are scenarios where applications developed by the same publisher need tight integration and shared data access. Android provides the android:sharedUserId attribute in the AndroidManifest.xml for this purpose.

If two apps declare the same sharedUserId and are signed with the exact same developer certificate, the system assigns them the same Linux UID at install time.

Consequences of Shared UID:

• Both apps can freely read and write each other's private data directories.
• Both apps can run components (Activities, Services) in the same Linux process using the android:process attribute, saving memory overhead.

Note: Google has deprecated sharedUserId in recent API levels due to security complexities and encourages using explicit mechanisms like ContentProvider or Service binding for data sharing instead.

seccomp Filtering for App Processes

To further restrict the attack surface of the Application Sandbox, Android employs seccomp-bpf (Secure Computing with Berkeley Packet Filter).

While UIDs restrict access to files and other processes, seccomp restricts access to the kernel itself. When the zygote process forks a new application process, it applies a strict seccomp filter.

This filter acts as an allowlist of system calls (syscalls). If a compromised app attempts to invoke an obscure or restricted kernel syscall (like kexec_load or swapon), the kernel intercepts the call via the seccomp filter and instantly terminates the process with a SIGSYS signal. This significantly mitigates kernel privilege escalation exploits launched from untrusted app code.