11.4 Mobile App Permissions and Sandbox Basics
One App, One UID
The mobile sandbox is kernel machinery, not a promise. Android assigns every app a unique Linux UID and confines its private data directory, then layers SELinux type enforcement so a process cannot reach another domain's files, sockets, or sensors even as itself. iOS wraps each app in a container gated by code-signing entitlements plus a filtered syscall boundary. Code signing, store vetting, and exploit mitigations make direct escapes rare and expensive, so real-world abuse goes through the front door: the capabilities you already granted. The kernel faithfully enforces whatever permission state you approved.
Gates That Ask Before Opening
Android moved sensitive capabilities into runtime "dangerous" permissions -- CAMERA, RECORD_AUDIO, ACCESS_FINE_LOCATION -- requested at first use and revocable from settings. iOS works the same way but tracks background refresh separately. Two Android behaviors quietly matter most: one-time grants that expire after a single task, and auto-reset that strips permissions from apps you have not opened for months, neutralizing that flashlight app you installed once in 2023.
Background Location: A Gate With a Schedule
Location carries a timing dimension. With "only while using the app," the OS refuses background fixes outright -- the request does not silently return stale data, it is denied -- and the system lights an indicator whenever the mic, camera, or precise location is live. "Always" is a separate explicit grant, and the geofencing API is the sanctioned pattern for location-triggered behavior: the OS wakes the app at a boundary instead of letting it poll. Read the special-access list too: accessibility services, notification listeners, and device admin can read your entire screen -- far more potent than any camera permission.
Data Boundaries Beyond the Gate
Cross-app channels are the remaining path: Android's scoped storage narrows shared-media access, intents and share sheets pass sanitized handles rather than raw files, and iOS warns apps reading the clipboard after another app copied. Sideloading skips the store's pre-install review, making the source itself part of your permission decision. Apply least privilege on sight: deny contacts to the flashlight app -- it still works, because it never needed them.
Architecture Diagram
Key Takeaways
- Sandboxing is enforced per-UID with SELinux (Android) or signed containers (iOS) -- app-to-app reads are refused in the kernel.
- Runtime permissions are revocable at any time; audit settings and deny anything the app's stated function does not need.
- While-in-use location means background requests are actually denied; "always" and accessibility access deserve extra suspicion.
- Indicators (mic/camera/location dots) tell you when a sensor is live -- trust the indicator over the app's marketing.
- Auto-reset and one-time grants are your safety net, but sideloaded apps skip vetting -- the source is part of the grant.