根據(jù)《The Security Architecture of the Chromium Browser》論文完成
browser kernel和rendering engine
Chromium有兩個模塊仓手，兩個模塊在不同的保護域中：browser kernel和rendering engine，其中browser kernel用于與操作系統(tǒng)交互褥符，rendering engine在sandbox中運行（擁有受限制的特權）
browser kernel代表用戶運行瘦馍，rendering engine模塊代表web運行晕城。
Chromium的架構將瀏覽器不同組件在browser kernel和rendering engine之間進行分配蝌蹂，將高風險部分（如HTML parser、JS 虛擬機儒飒、DOM）放到rendering engine的沙盒中产雹。Browser kernel用于管理永久資源（如cookie诫惭、password database、和操作系統(tǒng)交互以接收用戶輸入蔓挖、輸出信息到屏幕夕土、訪問網(wǎng)絡），并提供API供rendering engine調(diào)用，維護期分配給各個rendering engine的權限信息（如各個rendering engine允許上傳的文件列表）怨绣。
Chromium的架構依賴rendering engine單獨實現(xiàn)browser的安全策略--same-origin policy角溃。browser kernel僅僅進行粗粒度的控制。
本方案無法阻止攻擊者在攻占了rendering engine的情形下攻擊其他web站點（如獲取他們的cookie）篮撑；但是阻止了攻擊者讀减细、寫用戶文件系統(tǒng)。
Browser Kernel暴露了API赢笨，使得rendering engine能夠用來發(fā)起網(wǎng)絡請求未蝌、訪問持久存儲、在用戶屏幕上顯示圖形茧妒。
Rendering web content按下列順序處理：parsing萧吠、建立DOM的in-memory representation， lay out the document graphically桐筏，根據(jù)script指令做出響應以修改document纸型。
Browser Kernel和Rendering engine之間的分工如下，其中很多parsing和decoding工作由rendering engine完成九昧，是因為這些任務從歷史角度看來，是source of a large number of browser vulnerabilities毕匀。一個例外是network stack是由Browser Kernel實現(xiàn)的铸鹰，browser kernel負責解析HTTP response header，調(diào)用gzip或bzip2解碼器來解壓縮HTTP responses（如果其是使用Content-Encoding的）皂岔，這些任務可以分配給render engine蹋笼，但是會是的network stack更為負責并且降低性能。
Chromium也使用rendering engine來顯示一些可信內(nèi)容（如HTTPS證書錯誤的警告躁垛、釣魚網(wǎng)站的警告）剖毯，但是這個是由一個獨立的rendering engine完成的，與處理web 內(nèi)容的rendering engine不同教馆。但是存在一個例外逊谋，Web Inspector，其展示可信內(nèi)容土铺，是由render engine展示的（該render engine也顯示其他web 內(nèi)容）胶滋，這是因為Web inspector的職責所限，其與其所inspecting的頁面交互悲敷。
plug-ins：Chromium中究恤，每個plug-in運行在一個單獨的host process。為了與現(xiàn)有網(wǎng)站兼容后德，browser plug-in無法部署在rendering engine中部宿，因為plug-in廠商期望的是在整個browser中至多有一個plug-in實例。默認情況下瓢湃，每個plug-in運行在sandbox之外理张，以用戶的所有權限運行赫蛇。從而攻擊者可以利用plug-in的漏洞，在用戶機器上安裝惡意軟件涯穷。廠商在之后可以編寫plug-in棍掐，使其運行在sandbox中，用戶也可以為browser加上選項--safe-plugins拷况，使plugin運行（但是只是實現(xiàn)階段作煌，可能會不穩(wěn)定及不可預期的行為，如無法更新）
SandBox
Sandbox限制了rendering engine進程調(diào)用一些系統(tǒng)調(diào)用赚瘦。
目標：理想情況下粟誓，sandbox將強制rendering engine使用browser kernel API來與外部進行交互。很多DOM方法起意，如appendChild可以在rendering engine內(nèi)完成鹰服；其他一些DOM方法，如XMLHttpRequest的send方法揽咕，要求rendering engine不僅操縱器內(nèi)部狀態(tài)悲酷，honest rendering engine可以使用browser kernel提供的接口來實現(xiàn)該功能。sandbox的最終目標是惡意的rendering engine仍然只能通過browser kernel的接口和文件系統(tǒng)交互亲善。
實現(xiàn)：當前设易，Chromium依賴Windows-specific特性來sandbox rendering engine。rendering engine并沒有使用Windows security token蛹头，而是使用一個受限的security token顿肺，當rendering engine嘗試訪問一個secureable object時，Windows Security Manager檢查rendering engine的securitytoken是否有足夠的權限來訪問該object渣蜗，Sandbox限制rendering engine的security token屠尊，是的token check在大多數(shù)情況下fail。
不足： sandbox存在下列不足之處：1. FAT32文件系統(tǒng)不支持訪問控制列表耕拷，沒有訪問控制列表讼昆，Windows security manager將忽略進程的security token，從而rendering engine可以讀寫FAT32文件（不受權限控制）骚烧。 2. 錯誤配置的object控淡，如果一個object的discretionary access control list（DACL）為NULL，Windows security manager也將忽略token止潘，直接訪問掺炭；NULL DACL很少出現(xiàn)，而且在NTFS文件系統(tǒng)中凭戴，NULL DACL被極大緩解涧狮，因為Sandbox強制Windows檢查rendering engine是否有訪問目標文件父目錄的權限。
Browser kernel接口
1. ?用戶交互方面，操作系統(tǒng)提供接口者冤，使得應用能夠和用戶交互肤视，但是這些用戶一般不暴露給不可靠的應用（例如，下X windows系統(tǒng)中涉枫，在X server上創(chuàng)建window的能力邢滑，意味著能夠獲取用戶鍵盤輸入）
渲染：rendering engine是內(nèi)存中完成渲染，然后將bitmap交給browser kernel愿汰，由其完成真正的渲染困后；
用戶輸入：操作系統(tǒng)將用戶輸入事件傳遞至browser kernel；browser kernel根據(jù)當前focused的元素衬廷，確定該事件派發(fā)給誰摇予。
2. 永久存儲
上傳文件：僅上傳用戶選擇的文件，吗跋。
下載文件：僅能下載到用戶選擇的區(qū)域侧戴，特定的文件類型不被允許，如.local,.ini等
3.網(wǎng)絡
能夠訪問http跌宛，https酗宋，ftp的，但是一般的rendering engine不能請求file開頭的URL疆拘，用戶可在地址欄中輸入file開頭的url進行訪問蜕猫，該訪問是在專用的rendering engine中完成的。
