沙箱将程序視為一種惡劣的環境，因為程序任何時候都可能被一個惡意攻擊者借由緩沖區溢出或者其他這樣的攻擊方式所影響。一旦程序被影響，我們的目标就變成了，讓這個有問題的程序能通路的使用者機器的資源越少越好，并盡量避免在标準檔案系統通路控制以外，以及核心執行的使用者/組程序控制相關的行為。
檢視概述文檔了解目标與整體架構圖表。
在Mac OS X上，從Leopard版本開始，每個程序通過使用BSD沙箱設施（在一些Apple的文檔中也被成為Seatbelt）擁有自己的權限限制。這由一系列獨立的API調用組成，sandbox_init()，設定程序彼時的通路限制。這意味着即使新的權限拒絕通路任何新建立的檔案描述符，之前打開的檔案描述符仍然生效。我們可以通過在程序啟動前正确地設定來利用這一點，在我們将渲染器暴露給任何第三方輸入（html，等等）前，切斷所有通路。
Seatbelt不會限制記憶體配置設定，多線程，或者對先前打開的系統設施的通路。是以，這應該不會影響其他的需求或者嚴重影響我們的IPC設計。
OS X提供了對緩沖區溢出提供了額外的保護。在Leopard中，棧被标志為不可執行記憶體，是以更不易被作為執行惡意代碼的攻擊方向。這不能避免堆的記憶體溢出，但對于64位應用，除非記憶體的一部分被顯式辨別為可執行，否則Leopard不允許任何執行代碼的企圖。随着我們将來轉入64位渲染器程序，這會變成另一個吸引人的安全特性。
sandbox_init()支援預定義沙箱通路限制和提供更精細控制的沙箱配置腳本。
Chromium使用的自定義沙箱配置在源代碼樹的.sb檔案中。
我們定義了下面這些配置檔案（路徑相對于源代碼根目錄）：
content/common/common.sb - 用于所有沙箱的常用安裝
content/renderer/renderer.sb - 用于擴充和渲染器程序。允許通路字型伺服器。
chrome/browser/utility.sb - 用于工具程序。允許通路單一可配置目錄。
content/browser/worker.sb - 用于工作程序。限制度最高 - 除了加載系統庫之外，沒有檔案系統通路權限。
chrome/browser/nacl_loader.sb - 使用者允許不受信任的原生用戶端代碼（例如，“user”）。
一個讓我們不愉快的點是，沙箱程序通過OS X系統API調用。而且沒有每個API需要哪些權限的文檔，比如它們是否需要通路磁盤檔案，或者是否會調用沙箱限制通路的其他API？目前，我們的方法是，在打開沙箱前，對任何可能有問題的API調用做“熱身”。例如，顔色配置和共享庫可以在我們鎖定程序前從磁盤加載。
SandboxInitWrapper::InitializeSandbox()是初始化沙箱的主要入口，它按以下步驟執行：
判斷目前程序的類型是否需要沙箱化，如果需要，判斷需要使用哪種沙箱配置。
通過調用sandbox::SandboxWarmup() “熱身”相關"系統API。
通過調用sandbox::EnableSandbox()啟動沙箱。
OS X沙箱實作支援下面這些标志位：
--no-sandbox - 關閉整個沙箱
--enable-sandbox-logging - 關于哪個系統調用正在阻塞的詳細資訊被記錄到syslog
Debugging Chrome on OS X裡有更多關于調試和Mac OS X 沙箱API診斷工具的文檔。
http://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf
http://www.318.com/techjournal/?p=107
沙箱手冊頁 (man 7 sandbox)
系統沙箱檔案可以在下面的路徑之一找到(取決于系統版本)：
/Library/Sandbox/Profiles
/System/Library/Sandbox/Profiles
/usr/share/sandbox