轉載請註明出處:https://ahangchen.gitbooks.io/chromium_doc_zh/content/zh//General_Architecture/OSX_Sandbox_design.htmlhtml
全書地址
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_zhgit
這個文檔描述了Mac OS X上的進程沙箱機制。github
沙箱將進程視爲一種惡劣的環境,由於進程任什麼時候候均可能被一個惡意攻擊者藉由緩衝區溢出或者其餘這樣的攻擊方式所影響。一旦進程被影響,咱們的目標就變成了,讓這個有問題的進程能訪問的用戶機器的資源越少越好,並儘可能避免在標準文件系統訪問控制之外,以及內核執行的用戶/組進程控制相關的行爲。chrome
查看概述文檔瞭解目標與總體架構圖表。安全
在Mac OS X上,從Leopard版本開始,每一個進程經過使用BSD沙箱設施(在一些Apple的文檔中也被成爲Seatbelt)擁有本身的權限限制。這由一系列獨立的API調用組成,sandbox_init(),設置進程彼時的訪問限制。這意味着即便新的權限拒絕訪問任何新建立的文件描述符,以前打開的文件描述符仍然生效。咱們能夠經過在進程啓動前正確地設置來利用這一點,在咱們將渲染器暴露給任何第三方輸入(html,等等)前,切斷全部訪問。服務器
Seatbelt不會限制內存分配,多線程,或者對先前打開的系統設施的訪問。所以,這應該不會影響其餘的需求或者嚴重影響咱們的IPC設計。多線程
OS X提供了對緩衝區溢出提供了額外的保護。在Leopard中,棧被標誌爲不可執行內存,所以更不易被做爲執行惡意代碼的攻擊方向。這不能避免堆的內存溢出,但對於64位應用,除非內存的一部分被顯式標識爲可執行,不然Leopard不容許任何執行代碼的企圖。隨着咱們未來轉入64位渲染器進程,這會變成另外一個吸引人的安全特性。架構
sandbox_init()支持預約義沙箱訪問限制和提供更精細控制的沙箱配置腳本。app
Chromium使用的自定義沙箱配置在源代碼樹的.sb文件中。ide
咱們定義了下面這些配置文件(路徑相對於源代碼根目錄):
一個讓咱們不愉快的點是,沙箱進程經過OS X系統API調用。並且沒有每一個API須要哪些權限的文檔,好比它們是否須要訪問磁盤文件,或者是否會調用沙箱限制訪問的其餘API?目前,咱們的方法是,在打開沙箱前,對任何可能有問題的API調用作「熱身」。例如,顏色配置和共享庫能夠在咱們鎖定進程前從磁盤加載。
SandboxInitWrapper::InitializeSandbox()是初始化沙箱的主要入口,它按如下步驟執行:
OS X沙箱實現支持下面這些標誌位:
Debugging Chrome on OS X裏有更多關於調試和Mac OS X 沙箱API診斷工具的文檔。
系統沙箱文件能夠在下面的路徑之一找到(取決於系統版本):