Lars Kurth 谈开源安全流程之二：容器 vs 虚拟机管理程序

【编者的话】随着云平台的日渐流行，其面对的安全问题也越来越严重。近日， Xen 项目顾问委员会主席 Lars Kurth 分享了其对开源安全流程的理解和看法。作为该系列文章四部分的第二篇，本文介绍了Lars 对于容器和虚拟机管理程序的不同安全漏洞的理解。

在这一系列的第一部分，Lars 介绍了他对于云安全背后的理论和这些理论与《行尸走肉》（The Walking Dead 2）电视剧的关系。阅读第1 部分：云安全介绍。

随着虚拟化软件的发展，每一个接口中的每一个要素都有机会犯错误，接口调用每一段代码都可能会引入漏洞，接口的每一个角落都可能给攻击者提供突破的机会。这就是所谓的“受攻击面”，信息技术需要考虑由虚拟化软件本身的接口中的漏洞所带来的风险，以及当接口被调用的时候需要执行的代码量。

通过给定不同的功能，让我们介绍“受攻击面”是如何形成的，以及在流行的云技术中它们有什么关联和差异。

首要攻击媒介：操作系统功能

虚拟化和容器的基本构建模块是调度和内存管理。在Xen 的环境下，虚拟机管理程序整个从头到尾重新实现了这个功能。Linux 内核展示的KVM 功能，由KVM 内核模块进行增强，被调度虚拟机重用，并用来管理它的内存。在这种模式下，每一个虚拟机都是一个Linux 进程，这个进程通过Linux 调度器调度，同时它的内存是由Linux 的内存分配器分配。相同的复用的概念也适用于容器。

KVM 和容器之间的主要区别是：KVM 在每个虚拟机（要么是 Linux 的不同版本，要么是完全不同的操作系统内核，如 Windows）中运行一个单独的内核实例，并使用一个内核模块和 QEMU 来实现额外的条块分割。容器使用相同的内核实例，并通过内核的系统调用接口的单个实例来管理容器以及容器中运行的应用程序。

尽管容器中的 Linux 内核的重用有许多优点，但需要在经由系统接口的可用功能的广度与它背后的代码之间进行平衡。这增加了代码中出现错误的风险，以及相比 Xen 更容易出现漏洞，Xen 仅实现必要的部分，另外，KVM 重新使用 KVM 内的内核功能，而不直接将其暴露给客户虚拟机。

如果你将 Linux 内核系统调用接口与 Xen 的调用接口进行比较，Linux 的外部接口中的幅度差大于 300，而 Xen 的外部接口中的幅度差仅仅为 40。内核给你提供文件系统，其中包括了文件、目录、查找、FSTAT、阅读、MMIO 和 AIO。你可以创建多少种不同的 sockets 呢？存在多少种不同的 IPC 机制呢？所有带有内部状态的事情都必须正确处理，如 Futexes、共享内存、读写控制、TTY。在 Linux 系统调用接口，还有更多的机会可能会犯错。如下表 1 所示，在一个更加规则的基础上，会出现了更多的错误。这给问题增加了复杂性和受攻击面的数量。

第二攻击媒介：设备仿真

虚拟机管理程序，如 Xen 和 KVM，使用 QEMU 作为设备模型仿真器来仿真服务器硬件部件，如主板，定时器，内核中的外部中断和 I/O。 Xen 在某些情况下（例如，x86 的 HVM，但不适用于 x86 的 PV，以及 ARM 架构）只使用仿真，而 KVM 完全依赖于 QEMU（或提供类似功能的替代方案）。

设备仿真很复杂，其原因有两个。首先，硬件接口需要权衡硬件实现与软件执行之间的关系，其次，在此过程中需要仿真大量设备。这就是为什么我们最近在 QEMU 中常常看到漏洞增加的原因。

表 1：该表显示了关于显著的漏洞的一个调查结果，该结果发表于 FOSDEM 2015。 m 相应的 2015 年的调查还没有执行，还需要花费更多的努力。要注意的是，Xen HVM 的图有一些类似于带 QEMU 的 KVM。

第三攻击媒介：I / O 和设备驱动程序

如前所述，系统的 I / O 是恶意的有效载荷进入云系统的主要途径。攻击通常试图利用设备驱动程序的漏洞，这给攻击者提供了访问系统中所有内容的路径，因为设备驱动程序运行在 Linux 内核模式下。在虚拟化环境中，设备驱动程序漏洞可能赋予攻击者单个虚拟机的控制权限，但为了攻击主机上的其他虚拟机，就需要利用额外的漏洞来获得对主机的控制。

由于仿真在本质上是非常缓慢的，Xen 和 KVM 为磁盘和网络访问采用半虚拟化 I / O 驱动程序，因此二者不需要仿真。半虚拟化 I / O 驱动程序往往是非常简单的，将其与容器相比，半虚拟化 I / O 驱动程序采用单内核实例的系统调用接口，并能够实现与设备驱动程序的交互。正如前面指出的，系统调用接口的工作量是非常大的，远远超过 PV I / O，以及组合的仿真 I / O。因为设备驱动程序是运行在内核模式下，因此相比虚拟机管理程序的部署，容器部署带来的风险会高得多。

结论

针对容器技术，最近不少厂商也开发了许多安全功能，如每个容器的 ulimit、容量消减、设备访问限制、Linux 安全模块（SELinux、AppArmor）的改进处理、用户命名空间的提高，以及所有的深度防御（多重保护层）的例子

尽管有了这些努力，以及尽量用最小的 Linux 发行版，与虚拟机管理程序相比，容器的根本问题仍然存在，因为它们有一个非常大的“受攻击面”，使得它们本质上非常脆弱。这就是为什么我们需要尝试将虚拟化技术与容器进行结合，比如超清晰容器和 Xen 容器，现在都已经开始在制造声势。

编后语

《他山之石》是 InfoQ 中文站新推出的一个专栏，精选来自国内外技术社区和个人博客上的技术文章，让更多的读者朋友受益，本栏目转载的内容都经过原作者授权。文章推荐可以发送邮件到 editors@cn.infoq.com。

感谢董志南对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。