全書地址
Chromium中文文檔 for https://www.chromium.org/developers/design-documents
持續更新ing，歡迎star
gitbook地址：https://ahangchen.gitbooks.io/chromium_doc_zh/content/zh//
github地址： https://github.com/ahangchen/Chromium_doc_zh
這個文檔描述了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文件中。
我們定義了下面這些配置文件（路徑相對于源代碼根目錄）：
- 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
沙箱手冊頁 (man 7 sandbox)
-
系統沙箱文件可以在下面的路徑之一找到(取決于系統版本)：
- /Library/Sandbox/Profiles
- /System/Library/Sandbox/Profiles
- /usr/share/sandbox
