关于App Sandbox

Posted 2023-04-27

参考技术A App Sandbox（以下或简称应用程序沙盒，应用程序沙箱，沙盒或者沙箱）是 OS X 系统提供的一种访问控制技术，它在内核级别被强制要求。一旦某个应用遭到破坏，沙盒能够保护系统和用户数据免受波及。通过 Mac App Store 分发的应用程序必须采用沙盒。还有一些应用程序不通过 Mac App Store 分发，而是使用开发者账号做签名的（大多数情况下）也要使用沙盒。

系统越复杂便越是容易遭受攻击，软件不断迭代并随着时间的推移变得越来越复杂。你采取安全编码实践来防止 bug 的出现，但攻击者只需要穿透你的防御即可成功入侵。尽管沙盒不能阻止应用程序遭受攻击，但它能把入侵造成的损害控制在最小程度。

非沙盒的应用程序具有运行应用程序用户的完整权限，并且能访问用户可以访问的任何资源。如果应用程序或者该应用链接的任何框架存在安全漏洞，那么攻击者会试图利用这些漏洞来获取应用程序的控制权，一旦得逞，攻击者就可以为所欲为。

为了解决这些问题，应用程序沙盒采取了两个策略：

然而，沙盒不是银弹。应用程序仍然会受到影响，并且可能遭受攻击。但是潜在的破坏影响范围会受到严格的限制，因为应用程序只能拿到保证其正常运行所能获取的最小权限。

如果攻击者在你的应用程序中成功的发现一个安全漏洞，那么应用程序沙箱通过限制每个应用对敏感数据的访问，铸起最后一道防御措施来应对盗取，篡改或删除用户数据，以及劫持系统硬件等行为。例如，一个沙盒应用要使用以下资源就必须明确声明：

在系统运行时，对在项目定义中未明确请求任何资源的访问都是拒绝的。比如，如果你正在使用 sketch（编辑图片之类），你知道应用程序不需要访问到麦克风，你当然也不会去请求，同时系统会拒绝任何尝试通过应用程序（可能已被入侵）启用麦克风的行为。

另一方面，沙盒应用可以访问你请求的特定资源，允许用户以常用方式（比如拖放操作）执行典型操作来扩展沙盒，并且可以自动执行很多安全相关的额外操作，包括：

END

About App Sandbox

沙盒是在受限的安全环境中运行应用程序的一种做法，这种做法是要限制授予应用程序的代码访问权限。

沙盒技术提供对资源的严格控制，沙盒通过限制对内存、系统文件和设置的访问，沙盒可以让企业可通过执行潜在恶意代码而发现其活动和意图，而不会影响主机设备。沙盒技术对进入企业网络的代码进行的这种分析意味着，即使是零日漏洞利用都可以被发现——通过分析代码的恶意意图。

About App Sandbox

App Sandbox is an access control technology provided in macOS, enforced at the kernel level. It is designed to contain damage to the system and the user’s data if an app becomes compromised. Apps distributed through the Mac App Store must adopt App Sandbox. Apps signed and distributed outside of the Mac App Store with Developer ID can (and in most cases should) use App Sandbox as well.

At a Glance

Complex systems will always have vulnerabilities, and software complexity only increases over time. No matter how carefully you adopt secure coding practices and guard against bugs, attackers only need to get through your defenses once to succeed. While App Sandbox doesn’t prevent attacks against your app, it does minimize the harm a successful one can cause.

A non-sandboxed app has the full rights of the user who is running that app, and can access any resources that the user can access. If that app or any framework it is linked against contain security holes, an attacker can potentially exploit those holes to take control of that app, and in doing so, the attacker gains the ability to do anything that the user can do.

Designed to mitigate this problem, the App Sandbox strategy is twofold:

1. App Sandbox enables you to describe how your app interacts with the system. The system then grants your app the access it needs to get its job done, and no more.

2. App Sandbox allows the user to transparently grant your app additional access by way of Open and Save dialogs, drag and drop, and other familiar user interactions.

App Sandbox is not a silver bullet. Apps can still be compromised, and a compromised app can still do damage. But the scope of potential damage is severely limited when an app is restricted to the minimum set of privileges it needs to get its job done.

App Sandbox is Based on a Few Straightforward Principles

By limiting access to sensitive resources on a per-app basis, App Sandbox provides a last line of defense against the theft, corruption, or deletion of user data, or the hijacking of system hardware, if an attacker successfully exploits security holes in your app. For example, a sandboxed app must explicitly state its intent to use any of the following resources using entitlements:

• Hardware (Camera, Microphone, USB, Printer)

• Network Connections (Inbound or Outbound)

• App Data (Calendar, Location, Contacts)

• User Files (Downloads, Pictures, Music, Movies, User Selected Files)

Access to any resource not explicitly requested in the project definition is rejected by the system at run time. If you are writing a sketch app, for example, and you know your app will never need access to the microphone, you simply don’t ask for access, and the system knows to reject any attempt your (perhaps compromised) app makes to use it.