Chrome 的安全机制

今天看到多篇新闻报道：在 Pwn2Own 2010 黑客大赛上，针对各种浏览器的攻击中，只有 Google Chrome 屹立不倒。随便 Google 一下，会发现很多黑客把 Chrome 的安全性归结于 Chrome 的 sandbox（沙箱）机制。我因此好奇的看了看 Chromium（Google Chrome 的 open source project）的文档,

• http://www.chromium.org/developers/design-documents/sandbox
• http://dev.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ

大概了解了一下 Chrome sandbox 的基本原理。

Chrome 会启动两类进程：target 和 broker：

1. Target 进程执行那些容易被黑客影响并做坏事的工作；主要包括（1）Javascript 程序的解释，和（2）HTML rendering。Target 进程是由 broker 进程创建的。创建之初，broker 就把 target 进程的各种访问权限都剥夺了。也就是说虽然 target 进程可以像所有用户态进程那样通过操作系统调用，请操作系统内核做事，但是操作系统内核会认为 target 进程没有权限，因而拒绝之。【注：在现代操作系统中，用户进程对任何系统资源的访问都得通过“请操作系统内核帮忙”来完成。】所以 target 实际上只能通过进程间调用，请 broker 进程来帮忙做事。
   
   
2. Broker 进程扮演着操作系统内核的角色 —— 因为 broker 进程执行的代码是浏览器的作者写的，并且不易被坏人注入坏代码，所以我们可以依赖它检查 target 进程请它做的事情是不是靠谱。如果不靠谱，则拒绝之。

简单的说，Chrome 的 sandbox 机制复制了操作系统的两层安全概念 —— 用户进程（target 进程）没实权，实权由操作系统内核（broker 进程）把持。实际上是装了第二把锁 —— 当用户和第三方软件对操作系统的错误配置导致操作系统安全机制失效的时候，第二把锁的作用就显示出来了。