Native Client: A Sandbox for Portable, Untrusted x86 Native Code
原文：https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf
注意！本文有删节！
摘要
本文描述了设计、实现 Native Client(后文用 NC 替代)，一个不受信任的x86本机的沙箱。 NC旨在为基于浏览器的应用程序提供本机应用程序的计算性能，而不会影响安全性。 NC使用软件故障隔离和安全运行时。 NC为二进制代码提供操作系统可移植性，同时支持Web应用程序编程环境中通常不能满足的面向性能的功能，例如线程支持，SSE等指令集扩展，以及编译器内在函数和手动编码汇编程序的使用。我们将这些属性组合在一个集合第三方工具的开放式架构中。
1 简介
此处有删节 现代Web浏览器提供扩展机制，如ActiveX和 NPAPI，以允二进制代码作为Web应用程序的一部分加载和运行。这样的体系结构允许插件绕过以其他方式应用于Web内容的安全机制、更好的利用机器的性能。
但是这些技术并没有从技术上提出一套安全机制，而是依靠非技术的手段（例如，通过弹出对话框手动建立信任关系，或手动安装控制台应用程序。）这些非技术在阻止恶意二进制代码的执行显得无力，导致不便和经济损失。
这篇论文的工作的主要贡献是：
- 操作系统和浏览器可移植的沙盒x86二进制模块的基础结构
- 支持高级性能功能，如线程，SSE指令，编译器内在函数和手工编码汇编程序
- 一个开放式系统，旨在轻松重新定位新的编译器和语言
- 改进CISC软件故障隔离，使用x86段以提高简单性并减少开销
1.1 威胁模型
NC应该能够处理来自任何网站的不受信任的模块，其安全性与JavaScript等可接受的系统相当。
当呈现给系统时，不可信模块可以包含任意代码和数据。这样做的结果是NaCl运行时必须能够确认模块符合我们的有效性规则（详见下文）。系统拒绝不符合这些规则的模块。此处有删节
我们在下面讨论我们的架构和代码有效性规则约束我们沙箱中的NaCl模块。
2 系统架构
NaCl应用程序由一组可信和不可信组件组成。
Figure 1 显示了用于管理和分割照片的基于NaCl的假设应用程序的结构。它由两个组件组成：
- 用户界面，用JavaScript实现并在Web浏览器中执行;
- 以及图像处理库（imglib.nexe），实现为NaCl模块。
在这个假设的场景中，用户界面和图像处理库是应用程序的一部分，因此不受信任。浏览器组件受浏览器执行环境约束，图像库受NaCl容器约束。这两个组件都可以跨操作系统和浏览器移植，并且NC支持本机代码可移植性。在运行照片应用程序之前，用户已将NC安装为浏览器插件。请注意，NaCl浏览器插件本身是操作系统和浏览器特定的。还要注意它是可信的，即它具有对OS系统调用接口的完全访问权限，并且用户相信它不会被滥用。
当用户导航到承载照片应用程序的网站时，浏览器会加载并执行应用程序JavaScript组件。 JavaScript依次调用NaCl浏览器插件将图像处理库加载到NaCl容器中。观察到本机代码模块是静默加载的 - 没有弹出窗口要求权限。 NC负责约束不可信模块的行为。每个组件都在自己的私有地址空间中运行。组件间通信基于NC的可靠数据报服务IMC（什么是IMC？模块间通信？-> Native Client’s IMC sockets interface）。
（PS：图片来自 BH_US_12_Rohlf_Google_Native_Client_Slides）
对于浏览器和NaCl模块之间的通信，NC提供两个选项：简单RPC工具（SRPC）和 Netscape插件应用程序编程接口（NPAPI），两者都在IMC之上实现。 IMC还提供共享内存段和共享同步对象，旨在避免高容量或高频率通信的消息传递开销。
NaCl模块还可以访问“服务运行时”接口，提供内存管理操作，线程创建和其他系统服务。该接口类似于传统操作系统的系统调用接口。
在本文中，我们使用“NaCl模块”来指代不受信任的本机代码。但请注意，应用程序可以使用多个NaCl模块，并且可信和不受信任的组件都可以使用IMC。例如，照片应用程序的用户可以选择使用（假设的）可信NaCl服务进行图像的本地存储，如 Figure 2 所示。因为它可以访问本地磁盘，所以存储服务必须作为本机安装浏览器插件;它不能作为NaCl模块实现。假设照片应用程序设计为可选地使用稳定的存储服务;用户界面将在初始化期间检查稳定的存储插件。如果它检测到存储服务插件，则用户界面将为其建立IMC通信通道，并将该通道的描述符传递给图像库，使图像库和存储服务能够通过基于IMC的服务直接通信（SRPC、共享内存等）。在这种情况下，NaCl模块通常将静态链接到库，该库提供用于访问存储服务的过程接口，隐藏IMC级通信的细节，例如它是否使用SRPC或者它是否使用共享存储器。
请注意，存储服务必须假定图像库不受信任。该服务负责确保它仅提供与用户隐含合同一致的请求。例如，它可能会对照片应用程序使用的总磁盘强制执行限制，并可能进一步限制操作仅引用特定目录。
NC非常适合需要纯计算的应用程序组件。它不适用于需要创建流程，直接文件系统访问或不受限制地访问网络的模块。诸如存储之类的可靠设施通常应在NC之外实现，从而鼓励单个组件的简单性和健壮性，并对所有组件进行更严格的隔离和审查。这种设计选择与微内核操作系统设计相呼应。
（PS:微内核操作系统设计资料:A new kernel foundation for UNIX development、The V distributed system、Unix as an Application Program）
我们现在将更详细地描述关键NaCl系统组件的设计。
2.1 沙盒
NC是围绕特定于x86的内部进程“内部沙箱”构建的。我们相信内部沙箱是健壮的;无论如何，为了提供深度防御（PS:Defense-in-depth against computer viruses)我们还开发了第二个“外部沙箱”，它在过程边界处调解系统调用。外沙箱基本上类似于现有结构（PS:Improving host security with system call policies和A secure enviroment for untrusted helper applications），我们在本文中不会详细讨论。
内部沙箱使用静态分析来检测不受信任的x86代码中的安全缺陷。以前，由于自修改代码和重叠指令等实践，此类分析对任意x86代码提出了挑战。在NC中，我们通过一组对齐和结构规则禁止此类实践，这些规则在观察时确保可以可靠地拆卸本机代码模块，以便在反汇编期间识别所有可到达的指令。通过可靠的反汇编作为工具，我们的验证器可以确保可执行文件仅包含法律指令的子集，禁止不安全的机器指令。
内部沙箱进一步使用x86分段内存来约束数据和指令内存引用。利用现有硬件实现这些范围检查极大地简化了对内存引用进行限制所需的运行时检查，从而降低了安全机制对性能的影响。
此内部沙箱用于在本机操作系统进程中创建安全子域。通过这种组织，我们可以将可信服务运行时子系统放置在与不受信任的应用程序模块相同的进程中，并使用安全的接口，以便将控制从受信任代码安全地转移到不受信任的代码，反之亦然。虽然在某些情况下，进程边界可以有效地包含内存和系统调用副作用，但我们相信内部沙箱可以提供更好的安全性。我们通常假设操作系统没有缺陷，因此进程障碍可能存在缺陷，而且操作系统可能会故意将资源（如共享库）映射到所有进程的地址空间，如Microsoft Windows中所发生的那样。实际上，我们的内部沙箱不仅将系统与本机模块隔离开来，而且还有助于将本机模块与操作系统隔离开来。
2.2 运行时
沙箱可防止不必要的副作用，但通常需要一些副作用才能使本机模块变得有用。对于进程间通信，NC提供可靠的数据报抽象，即“模块间通信”服务或IMC。 IMC允许可信和不可信模块发送/接收由无类型字节数组组成的数据报以及可选的“NaCl资源描述符”，以便跨过程边界共享文件，共享存储对象，通信信道等。 IMC可以由受信任或不受信任的模块使用，并且是两个更高级别抽象的基础。第一个是简单远程过程调用（SRPC）工具，它提供了方便的语法，用于在NaCl模块边界定义和使用子程序，包括在浏览器中从JavaScript调用NaCl代码。第二个是NPAPI，它提供了一个熟悉的界面来与浏览器状态进行交互，包括打开URL和访问DOM，这符合现有的内容安全约束。这些机制中的任何一种都可用于与传统浏览器内容的一般交互，包括内容修改，处理鼠标和键盘活动以及获取其他网站内容;基本上所有可用于JavaScript的资源。
服务运行时负责提供容器，NaCl模块通过容器彼此交互并与浏览器交互。服务运行时提供通常与应用程序编程环境相关联的一组系统服务。它提供 sysbrk() 和 mmap() 系统调用，原语以支持 malloc()/ free() 接口或其他内存分配抽象。它提供了POSIX线程接口的子集，带有一些NaCl扩展，用于创建和销毁线程，条件变量，互斥锁，信号量和线程局部存储。我们的线程支持足够完整，允许英特尔的线程构建块[51]的端口到NC。服务运行时还提供公共POSIX文件I/O接口，用于通信通道上的操作以及基于Web的只读内容。由于这些接口无法访问本地文件系统的名称空间，因此无法实现本地副作用。
为了防止意外的网络访问，简单地省略了诸如 connect() 和 accept() 之类的网络系统调用。 NaCl模块可以通过浏览器中的JavaScript访问网络。此访问受限于适用于其他JavaScript访问的相同约束，对网络安全性没有任何净影响。
NaCl开发环境主要基于Linux开源系统(PS:Ubuntu 14.04)，大多数Linux和Unix开发人员都很熟悉。我们发现移植现有的Linux库通常很简单，大型库通常不需要更改源代码。
2.3 潜在威胁
总的来说，我们认为以下是潜在攻击者可能试图利用的系统组件：
- 内部沙箱：二进制验证
- 外部沙箱：OS系统调用拦截•服务运行时二进制模块加载器
- 服务运行时接口
- IMC通信接口
- NPAPI接口
除了内部和外部沙箱，系统设计还包含CPU和NaCl模块黑名单。这些机制将使我们能够根据我们对各种组件的稳健性的信心以及我们对如何在性能，灵活性和安全性之间实现最佳平衡的理解来整合保护层。
在下一节中，我们希望证明这些设施的安全实现是可能的，并且在我们自己的实现工作中做出的具体选择是合理的。
3 NC实现
书接下文：https://blog.csdn.net/yeshennet/article/details/83792533
玩～