容器比虚拟机“更安全”

IBM研究院（IBM Research）设计了一种衡量软件安全性的新方法：横向攻击剖面（HAP），它发现采取适当保护的容器与虚拟机一样安全，甚至来得更安全。

IBM研究院杰出工程师兼顶级Linux内核开发人员詹姆斯•博顿利（James Bottomley）说：“目前容器与虚拟机管理程序安全性谁更高这场争论方面最大的一个问题是，还没有人真正开发出一种方法来衡量安全性，所以争论完全仅限于定性方面（由于接口宽度，虚拟机管理程序“让人觉得”比容器来得更安全），但实际上还没有人进行过定量比较。”为了满足这个要求，博顿利设计出了横向攻击剖面（HAP），这种新方法旨在以一种可以客观衡量的方法来描述系统安全。博顿利发现，“采用精心设计的安全计算模式（seccomp）剖面（可阻止意外系统调用）的Docker容器提供了与虚拟机管理程序大致相当的安全性。”

博顿利先定义了纵向攻击剖面（VAP）。这全是代码，遍历代码以便为从输入、数据库更新到输出的各种任务提供服务。与所有程序一样，该代码含有bug。bug密度各不相同，但是你遍历的代码越多，暴露于安全漏洞的可能性就越大。HAP就是堆栈安全漏洞（可以跳转进入到物理服务器主机或虚拟机）。

HAP是最糟糕的那种安全漏洞。博顿利称之为“可能破坏企业的事件”。那么，你如何就HAP方面衡量系统呢？ 博顿利这样解释：

衡量HAP的定量方法是指，我们拿来Linux内核代码的bug密度，乘以运行中的系统在达到稳定状态后（这意味着它似乎并不遍历任何新的内核路径）遍历的独特代码数量。为了采用这种方法，我们假设bug密度是一致的，因此HAP近似于稳定状态下遍历的代码数量。针对运行中的系统衡量这个指标完全是另一回事，不过幸好，内核有一个名为ftrace的机制，可用于对某个特定用户空间进程调用的所有函数进行跟踪（trace），从而给出遍历的代码行数的合理近似值。（注意：这是一个近似值，因为我们衡量函数中的代码行总数，并未考虑内部代码流，这主要是由于ftrace没有给出那么多详细的信息。）此外，这种方法非常适用于这种情形下的容器：所有的控制流通过系统调用信息来自一组众所周知的进程，但是它不太适用于这种情形下的虚拟机管理程序：除了直接的超级调用（hypercall）接口外，你还得添加来自后端守护程序（比如kvm vhost内核或Xen这种情况下的dom0）的跟踪。

简而言之，你衡量一个系统（无论它是裸机、虚拟机还是容器）运行某个特定应用程序使用了多少行代码。它运行的代码越多，存在HAP级别的安全漏洞的可能性就越大。

博顿利在定义了HAP以及如何衡量它后，运行了几个标准基准测试：redis-bench-set、redis-bench-get、python-tornado和node-express，后两项基准测试还运行了装有简单的外部事务型客户软件的Web服务器。他针对下列多个系统执行了上述测试：Docker、谷歌的gVisor（容器运行时沙箱）、使用KVM的同一个容器沙箱gVisor-kvm（KVM是Linux内置的虚拟机管理程序）、开源轻量级虚拟机Kata Containers以及IBM刚发布的容器Nabla（专为强大有效的服务器隔离而设计）。

博顿利发现，Nabla运行时环境的“HAP比含有虚拟机管理程序的Kata技术更好，这意味着我们获得了HAP比虚拟机管理程序更好（即更安全）的容器系统。”

不过，不仅仅是IBM的项目证明了容器更安全。他还发现，“采用精心设计的安全计算模式（seccomp）剖面（可阻止意外系统调用）的Docker容器提供了与虚拟机管理程序大致相当的安全性。”

gVisor是另一种情况。gVisor的最佳结果和Docker用例不相上下，但在一种用例下，其安全性差得多。博顿利推测，那是由于“gVisor试图通过用Go来重写Linux系统调用接口来改进隔离性。然而，没有人注意过Go运行时环境实际使用的系统调用数量，这正是这些结果实际所显示的。”如果是这种情况，博顿利认为将来版本的gVisor有可能被重写，以大大提高安全性。

不过，真正的问题不在于哪种技术本身更安全。对于最严重的安全问题来说，容器和虚拟机的安全级别大致一样。的确，博顿利认为，“完全有可能拥有比虚拟机管理程序更安全的容器，关于哪种技术来得更安全的争论可以停止了。”

他继续说：“下一步是查明暴露在恶意应用程序面前的程度，为此需要采用某种类型的模糊测试。”

此外，博顿利的工作仅仅开了个头。他表明了可以客观地衡量应用程序的安全性。正如他所说，“我认为这不是这场争论的最终结语，但是通过描述我们如何做到这一点，我希望其他人也能设计出定量衡量方法。”