根据《The Security Architecture of the Chromium Browser》论文完成
browser kernel和rendering engine
Chromium有两个模块，两个模块在不同的保护域中：browser kernel和rendering engine，其中browser kernel用于与操作系统交互，rendering engine在sandbox中运行（拥有受限制的特权）
browser kernel代表用户运行，rendering engine模块代表web运行。
Chromium的架构将浏览器不同组件在browser kernel和rendering engine之间进行分配，将高风险部分（如HTML parser、JS 虚拟机、DOM）放到rendering engine的沙盒中。Browser kernel用于管理永久资源（如cookie、password database、和操作系统交互以接收用户输入、输出信息到屏幕、访问网络），并提供API供rendering engine调用，维护期分配给各个rendering engine的权限信息（如各个rendering engine允许上传的文件列表）。
Chromium的架构依赖rendering engine单独实现browser的安全策略--same-origin policy。browser kernel仅仅进行粗粒度的控制。
本方案无法阻止攻击者在攻占了rendering engine的情形下攻击其他web站点（如获取他们的cookie）；但是阻止了攻击者读、写用户文件系统。
Browser Kernel暴露了API，使得rendering engine能够用来发起网络请求、访问持久存储、在用户屏幕上显示图形。
Rendering web content按下列顺序处理：parsing、建立DOM的in-memory representation， lay out the document graphically，根据script指令做出响应以修改document。
Browser Kernel和Rendering engine之间的分工如下，其中很多parsing和decoding工作由rendering engine完成，是因为这些任务从历史角度看来，是source of a large number of browser vulnerabilities。一个例外是network stack是由Browser Kernel实现的，browser kernel负责解析HTTP response header，调用gzip或bzip2解码器来解压缩HTTP responses（如果其是使用Content-Encoding的），这些任务可以分配给render engine，但是会是的network stack更为负责并且降低性能。
Chromium也使用rendering engine来显示一些可信内容（如HTTPS证书错误的警告、钓鱼网站的警告），但是这个是由一个独立的rendering engine完成的，与处理web 内容的rendering engine不同。但是存在一个例外，Web Inspector，其展示可信内容，是由render engine展示的（该render engine也显示其他web 内容），这是因为Web inspector的职责所限，其与其所inspecting的页面交互。
plug-ins：Chromium中，每个plug-in运行在一个单独的host process。为了与现有网站兼容，browser plug-in无法部署在rendering engine中，因为plug-in厂商期望的是在整个browser中至多有一个plug-in实例。默认情况下，每个plug-in运行在sandbox之外，以用户的所有权限运行。从而攻击者可以利用plug-in的漏洞，在用户机器上安装恶意软件。厂商在之后可以编写plug-in，使其运行在sandbox中，用户也可以为browser加上选项--safe-plugins，使plugin运行（但是只是实现阶段，可能会不稳定及不可预期的行为，如无法更新）
SandBox
Sandbox限制了rendering engine进程调用一些系统调用。
目标：理想情况下，sandbox将强制rendering engine使用browser kernel API来与外部进行交互。很多DOM方法，如appendChild可以在rendering engine内完成；其他一些DOM方法，如XMLHttpRequest的send方法，要求rendering engine不仅操纵器内部状态，honest rendering engine可以使用browser kernel提供的接口来实现该功能。sandbox的最终目标是恶意的rendering engine仍然只能通过browser kernel的接口和文件系统交互。
实现：当前，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在大多数情况下fail。
不足： sandbox存在下列不足之处：1. FAT32文件系统不支持访问控制列表，没有访问控制列表，Windows security manager将忽略进程的security token，从而rendering engine可以读写FAT32文件（不受权限控制）。 2. 错误配置的object，如果一个object的discretionary access control list（DACL）为NULL，Windows security manager也将忽略token，直接访问；NULL DACL很少出现，而且在NTFS文件系统中，NULL DACL被极大缓解，因为Sandbox强制Windows检查rendering engine是否有访问目标文件父目录的权限。
Browser kernel接口
1. 用户交互方面，操作系统提供接口，使得应用能够和用户交互，但是这些用户一般不暴露给不可靠的应用（例如，下X windows系统中，在X server上创建window的能力，意味着能够获取用户键盘输入）
渲染：rendering engine是内存中完成渲染，然后将bitmap交给browser kernel，由其完成真正的渲染；
用户输入：操作系统将用户输入事件传递至browser kernel；browser kernel根据当前focused的元素，确定该事件派发给谁。
2. 永久存储
上传文件：仅上传用户选择的文件，。
下载文件：仅能下载到用户选择的区域，特定的文件类型不被允许，如.local,.ini等
3.网络
能够访问http，https，ftp的，但是一般的rendering engine不能请求file开头的URL，用户可在地址栏中输入file开头的url进行访问，该访问是在专用的rendering engine中完成的。