How iOS 12 Sandboxing Isolates App Data

In Apple's iOS 12, application sandboxing serves as a foundational security architecture designed to prevent applications from compromising the underlying operating system or accessing data stored by other apps. By establishing distinct boundaries at both the file system and kernel levels, iOS 12 ensures that third-party applications operate strictly within their designated environments. This overview examines the specific mechanisms iOS 12 uses to enforce sandboxing, including isolated directory containers, kernel-level access controls, and restricted inter-process communication.

Containerized File Systems

Every third-party app installed on iOS 12 is placed inside its own container directory at runtime. The operating system assigns a unique, randomized Globally Unique Identifier (GUID) to each app's container directory path upon installation. This structure isolates the app’s files from the rest of the file system and divides storage into specific functional containers:

  • Bundle Container: Holds the executable binary, assets, and read-only resources packaged with the app.
  • Data Container: Divided into standard directories like Documents (user-generated content), Library (caches, preferences, and state data), and tmp (transient files cleared automatically).
  • iCloud and App Group Containers: Explicitly declared shared containers accessible only if designated within the app's cryptographic entitlements.

An app cannot traverse outside its assigned directories via standard file path operations. Attempts to access system directories (such as /System or /private) or directories belonging to other applications are immediately rejected at the file system level.

Kernel-Level Enforcement via TrustedBSD

The core boundary enforcement in iOS 12 is governed by the Mach/XNU kernel using a framework derived from TrustedBSD Mandatory Access Control (MAC). Sandboxing is not a cooperative user-space feature; it is enforced directly by the kernel.

When an application is launched, the system applies a mandatory sandbox profile (a compiled configuration based on Apple’s Seatbelt policy language). Every time the application initiates a system call—such as reading a file, binding a network socket, or spawning a sub-process—the kernel intercepts the request and evaluates it against the app’s active sandbox policy. If the requested action falls outside the policy rules, the kernel denies the operation, typically returning a POSIX error code (such as EPERM or EACCES) or terminating the misbehaving process.

Cryptographic Entitlements and Hardware Access

iOS 12 uses code signing and entitlements to govern hardware and API permissions. Entitlements are key-value pairs embedded within the app’s digital signature during compilation and verified by Apple during App Store review and by iOS during installation.

If an application needs to access shared system resources—such as the camera, microphone, HealthKit, or Bluetooth—it must explicitly request the appropriate entitlement. Even with an entitlement present, the sandbox acts as an intermediary, requiring the user to grant explicit runtime permission before the operating system exposes the hardware API.

Restricted Inter-Process Communication (IPC)

Direct memory access, shared memory, and traditional POSIX IPC mechanisms between separate applications are blocked in iOS 12. Sandboxed apps cannot inspect the memory space of other running apps, nor can they trace or debug external processes.

Legitimate communication between sandboxed applications must take place through strict, operating-system-mediated channels:

  • Custom URL Schemes and Universal Links: Applications can launch other apps with designated payloads, with data passed via controlled URLs.
  • App Extensions: Extensions run in their own separate processes with restricted sandbox profiles, interacting with host apps exclusively through prescribed system APIs.
  • Shared App Groups: Apps from the same developer team can share a segregated data container, provided they share the same cryptographic Team ID and explicit App Group entitlements.

Integration with Data Protection

Sandboxing in iOS 12 works alongside the hardware-backed Data Protection architecture. Files created within an app’s sandbox can be encrypted using keys tied to the device's Secure Enclave and the user's passcode. By default, applications use class-based encryption settings (such as Complete Protection or Protected Unless Open), ensuring that even if an attacker were to bypass physical storage barriers, the sandboxed data remains encrypted while the device is locked.