09 — 沙箱与安全模型 ​

Chrome 安全模型的基本假设是：Renderer 可能会被恶意网页攻破，所以必须限制它能做什么。

沙箱解决什么 ​

Renderer 进程需要解析 HTML、CSS、图片、字体、执行 JS，攻击面很大。沙箱的目标是：即使 Renderer 被攻破，也不能随意读文件、访问系统资源或直接控制 OS 能力。

Broker / Target ​

沙箱常见模型是：

• Browser 进程 = broker：权限更高，负责策略判断和代执行敏感操作。
• Renderer 进程 = target：权限低，只能在沙箱允许的范围内运行。

当 Renderer 需要敏感能力时，通常要经过 broker 判断，而不是直接访问系统资源。

设计原则 ​

• 最小权限。
• 假设沙箱内代码可能是恶意的。
• 依赖操作系统安全机制，而不是自己发明一套安全边界。
• 正常路径尽量低开销。

和 Site Isolation 的区别 ​

• 沙箱限制“被攻破后能做什么”。
• Site Isolation 限制“同一进程里有哪些站点数据”。

二者叠加，构成 Chrome 的纵深防御。

总结 ​

Chrome 把 Renderer 放进低权限沙箱，由 Browser 进程作为 broker 控制敏感能力。沙箱不保证没有漏洞，但能显著降低 Renderer 漏洞的破坏范围。