BlackBox：在不受信任的系统上保护容器安全

论文地址：https://www.usenix.org/system/files/osdi22-vant-hof.pdf

这篇论文使用了硬件虚拟化对容器进行隔离，从而实现了轻量化的容器隔离与安全加强。文章的核心想法并不新奇，有很多类似的工作采用了虚拟化以及VMFUNC做内存隔离。其核心的贡献点，在于能够支持未经修改Docker应用，以及对syscall的支持较为完整。由此可见，Solid的工作也是会受到PC们的青睐。

背景

容器作为共享计算的基础设施，被广泛地运用在应用程序的部署，打包与应用隔离中。相较于虚拟机的方式，容器所需要的资源更加少，有更好的启动性能与IO的性能。但是，容器以来与特权OS作为安全的保障，然后以Linux为代表的商用OS代码量大，复杂存在很多攻击的漏洞。攻击者可以通过攻击OS从而实现对容器中数据和内容的攻击。

近几年也有不少的工作，通过不同的软硬件机制，对容器的安全进行加强。例如，基于硬件Enclave的方式对容器中的代码和数据进行强隔离，但是需要应用开发者重写代码，并且会引入较高的CPU计算的开销。而基于虚拟化的方式，也会增加虚拟化的开销同时引入guest OS的代码扩大的TCB。因此当前缺少一种轻量化的安全容器方案。

设计

为了实现轻量级安全容器，作者提出了BlackBox的设计，它能够提供细粒度的内存隔离，同时保护容器的完整性和机密性，并且不需要相信OS。如上图所示，在BlackBox中引入了一个新的安全监视器：container security monitor (CSM), 它负责提供一个受保护的内存空间protected physical address space（PPASes），保证所有外部的代码无法访问受保护的内存地址中的数据，同时内部的代码也无法访问其他的PPASes空间。

BlackBox重用了虚拟化技术，只用于对内存的隔离，而不需要做任何虚拟化相关的工作，从而极大减少了TCB的大小（不需要GuestOS的介入）。BlackBox不需要修改容器中运行的应用程序。应用程序和OS之间的交互会受到CSM的检查（例如系统调用，中断和异常），如果一个受保护的容器需要切换到OS中运行，CSM会将所有与容器相关的寄存器保存并清零；反之，CSM会恢复容器的上下文，并且给予其访问对应PPAse的权限。其中syscall的参数是唯一一个容器内的内容需要被OS访问。CSM会将syscal的参数拷贝到OS的内存中，同时对IO的数据进行端到端的加密。为了保证没有恶意的代码运行在容器中，所有加载到容器中的代码，都需要容器的提供者签名并且加密，由CSM负责解密并加载。

内存隔离

CSM保证OS无法直接访问容器中的内存，为了减少CSM的TCB，CSM允许OS进行内存分配。但是与此同时，需要防止OS发起基于内存的Iago攻击。例如用户希望通过mmap得到一块没有被使用过的内存，但是OS可能返回一个栈地址空间，导致栈上的数据被覆盖重写。

为了解决这个问题，BlackBox不允许OS直接修改容器的页表，而需要CSM介入。CSM会对页表修改的操作做两个检查：

（1）所有映射的虚拟地址是一个合法的地址；

（2）映射的物理地址不在容器所有的PPAS中。

除此之外，BlackBox还提供额外的接口允许OS以CoW的方式获得container中内存数据，但是需要经过CSM的额外的安全检查；同时BlackBox也支持动态的内存回收。

很多系统调用会需要传递内存数据，在BlackBox中采用了和OS共享的缓存，作为系统调用源内存地址。CSM会将需要传递的内存数据拷贝到该缓存区中。对于系统调用的返回值，CSM也会做检查，保证所有的返回值落在预定义的返回值区间内。

进程间通信

类似于pipe以及Unix socket这类system cal允许实现进程间通信。当container想要和外部通信前，会将需要传递的数据加密并拷贝到syscall的共享内存中。数据的加密传输同样应用在read/recvmsg这类调用时。在实现IPC的时候，需要使用futex进行同步保护，因为futex需要OS和container共享同一个futex的标记，所以CSM提供了一个新的CSM call允许OS通过该接口读取在container中存储的futex标记。同时，还需要实现通知的机制，BlackBox采用了signal的机制，但是由于OS需要创建一个signal的栈，所以在创建的时候，OS将signal的栈建立在PPAS之外，当处理signal的时候，CSM会将signal的栈移到PPAS之中。当signal执行结束之后，再将signal的栈移到PPAS之外。

容器的文件系统

为了减少TCB，BlackBox让应用加密保护敏感的数据，并且允许OS加载加密的二进制文件并且正常执行。

实验

作者在两个Arm的平台：Raspberry Pi 4 Model B with a 4-core Cortex-A72以及AMD Seattle Rev.B0 server with an 8-core Cortex-A57 64-bit ARMv8-A 2 GHz AMD Opteron A1100 SoC进行的测试。比较了BlackBox和docker之间的性能。作者选择了四个比较的对象（以native没有采用容器隔离作为baseline）：

（1）Docker以及未经修改了Linux容器；

（2）BlackBox以及未经修改的Linux容器，但使能了NPT；

（3）BlackBox使用CSM对容器进行管理，但是没有使能加密IPC；

（4）BlackBox采用了CSM以及加密的IPC等。

测试结果：

null syscall上BlackBox虽然会导致一定的overhead，但是主要的开销在seccomp做的syscall过滤。而CSM call在Arm的架构上因为有独自的EL2的寄存器，所以开销只在于存储与恢复通用寄存器，因此不是主要的开销。

读和写会造成小于两倍的开销，因为需要将读写的内容先拷贝到共享的syscall缓存中。Fork会造成小于三倍的开销，因为在exec的时候会调用mmap需要进行额外的检查，同时加载的binary需要经过解密。

加密的IPC在大多数的场景中的开销都比较小，但是在pipe, UNIX socket等IPC机制中的开销非常的明显。当然，这部分开销也是显而易见的，因为需要对传输的数据进行加解密保护。

作者在memcached, MySQL, and Nginx这些应用上测试结果表明，在真实应用上BlackBox的开销小于15%

总结

该论文采用的方法：NPT对内存进行隔离，以及一个安全monitor对容器和OS之间的交互进行保护，都是非常成熟的技术。同时在测试部分，也只是和docker进行了比较，没有和其他安全容器的技术进行比较，在部分benchmark上的性能相较于其他方式，并没有明显的提高。

Q&A

Q1：因为BlackBox假设OS是不可信，如何保证运行在OS之下的CSM是可信的呢？

A1：我们认为系统的启动是可信的，我们通过安全启动的方式验证CSM代码的完整性

Q2：有提供运行时验证的机制吗？开发者如何知道，应用程序被安全并完整地加载到了BlackBox之中？

A2：应用程序会被开发者加密，在加载的时候有CSM解密，并且检验其完整性。

推荐

中间件的过去、现在和未来

论如何解决学习通被拖库导致的数据泄漏问题

---

随手关注或者”在看“，诚挚感谢！