现代时代的安全性

安全地运行需要完整系统调用接口的进程

Jessie Frazelle

在云端部署应用程序时，从业者力求使用最适合工作的操作工具集；当然，确定“正确”的工具并非易事。早在2013年，Docker就以其易用性赢得了开发人员的青睐，但Linux容器本身早在2007年就已出现，当时cgroups（控制组）被添加到内核中。如今，容器已经催生了一个庞大的新工具和实践生态系统，许多专业人士每天都在使用它们。然而，构成容器的基础技术并非新事物。与Solaris Zones或FreeBSD Jails不同，Linux容器不是以隔离为目的构建的离散内核组件。相反，Linux容器是内核中多种技术的组合：命名空间、cgroups、AppArmor和SELinux（安全增强型Linux），仅举几例。

容器不是应用程序开发人员今天通常遇到的抽象概念。趋势是朝着函数和“无服务器”方向发展，允许用户在云端运行单个函数。由于应用程序和函数在云端运行的方式，很可能会出现新一代的隔离技术，围绕着以简单和最小化的方式安全地运行单个进程而构建。

虽然有证据表明，“具有精心设计的seccomp（安全计算模式）配置文件（阻止意外系统调用）的容器提供的安全性大致相当于虚拟机”（https://blog.hansenpartnership.com/measuring-the-horizontal-attack-profile-of-nabla-containers/），但仍然需要方法来安全地运行那些需要完整系统调用接口的进程。解决这个问题引发了一些有趣的研究。

让我们来看看在这些领域正在进行的一些研究。

虚拟机与容器

我的虚拟机比你的容器更轻（更安全）；

Filipe Manco 等人

https://dl.acm.org/citation.cfm?id=3132763

容器作为虚拟机的替代品而流行起来，因为它们在快速启动、小内存开销以及允许在单台机器上实现高密度方面表现更好。本文探讨了创建满足相同要求的虚拟机，以及容器的暂停和取消暂停功能。

考虑到大多数容器所需的功能是单个应用程序，作者探索了unikernel（操作系统直接链接到应用程序的最小虚拟机）和TinyX（用于为应用程序创建最小Linux发行版的工具）。虚拟机镜像越小，内存占用就越小，镜像启动速度就越快。

对于容器，就像在主机上运行的典型进程一样，启动的进程或容器的数量不会影响启动它们的时间，前提是关于资源不是无限的通常警告，即使在云端也是如此。虚拟机的情况并非如此。启动虚拟机的开销会随着运行的虚拟机数量的增加而增加。作者发现在 Xen 的情况下，这是设备创建时间和与 XenStore 交互的结果。作者实现了他们自己的 LightVM，以解决他们在 Xen 中发现的许多算法和设计问题。

他们努力的结果是最小的虚拟机，可以在短短 2.3 毫秒内启动。标准的 Linux 进程启动大约需要 1 毫秒，而 docker 容器启动大约需要 40 毫秒，具体取决于镜像的大小。随着启动更多虚拟机，启动时间保持不变，这与典型的虚拟机形成鲜明对比。然而，Unikernel 不像容器那样容易创建，并且需要为每个应用程序投入单独的开发时间才能使其正常工作。

以最小的方式隔离应用程序

Unikernel 监视器：将极简主义扩展到盒子之外；

Dan Williams 和 Ricardo Koller

https://dl.acm.org/citation.cfm?id=3027053

最小化的软件具有减少攻击面并使软件更易于理解且开销更小的优点。Unikernel 经常在云端运行程序的最小化和安全方式的背景下被讨论。在传统方法中，unikernel 是一个虚拟机，因此，它在虚拟机监视器中运行，虚拟机监视器是监视和控制虚拟机生命周期的程序，例如 VMWare、QEMU 或 VirtualBox。Unikernel 监视器捆绑到 unikernel 中。这创建了一种最小化的方式来启动 unikernel，而无需使用独立的虚拟机监视器增加复杂性。

大多数虚拟机管理器/监视器都很笨重，具有现代或云环境中未使用的设备的功能。以 QEMU 为例：它带有键盘和软盘驱动器等设备的仿真。如果软盘驱动器仿真器中存在漏洞，那么整个系统就完了，即使软盘驱动器在云端显然没有任何用处。

如果监视器是专门为启动 unikernel 而构建的，那么它的计算基础比今天使用的虚拟机监视器要小得多（大约只有其大小的百分之五）。本文的作者创建了一个监视器，它只有两个任务：创建隔离以运行 unikernel，以及在 unikernel 退出时执行操作。监视器也嵌入到 unikernel 的可执行文件中，为分发和执行 unikernel 创建了一种简单而最小化的方法。

他们的原型启动时间为 10 毫秒，比传统监视器快八倍。本文对未来持积极愿景，即在云端以最小化和安全的方式运行应用程序。IBM 最近围绕本文的主题和实现发布了一个名为 Nabla 的容器运行时 (https://nabla-containers.github.io/)。

在运行时层虚拟化

Alto：使用虚拟化感知托管运行时的轻量级虚拟机；

James Larisch、James Mickens 和 Eddie Kohler https://mickens.seas.harvard.edu/files/mickens/files/alto.pdf

传统的虚拟机（如 Xen）在硬件层虚拟化。另一方面，Docker 在 POSIX 层虚拟化。本文提出了一种在运行时层虚拟化的新方法。

这个领域中较难的问题之一是如何处理状态。在传统环境中，文件系统和网络的状态在内核中处理。作者建议通过用户空间网络堆栈和 FUSE 文件系统将尽可能多的内核状态移到虚拟机中。他们还建议将每个状态对象明确地描述为一个可寻址的服务器（每个服务器都有自己的 IP 地址），从而使操作员可以轻松地迁移和更新应用程序，因为程序的代码、堆栈和堆之间有清晰的分离。

通过在内存分配、垃圾回收和状态管理方面的创新，Alto 似乎是最接近以最小化方式保护进程安全，同时为操作员提供一组新控件的解决方案。作为一个花了很多时间思考创建最小化、虚拟化容器运行时所面临问题的人，我非常喜欢本文提出的问题陈述和解决方案。

阻止应用程序中的攻击者

Chaff Bugs：通过使软件更易出错来阻止攻击者；

Zhenghao Hu、Yu Hu 和 Brendan Dolan-Gavitt

https://arxiv.org/abs/1808.00659

软件和系统的防御通常包括纠正可能被利用的错误，以及构建具有多层安全性的软件，这意味着即使攻击者穿透了系统的一层，他们也必须穿透另一层才能发现任何有价值的东西。代码的静态分析有助于自动化今天的某些工作，但仍然不能保证软件安全。

人们往往不认真对待“通过混淆实现安全”，但这种技术确实有一些价值。地址空间布局随机化就是这种方法的一个例子。然而，它会带来性能成本。

本文描述了一种减缓试图利用您的系统的攻击者的新方法。由于这种方法会自动将不可利用的错误注入到软件中，因此发现这些错误的攻击者将浪费宝贵的时间来分类错误，以便恶意使用它，并且会失败。在某些情况下，注入的错误会导致程序崩溃，但在现代分布式系统中，这不太可能成为问题，因为许多程序使用进程池，并且高可用性系统（如使用容器的系统）通常具有在崩溃时自动重启程序的策略。

注入的错误有两种形式：覆盖未使用数据的错误和使用不可利用的值覆盖敏感数据的错误。前者相当简单：将未使用的变量注入到代码中，并确保虚拟变量直接放置在将要溢出的变量旁边。在后者覆盖敏感数据的情况下，攻击者的输入值受到过度约束，这意味着它具有一组定义的约束，这些约束通过位掩码和控制数据传递的路径而最终被强制为零。

本文的关键见解是，与其试图减少程序中的错误数量，不如增加错误数量，但使其不可利用，从而通过浪费攻击者的时间来阻止他们。过度约束输入检查仍然会带来性能开销，并且攻击者是否可以找到注入错误中的模式以自动排除它们还是一个悬而未决的问题。然而，这足以欺骗 gdb 等工具，这些工具认为这些错误“可利用”和“可能可利用”。未来版本的这种方法是否可以设计得不同，以便对开源项目更有用？拥有源代码肯定会让攻击者在发现哪些错误是真实的，哪些是注入的方面具有优势。

以可用的方式保护应用程序的未来

容器生态系统发展非常迅速。许多公司正在现有技术的基础上构建产品，而企业正在使用这些技术和产品来运行其基础设施。此处描述的三篇论文的重点是底层技术本身的进步以及在现代时代保护软件安全的战略方法。

第一篇论文从纯粹作为运行应用程序的机制的角度重新思考了现代环境中的虚拟机。这允许创建最小的虚拟机，这些虚拟机在内存开销、密度和启动时间方面可以像容器一样运行。第二篇论文更进一步，将监视器打包到 unikernel 中。这是一种极其可用的执行 unikernel 的方式，因为操作员不必安装虚拟机管理器。它还允许使用更小的监视器，限制攻击面。IBM 最近推出的 Nabla 容器运行时就是这些方法的一个例子。这两篇论文都利用了 unikernel，并且存在一个开放性问题，即 unikernel 最终是否能像今天的容器一样易于构建。这将是这些实现需要克服的障碍。

第三篇论文提出了一种全新的方法，该方法还为操作员提供了一组新的状态管理控件。通过地址空间隔离并将每个状态片段绑定到一个 IP 地址，操作员可以清楚地控制程序的代码、堆栈和堆。Alto 不仅在隔离技术方面进行了创新，而且在可操作性和控制方面也进行了创新。

这应该推动更轻松地调试在最小虚拟机中运行的应用程序的方法。在这些应用程序能够像标准 Linux 容器一样轻松地进行调试之前，大多数从业者的采用速度将会很慢，因为学习曲线更高。

最后，隔离并不是保护应用程序安全的唯一方法。最后一篇论文可能会启发其他人设计新的自动化方法来阻止攻击者。

为操作员提供一种可用的方法来保护他们用于部署和运行应用程序的方法对每个人来说都是双赢的。保持容器提供的以可用性为中心的抽象，同时找到自动化安全性和防御攻击的新方法，是一条很好的前进道路。

Jessie Frazelle 在 Microsoft 云组织工作。她是 Docker 的维护者，并且一直是容器生态系统内外许多不同开源项目的核心贡献者。她非常热爱可用、简洁的界面、性能和安全性，特别是围绕隔离的技术。

最初发表于 Queue vol. 16, no. 5—
在数字图书馆中评论本文

更多相关文章

Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用机密联邦学习的可信 AI
安全性、隐私性、问责制、透明度和公平性原则是现代人工智能法规的基石。经典的 FL 设计非常强调安全性和隐私性，但代价是透明度和问责制。CFL 通过将 FL 与 TEE 和承诺相结合来弥补这一差距。此外，CFL 还带来了其他理想的安全属性，例如基于代码的访问控制、模型机密性和推理期间模型的保护。机密计算（如机密容器和机密 GPU）的最新进展意味着现有的 FL 框架可以无缝扩展以支持低开销的 CFL。

Raluca Ada Popa - 机密计算还是密码学计算？
通过 MPC/同态加密与硬件 enclave 进行安全计算，在部署、安全性和性能方面存在权衡。关于性能，您脑海中的工作负载非常重要。对于简单的汇总、低阶多项式或简单的机器学习任务等简单工作负载，这两种方法都可以在实践中随时使用，但对于复杂的 SQL 分析或训练大型机器学习模型等丰富的计算，目前只有硬件 enclave 方法对于许多实际部署场景来说足够实用。

Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa - 机密容器组
此处介绍的实验表明，Parma（在 Azure 容器实例上驱动机密容器的架构）增加的额外性能开销不到底层 TEE 增加的开销的百分之一。重要的是，Parma 确保了容器组所有可达状态的安全性不变量，该不变量植根于证明报告中。这允许外部第三方与容器安全地通信，从而支持各种需要机密访问安全数据的容器化工作流程。公司获得了在云端运行最机密工作流程的优势，而无需在其安全要求上妥协。

Charles Garcia-Tobin, Mark Knight - 使用 Arm CCA 提升安全性
机密计算有很大的潜力通过将监控系统从 TCB 中移除来提高通用计算平台的安全性，从而减小 TCB 的大小、攻击面以及安全架构师必须考虑的攻击向量。机密计算需要在平台硬件和软件方面进行创新，但这些创新有可能增强对计算的信任，尤其是在第三方拥有或控制的设备上。机密计算的早期消费者将需要自行决定他们选择信任的平台。