这个文档描述了Mac OS X上的进程沙箱机制。
沙箱将进程视为一种恶劣的环境，因为进程任何时候都可能被一个恶意攻击者借由缓冲区溢出或者其他这样的攻击方式所影响。一旦进程被影响，我们的目标就变成了，让这个有问题的进程能访问的用户机器的资源越少越好，并尽量避免在标准文件系统访问控制以外，以及内核执行的用户/组进程控制相关的行为。
查看概述文档了解目标与整体架构图表。
在Mac OS X上，从Leopard版本开始，每个进程通过使用BSD沙箱设施（在一些Apple的文档中也被成为Seatbelt）拥有自己的权限限制。这由一系列独立的API调用组成，sandbox_init()，设置进程彼时的访问限制。这意味着即使新的权限拒绝访问任何新创建的文件描述符，之前打开的文件描述符仍然生效。我们可以通过在进程启动前正确地设置来利用这一点，在我们将渲染器暴露给任何第三方输入（html，等等）前，切断所有访问。
Seatbelt不会限制内存分配，多线程，或者对先前打开的系统设施的访问。因此，这应该不会影响其他的需求或者严重影响我们的IPC设计。
OS X提供了对缓冲区溢出提供了额外的保护。在Leopard中，栈被标志为不可执行内存，因此更不易被作为执行恶意代码的攻击方向。这不能避免堆的内存溢出，但对于64位应用，除非内存的一部分被显式标识为可执行，否则Leopard不允许任何执行代码的企图。随着我们将来转入64位渲染器进程，这会变成另一个吸引人的安全特性。
sandbox_init()支持预定义沙箱访问限制和提供更精细控制的沙箱配置脚本。
Chromium使用的自定义沙箱配置在源代码树的.sb文件中。
我们定义了下面这些配置文件（路径相对于源代码根目录）：
一个让我们不愉快的点是，沙箱进程通过OS X系统API调用。而且没有每个API需要哪些权限的文档，比如它们是否需要访问磁盘文件，或者是否会调用沙箱限制访问的其他API？目前，我们的方法是，在打开沙箱前，对任何可能有问题的API调用做“热身”。例如，颜色配置和共享库可以在我们锁定进程前从磁盘加载。
SandboxInitWrapper::InitializeSandbox()是初始化沙箱的主要入口，它按以下步骤执行：
OS X沙箱实现支持下面这些标志位：
Debugging Chrome on OS X里有更多关于调试和Mac OS X 沙箱API诊断工具的文档。
系统沙箱文件可以在下面的路径之一找到(取决于系统版本)：