容器和虚拟机安全性分析.docxVIP

容器和虚拟机安全性分析 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 有可能被重写，以大大提高安全性。 不过，真正的问题不在于哪种技术本身更安全。对于最严 重的安全问题来说，容器和虚拟机的安全级别大致一样。 的确， 博顿利认为，“完全有可能拥有比虚拟机管理程序更安全的容 器，关于哪种技术来得更安全的争论可以停止了。” 他继续说：“下一步是查明暴露在恶意应用程序面前的程度，为此需要采用某种类型的模糊测