移动开发中的应用沙盒 —— 什么是它，机制及工作原理

什么是 App Sandbox？

应用沙盒（App Sandbox）—— 一种架构安全机制，将每个应用程序隔离在其自己的执行环境中，对系统资源的访问受限。这个术语来源于儿童的“沙盒”概念 —— 一个安全的空间，孩子可以在其中玩耍，而无法接触到危险物品。类似地，应用程序在受限环境中运行，无法访问其他应用程序的数据或关键系统组件。

Sandbox 的主要目标是实现最小权限原则：每个应用程序只获得执行声明功能所需的权限。即使攻击者在应用程序中发现漏洞，沙盒也不允许访问其他应用程序的数据、照片、联系人或系统文件。损害仅限于一个应用程序的范围内。

移动操作系统比桌面系统更早引入了沙盒。iOS 从第一个 SDK 版本（2008）开始使用 Sandbox，Android —— 从 1.0 版本（2008）开始，但在 Android 4.3（2013）中通过 SELinux 进行了加强。桌面系统正在追赶：macOS 在 2012 年引入了 Sandbox，Windows —— 在 Windows 8 中引入了隔离的 UWP 应用程序。

沙盒中的隔离如何工作？

沙盒中的隔离通过操作系统不同层次的多种机制组合来实现。在文件系统级别，每个应用程序被分配一个受保护的目录，只有它自己拥有完全访问权限。在进程级别，每个应用程序使用唯一的用户标识符（UID）。在内核级别，通过 SELinux 或类似机制实施强制访问控制（MAC）。

文件系统隔离

每个应用程序在设备的文件系统中获得自己的根目录。在 iOS 中，这是 /var/mobile/Containers/Data/Application/{UUID} 目录，在 Android 中 —— /data/data/{package_name}。应用程序只能在此目录内读写文件。访问此目录外的任何文件都会在操作系统内核级别被阻止。

系统还提供具有有限访问权限的特殊共享目录。在 iOS 中，它们是用于用户数据的 Documents 目录、用于设置的 Library 和用于临时文件的 Caches。在 Android 中 —— 内部存储（getFilesDir）和外部存储（getExternalFilesDir），访问它们不需要额外的权限。

进程和 UID 隔离

在 Android 中，每个应用程序作为一个独立的 Linux 进程运行，具有唯一的 UID（用户 ID）。UID 在应用程序安装时分配，并在整个生命周期中保持不变。具有不同 UID 的进程在内核级别相互隔离 —— 它们无法访问彼此的内存或文件。类似机制在 iOS 中通过 XNU 内核及其保护系统运行。

Android 中额外的保护层由 SELinux（Security-Enhanced Linux）提供，自 Android 4.3 起以 enforcing 模式运行。SELinux 实现强制访问控制（MAC）：进程的每个操作都会检查是否符合安全策略，而不依赖于文件所有者的权限。即使应用程序以 root UID 运行，SELinux 也可以阻止对特定资源的访问。

iOS 中的沙盒

iOS 沙盒被认为是移动操作系统中最为严格的之一。每个应用程序在容器级别被隔离 —— 文件系统的一个受保护区域，其他应用程序无法访问。iOS 使用通过 Sandbox Kernel Extension（Sandbox.kext）进行的强制访问控制和 entitlement 机制的组合来授予扩展权限。

iOS 容器结构

iOS 应用程序的容器由几个具有不同访问级别的目录组成。Documents —— 用于用户数据，这些数据在通过 iCloud 和 iTunes 备份时保留。Library —— 用于配置文件和缓存。tmp —— 用于系统随时可以删除的临时数据。AppName.app —— 应用程序包本身，是只读的。

访问其他应用程序的数据被严格禁止。iOS 不提供从其他应用程序容器读取文件的 API。数据交换的唯一方式是通过系统机制：用于共享的 UIActivityViewController、用于剪贴板的 UIPasteboard、用于同一开发者应用程序的 App Groups。这些机制中的每一个都在操作系统的控制下运行。

iOS 中的 Entitlements 和 App Sandbox

标准沙盒之外的扩展功能通过 Entitlements 提供 —— 添加到应用程序代码签名中的数字签名。例如，com.apple.security.application-groups entitlement 允许同一组的应用程序拥有共享容器。推送通知、iCloud、Apple Pay —— 所有这些功能都需要相应的 entitlements。

需要注意的是，iOS 中的 entitlements 与权限（permissions）不同。权限在运行时向用户请求（例如，访问相机），而 entitlements 在安装阶段由系统检查，用户无法更改。Entitlement 由开发人员确定，并在应用程序审查过程中由 Apple 签署。

Android 中的沙盒

Android 使用基于 Linux 内核的多层沙盒模型。每个应用程序作为一个独立的 Linux 用户运行，具有唯一的 UID，这在进程和文件级别提供了基本的隔离。额外的层次 —— 用于强制访问控制的 SELinux 和用于控制系统 API 访问的 Permissions。

SELinux 和 UID 隔离

Android 中的 SELinux 以 enforcing 模式运行，这意味着安全策略的强制实施。每个应用程序被分配一个安全上下文（security context），所有系统调用都会检查是否符合策略。Android 中的 SELinux 包含超过 1500 条规则，涵盖文件系统、进程间通信、套接字和系统调用。

UID 隔离防止应用程序直接访问其他应用程序的文件。例如，具有 UID 10001 的应用程序 A 无法读取具有 UID 10002 的应用程序 B 的文件，即使两者都以同一电话用户的名义运行。这是适用于移动设备的 Linux 多用户安全的基本原则。

// 在 Android 中访问应用程序自己的目录
File appDir = context.getFilesDir();
File cacheDir = context.getCacheDir();
File externalDir = context.getExternalFilesDir(null);

// 尝试访问他人目录将导致 SecurityException
// File otherApp = new File("/data/data/com.other.app/shared_prefs/");

// 使用 FileProvider 进行安全的文件共享
Uri contentUri = FileProvider.getUriForFile(
    context, "com.example.fileprovider", file
);

Android 提供了应用程序之间安全数据交换的额外机制。ContentProvider —— 一个 Android 组件，允许应用程序通过严格定义的 URI 向其他应用程序提供对其数据的访问。FileProvider —— 一种安全共享文件的方式，而无需暴露文件系统路径。

沙盒的限制和安全性

尽管 App Sandbox 是一种强大的保护机制，但它有根本性的限制。沙盒可以防止横向访问（应用程序到应用程序），但无法防止纵向访问（内核级别的恶意软件或对设备的物理访问）。在越狱或 root 访问时，沙盒可能被绕过，因为攻击者获得了超级用户权限。

第二个限制 —— 恶意权限。如果用户授予应用程序访问联系人和麦克风的权限，沙盒无法阻止这些数据的收集，因为应用程序使用了合法的系统 API。在这种情况下，保护转移到用户意识层面以及 App Store 和 Google Play 的审查层面。

第三个限制 —— 沙盒之间的交互。某些系统服务（NotificationListenerService、AccessibilityService）对其他应用程序的数据具有扩展访问权限。如果攻击者获得相应权限，可以利用这些服务绕过沙盒。Google 和 Apple 不断更新此类服务的策略。

尽管存在限制，沙盒是移动操作系统的关键安全组件。根据 Android Security Report（2024），沙盒隔离阻止了超过 99% 的应用程序间数据访问尝试。结合代码签名、App Review 和运行时权限，Sandbox 构成了现代移动设备的多层保护。