OS X 沙箱設計
全書地址
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
- http://www.318.com/techjournal/?p=107
- 沙箱手冊頁 (man 7 sandbox)
系統沙箱文件可以在下面的路徑之一找到(取決於系統版本)：
- /Library/Sandbox/Profiles
- /System/Library/Sandbox/Profiles
- /usr/share/sandbox