沙箱
安全是chromium最重要的目标之一。安全的关键在于理解：我们仅仅能够在完全理解了其在所有状态下所有可能的输入的表现行为下，加固系统。对于一个和chromium一样庞大不同的代码库，讨论其所有部分的所有行为组合几乎是不可能的。沙箱就是用来提供一种硬授权，来确定代码片段什么能做什么不能做，而不管其输入是什么。
沙箱leverages操作系统提供的安全，来允许代码执行，且使其不能执行对计算机的持久改变或者访问机密信息。其架构和沙箱提供独立于系统的确切保证。这篇文档覆盖其在windows上的实现以及大致设计。Linux上的实现需访问https://code.google.com/p/chromium/wiki/LinuxSandboxing，而苹果上的实现则访问http://dev.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design
如果你不想阅读整个文档，你可以通过阅读“Sandbox FAQ”（http://www.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ）,沙箱的所做与所不做的保护，也许同样可以再FAQ中看到。
设计原则
1.不要在塑造车轮：诱导用一个更安全的模式扩展操作系统内核。不要这样做，让系统将其安全应用到其控制的对象上。在另一方面，创建应用程序级别的通用安全模型也是可以的。
2.最小授权原则：这个原则适用于沙箱模型和控制沙箱模型的代码。换句话说，沙箱模型应该在用户不能提升至超级用户的情况下依然正常工作
3.假设沙箱模型的代码是恶意代码： For threat-modeling purposes, we consider the sandbox compromised (that is, running malicious code) once the execution path reaches past a few early calls in the main() function.事实上，其几乎和第一个外部输入被接受时同时发生，或者刚好进入主循环时。
4.敏捷：非恶意代码不会试图访问其不能获取的资源。在这种情况下，沙箱应该尽量不要加强影响。在控制管理器中，一个敏感资源需要被修改时，为了这种个别情况，性能代价也是可以的。这通常是操作系统安全政正确适用的情况。
5.仿真是不安全的：仿真和虚拟机的解方案不是因爱其自身提供的安全。沙箱不应该依赖代码仿真，或者代码转换或者补丁，来提供安全。
沙箱模型在windows上的构架
windows上的沙箱模型是一个用户模式。没有特别的内核模型驱动，用户不需要管理员权限，沙箱模型就能正确运行。沙箱主要为32位进程设计，已经在 windows 2000/xp32/vista 32-64位上测试。
沙箱操作在进程级别的粒度上。任何需要沙箱化，都需要在一个独立的进程中运行。最小的沙箱配置需要两个进程:一个是权限控制器，即broker,其他进程则是目标进程。文档和代码两方面都是相当有意义的。沙箱以静态代码库方式提供，必须链接至broker和执行目标。
broker
在chromium中，broker一直就是brower进程。broker,在广义上，是一个权限控制器或者监督被沙箱住的进程行为。其主要职责：
1.为每个目标进程指定方针
2.孵化目标进程
3.主持沙箱策略引擎服务
4.主持沙箱截断管理器
5.主持沙箱IPC服务
6.代表目标进程，执行运行的策略行动
Broker应该比所有其产生的目标进程或得久。沙箱IPC是一个低级机制，用于透明forward某些从target上到broker上的windows api调用:这些调用针对策略，提升权限。被允许的策略被调用，然后被broker执行，然后通过同一IPC返回给目标进程。截断管理器用于补丁“通过ipc到broker的windows api调用”。
目标进程
在chromium中，渲染者一直是目标进程，出发在browser进程中指定了 --no-sanbox 命令行。使用--safe-plugins命令行，在沙箱中运行一个插件进程也是可能的。目标进程主持了所有运行在沙箱中的代码，加沙箱基础设施客户端：
1.所有被沙箱的代码
2.沙箱IPC通信客户端
3.沙箱策略客户端引擎
4.沙箱截断
其中2,3,4是沙箱库的部分，以连接的方式被沙箱化
截断（也就是钩子）描述了windows api调用是如何通过沙箱IPC到Broker的，它是broker 补发API调用，返回结果或者简单使调用失败。截断+IPC机制并不提供安全；它被设计用来兼容“当代码在沙箱不能被修改以应付沙箱的严格限制”这种情况。
期望在将来大部分插件豆浆运行在目标进程当中。
沙箱限制：
1.令牌限制
2.windows 任务对象
3.windows 桌面对象
4.windows vista 仅有：级别完整性
Job对象
1.禁止用户使用SystemParametersInfo()系统宽度改变
2.禁止用户创造或者切换桌面
3.禁止改变显示，比如分辨率等
4.不读或者写剪切板
5.禁止消息广播
6.禁止全局消息钩子
7.禁止访问全局原子表
8.禁止昂文用户处理器来创建外部任务对象
9.禁止创建子进程
10.过度使用CPU/内存/IO
安全是chromium最重要的目标之一。安全的关键在于理解：我们仅仅能够在完全理解了其在所有状态下所有可能的输入的表现行为下，加固系统。对于一个和chromium一样庞大不同的代码库，讨论其所有部分的所有行为组合几乎是不可能的。沙箱就是用来提供一种硬授权，来确定代码片段什么能做什么不能做，而不管其输入是什么。
沙箱leverages操作系统提供的安全，来允许代码执行，且使其不能执行对计算机的持久改变或者访问机密信息。其架构和沙箱提供独立于系统的确切保证。这篇文档覆盖其在windows上的实现以及大致设计。Linux上的实现需访问https://code.google.com/p/chromium/wiki/LinuxSandboxing，而苹果上的实现则访问http://dev.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design
如果你不想阅读整个文档，你可以通过阅读“Sandbox FAQ”（http://www.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ）,沙箱的所做与所不做的保护，也许同样可以再FAQ中看到。
设计原则
1.不要在塑造车轮：诱导用一个更安全的模式扩展操作系统内核。不要这样做，让系统将其安全应用到其控制的对象上。在另一方面，创建应用程序级别的通用安全模型也是可以的。
2.最小授权原则：这个原则适用于沙箱模型和控制沙箱模型的代码。换句话说，沙箱模型应该在用户不能提升至超级用户的情况下依然正常工作
3.假设沙箱模型的代码是恶意代码： For threat-modeling purposes, we consider the sandbox compromised (that is, running malicious code) once the execution path reaches past a few early calls in the main() function.事实上，其几乎和第一个外部输入被接受时同时发生，或者刚好进入主循环时。
4.敏捷：非恶意代码不会试图访问其不能获取的资源。在这种情况下，沙箱应该尽量不要加强影响。在控制管理器中，一个敏感资源需要被修改时，为了这种个别情况，性能代价也是可以的。这通常是操作系统安全政正确适用的情况。
5.仿真是不安全的：仿真和虚拟机的解方案不是因爱其自身提供的安全。沙箱不应该依赖代码仿真，或者代码转换或者补丁，来提供安全。
沙箱模型在windows上的构架
windows上的沙箱模型是一个用户模式。没有特别的内核模型驱动，用户不需要管理员权限，沙箱模型就能正确运行。沙箱主要为32位进程设计，已经在 windows 2000/xp32/vista 32-64位上测试。
沙箱操作在进程级别的粒度上。任何需要沙箱化，都需要在一个独立的进程中运行。最小的沙箱配置需要两个进程:一个是权限控制器，即broker,其他进程则是目标进程。文档和代码两方面都是相当有意义的。沙箱以静态代码库方式提供，必须链接至broker和执行目标。
broker
在chromium中，broker一直就是brower进程。broker,在广义上，是一个权限控制器或者监督被沙箱住的进程行为。其主要职责：
1.为每个目标进程指定方针
2.孵化目标进程
3.主持沙箱策略引擎服务
4.主持沙箱截断管理器
5.主持沙箱IPC服务
6.代表目标进程，执行运行的策略行动
Broker应该比所有其产生的目标进程或得久。沙箱IPC是一个低级机制，用于透明forward某些从target上到broker上的windows api调用:这些调用针对策略，提升权限。被允许的策略被调用，然后被broker执行，然后通过同一IPC返回给目标进程。截断管理器用于补丁“通过ipc到broker的windows api调用”。
目标进程
在chromium中，渲染者一直是目标进程，出发在browser进程中指定了 --no-sanbox 命令行。使用--safe-plugins命令行，在沙箱中运行一个插件进程也是可能的。目标进程主持了所有运行在沙箱中的代码，加沙箱基础设施客户端：
1.所有被沙箱的代码
2.沙箱IPC通信客户端
3.沙箱策略客户端引擎
4.沙箱截断
其中2,3,4是沙箱库的部分，以连接的方式被沙箱化
截断（也就是钩子）描述了windows api调用是如何通过沙箱IPC到Broker的，它是broker 补发API调用，返回结果或者简单使调用失败。截断+IPC机制并不提供安全；它被设计用来兼容“当代码在沙箱不能被修改以应付沙箱的严格限制”这种情况。
期望在将来大部分插件豆浆运行在目标进程当中。
沙箱限制：
1.令牌限制
2.windows 任务对象
3.windows 桌面对象
4.windows vista 仅有：级别完整性
Job对象
1.禁止用户使用SystemParametersInfo()系统宽度改变
2.禁止用户创造或者切换桌面
3.禁止改变显示，比如分辨率等
4.不读或者写剪切板
5.禁止消息广播
6.禁止全局消息钩子
7.禁止访问全局原子表
8.禁止昂文用户处理器来创建外部任务对象
9.禁止创建子进程
10.过度使用CPU/内存/IO
扫一扫
1140
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
