The Sandbox: Permissions, SELinux, and Isolation

Layer 1: The UID sandbox

This is the layer from Post 1, but it's worth seeing the full picture.

At install time, Android assigns your app a UID — say, 10143. Your app's data directory (/data/data/your.package.name/) is created with owner UID 10143 and permissions rwx------ (owner read/write/execute, no access for group or others). Every file your app creates inside this directory inherits the same ownership.

This is standard Unix file permission enforcement, running in the kernel's VFS (Virtual File System) layer. When your Dart code (through the Dart VM, through libc) calls open("/data/data/other.app/databases/secrets.db", O_RDONLY), the kernel's sys_openat handler checks:

Your Dart code gets a FileSystemException: Permission denied. The sandbox worked.

This extends beyond files. Network sockets carry the creating process's UID. The kernel can apply per-UID network rules (Android uses this for per-app data usage tracking and per-app VPN routing). When your app creates a TCP socket, the kernel tags it with UID 10143, and iptables/nftables rules can match on this UID.

The UID sandbox is effective because it's enforced by the kernel at the syscall level. There's no user-space code to bypass. The only way around it is running as UID 0 (root), which is why rooting a device fundamentally compromises app isolation.

Layer 2: Runtime permissions

The UID sandbox controls file access. Permissions control access to system capabilities — things that aren't files but that have privacy or security implications: camera, microphone, location, contacts, phone state, body sensors.

Before Android 6.0 (API 23), all permissions were granted at install time. The user saw a list of requested permissions, accepted all of them (or didn't install the app), and the app had those permissions forever. This was widely recognised as inadequate — users didn't read permission lists, and apps had no incentive to request minimal permissions.

Since Android 6.0, dangerous permissions require runtime requests. The app asks, the user decides, and the decision can be revoked at any time.

The enforcement happens in the system services, via Binder (Post 4). When your Flutter plugin calls CameraManager.openCamera(), the request goes through Binder to CameraService in system_server. The service calls checkCallingPermission("android.permission.CAMERA"), which checks whether the calling UID (your app's UID, stamped on the Binder transaction by the kernel) has been granted the CAMERA permission.

If the permission hasn't been granted, the call fails. The system service returns an error, which propagates back through Binder to your plugin's Kotlin code, which propagates it to Dart as an exception or error state.

The important point: the enforcement is in the system service, not in your app. Your app doesn't decide whether it has a permission — the system does, based on the UID and the permission grant state stored in PackageManagerService. This is why you can't "fake" a permission grant by modifying your own process. The check happens in a different process, and the identity is kernel-verified.

For Flutter, the permission_handler package wraps the Android permission request flow. Under the surface, it:

The system dialog runs in a different process specifically so the app can't influence or fake the user's choice.

Layer 3: SELinux

The UID sandbox and permissions are discretionary access control (DAC) — the owner of a resource can change its permissions. Root (UID 0) bypasses all DAC checks. This is a problem if any process running as root is compromised.

SELinux provides mandatory access control (MAC) — policies set by the system that even root cannot override (without disabling SELinux itself, which requires a kernel modification).

SELinux assigns a security context (label) to every process and every resource (file, socket, device, etc.). Policies define which contexts can access which other contexts, and in what ways.

adb shell ps -Z | grep your.package.name

u:r:untrusted_app:s0:c143,c256,c512,c768  u0_a143  14823  812  ...  your.package.name

Your app runs in the untrusted_app SELinux context. The system services run in different contexts (system_server, platform_app). Kernel resources have their own labels.

The SELinux policy for untrusted_app defines exactly what your app can do:

This is defence in depth. Even if the UID sandbox were somehow bypassed (a kernel bug, an escalation exploit), SELinux provides a second enforcement layer. A process running as UID 0 but in the untrusted_app SELinux context still can't access most system resources, because the MAC policy blocks it.

For Flutter developers, SELinux is mostly invisible — until it isn't. If a native plugin tries to access a file path or device that SELinux blocks, the operation fails with a permission error even though Unix permissions might have allowed it. The diagnostic tool:

adb logcat | grep "avc: denied"

SELinux denials show up as avc: denied in logcat, with the source context, target context, and the specific operation that was blocked. These messages are the clue that the failure is MAC (SELinux) rather than DAC (Unix permissions).

Layer 4: seccomp-bpf

Starting with Android 8.0, apps run under a seccomp-bpf filter — a kernel mechanism that restricts which system calls a process can make.

The filter is a BPF (Berkeley Packet Filter) program loaded into the kernel. Before each syscall executes, the kernel runs the filter to check if the syscall is allowed for this process. If the filter rejects it, the syscall fails or the process is killed.

Android's seccomp policy for apps blocks syscalls that normal apps should never need:

This is a last line of defence against exploits. Even if an attacker achieves code execution inside your app's process (through a buffer overflow in a native library, for example), the seccomp filter limits what they can do with that execution.

For normal Flutter development, seccomp is invisible. The Dart VM and Flutter engine only use standard syscalls (open, read, write, mmap, ioctl, epoll — the ones from Post 3). But if you're integrating a native library that uses unusual syscalls (perhaps for debugging or low-level system interaction), seccomp can be the reason it works on desktop Linux but fails on Android.

Layer 5: App-specific storage

Android 10 (API 29) introduced Scoped Storage, which fundamentally changed how apps access files outside their sandbox.

Before scoped storage, an app with the READ_EXTERNAL_STORAGE permission could read any file on shared storage — photos, downloads, documents from other apps. This was a privacy problem: a weather app with storage permission could read your private photos.

With scoped storage:

For Flutter, this affects plugins like image_picker, file_picker, and path_provider. The path_provider plugin returns paths to app-specific directories (which don't need permissions). The image_picker plugin uses the system photo picker (which handles permissions internally). Plugins that try to access raw file paths outside the app sandbox may work on older Android versions but fail silently or with permission errors on newer ones.

Understanding that "the file system" isn't a single, uniform space — but rather a set of sandboxed regions with different access rules — makes these failures predictable rather than surprising.

The sandbox from the kernel's perspective

From the kernel's viewpoint, your Flutter app's process has:

These are all kernel-enforced. No user-space code can override them without exploiting a kernel vulnerability. The combination creates a process that:

This is your Flutter app's world. Everything your Dart code does happens within these constraints. When a plugin opens the camera, it asks (via Binder) a system service (CameraService) that runs with higher privileges (the cameraserver SELinux context) to operate the camera hardware on the app's behalf. The app never touches the camera hardware directly.

Shared UID: the exception

By default, each app gets its own UID. But apps signed with the same key can declare a shared UID in their manifest, allowing them to run in the same sandbox — sharing file access, potentially sharing a process.

Google's own apps (GMS Core, Play Store, Play Services) use shared UIDs extensively. This is how Google Play Services can access data from multiple Google apps without explicit content providers.

For third-party developers, shared UIDs are strongly discouraged (and deprecated since Android 12 / API 31). They create security risks (a vulnerability in one app exposes the other's data) and complicate the installation/update lifecycle. For Flutter developers, shared UIDs are essentially irrelevant — each Flutter app is its own isolated process with its own UID.

The sandbox and debugging

The sandbox's enforcement has implications for debugging:

Debug builds vs release builds. Debug builds (installed via flutter run or adb install) get the debuggable flag, which relaxes certain restrictions: you can attach a debugger (ptrace is allowed for the specific debug connection), run-as works (you can access the app's data directory from the shell), and some SELinux restrictions are loosened.

Release builds run in the full sandbox. If your app works in debug but fails in release, the sandbox might be the reason — an operation that was permitted in the relaxed debug context is blocked in the strict release context.

`adb shell run-as your.package.name` drops you into a shell with your app's UID, letting you browse the app-specific data directory. This only works for debuggable builds.

Root access (adb root on userdebug builds, or rooted devices) bypasses UID-based DAC but does not bypass SELinux on enforcing builds. Even as root, avc: denied messages still appear. On userdebug builds, setenforce 0 disables SELinux enforcement temporarily — but production devices don't allow this.

The mental model

For day-to-day Flutter development, the sandbox is mostly invisible. Files read and write to the app's directory without issue. Plugins handle permission requests. System services respond to Binder calls. Everything works.

The sandbox becomes visible when something goes wrong — a permission denial, a file access failure on a new Android version, a native library that works in debug but not release. In those moments, knowing which layer is responsible is the difference between hours of debugging and minutes:

Each layer has its own diagnostic tool, its own error signature, and its own solution. They're not redundant — they defend against different attack vectors. Together, they make Android's app isolation one of the strongest in any consumer operating system.

The final post in this series traces the build pipeline: from flutter build apk on your machine to an installed, running app on the device, following every transformation the code undergoes.

This is Post 9 of the [Android Under the Surface](/blog/android-under-the-surface) series. Previous: [From Render Tree to Pixels: The Display Pipeline](/blog/android-surfaceflinger-display-pipeline-flutter). Next: [The Build Pipeline: From Source to Installed App](/blog/android-flutter-build-pipeline-apk).