IBM Research 已经创造出一种新的软件安全性衡量方法——Horizontal Attack Profile(简称 HAP)，其发现适当保护下的容器(Containers)几乎能够提供与虚拟机(VM)相媲美的安全水平。

　　虚拟机是否比容器更加安全?

　　虚拟机比容器更加安全!——这可能被大多数人认为是正确答案，但 IBM Research 却发现，容器完全有可能与虚拟机同样安全，甚至更加安全。

　　本文源自E安全

　　容器

　　可以被视为不在虚拟机管理程序上运行的超极简虚拟机。容器不需要安装主机操作系统，可直接将容器层(比如LXC或libcontainer)安装在主机操作系统(通常是 Linux 变种)上，直接利用宿主机的内核，抽象层比虚拟机更少，更加轻量化，启动速度极快。

　　软件安全性衡量方法——HAP方案

　　IBM Research 工程师兼顶尖 Linux 内核开发人员詹姆斯·博顿利(James Bottomley)写道，“目前关于容器与虚拟机管理程序间安全性辩论中的一大核心问题，在于没人能够开发出一种真正可靠的安全性衡量方法。所以争论完全仅限于定性方面(由于接口宽度，虚拟机管理程序“让人觉得”比容器来得更安全)，但实际上还没有人进行过定量比较。

　　为了解决这个难题，博顿利创造了 HAP方案，旨在以客观方式衡量并描述系统的安全性水平。博顿利发现，“采用精心设计的安全计算模式(seccomp)配置文件(用于阻止意外系统调用)的Docker容器提供了与虚拟机管理程序大致相当的安全性。”

　　垂直攻击配置文件VAP

　　博顿利首先定义了垂直攻击配置文件(简称 VAP)。该配置文件中的全部代码用于通过遍历提供服务，从而实现数据库输入与输出信息的更新。与其它程序一样，这部分代码自然也存在 Bug。尽管其 Bug 密度各不相同，但一般来讲遍历的代码越多，其中存在安全漏洞的可能性就越大。HAP就是堆栈安全漏洞(可以跳转进入到物理服务器主机或虚拟机)。

　　HAP 原理

　　HAP 是最为严重的一类安全漏洞。博顿利将其称之为“潜在的商业破坏事件”。当问到如何利用HAP来衡量系统安全时，博顿利解释称：

　　衡量 HAP 的定量方法表明，安全人员可以选定 Linux 内核代码的 Bug 密度，并将其乘以所运行系统在达成稳定状态后(意味着其似乎不再遍历任何新的内核路径)会经过的惟一代码量。

　　这种方法假定 Bug 密度是均匀的，因此 HAP 将近似于稳定状态下所遍历过的代码量。显然，对正在运行的系统进行衡量时不可采取这样的假设，但幸运的是 Linux 内核中存在一种名为 ftrace 的机制，可用于对特定用户空间进程所调用的一切函数进行追踪，从而给出合理的遍历代码行近似值。(注意，这里只是一个近似值，因为我们在测量函数中的总代码行数时由于 ftrace 无法提供足够的细节，而没有考虑到内部代码流的情况。)

　　此外，这种方法对于一切容器都非常有效。控制流通过系统调用信息由一组已声明进程发出，但其并不适用于虚拟机管理程序。这是因为除了对接口进行直接超调用外，大家还需要从后台守护程序处添加追踪(例如 kvm vhost 内核线程或 Xen 中的 dom0)。

　　运行的代码越多越可能存在HAP安全漏洞

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

　　在确定了 HAP 以及如何对其加以衡量之后，博顿利随后运行了几轮基准测试：

　　redis-bench-set;

　　redis-bench-get;

　　python-tornado;

　　node-express。

　　后两者亦运行有配备简单外部事务客户端的 Web 服务器。

　　本文源自E安全

　　博顿利在此次测试当中使用到了：

　　Docker;

　　谷歌 gVisor(一套容器运行时沙箱);

　　使用KVM的同一个容器沙箱gVisor-kvm(KVM是Linux内置的虚拟机管理程序)

　　Kata Containers，一套开源轻量化虚拟机;

　　Nabla，IBM刚刚发布的、具有强大服务器隔离能力的容器类型。

　　博顿利发现，Nabla 运行时拥有“优于 Kata 虚拟机管理程序容器技术的 HAP，这意味着发现了一种在 HAP方面优于虚拟机管理程序(即安全性更高)的容器系统。”

　　不过体现出安全优势的绝不只有 IBM 公司的项目。他同时表示，“具有经过精心策划的 seccompt 配置文件的 Docker 容器(能够阻止意外系统调用)同样能够提供与虚拟机管理程序基本相当的安全表现。”

　　GVisor 的表现则有所不同。好消息是，gVisor 在 Docker 用例方面表现不错;但在另一个用例中，其表现则不及虚拟机管理程序。

　　博顿利推测，这是因为“gVisor 试图通过在 Go 中重写 Linux 系统调用接口以改善兼容性。但是开发人员并没有注意到 Go语言运行时实际使用的系统调用量，而这些结果实际上会暴露在外。”如果他的猜测没错，那么博顿利认为 gVisor 的未来版本可以通过重写来解决这一安全问题。

　　不过，真正的问题并不在于哪种技术本身更加安全。对于最严重的安全问题而言，容器与虚拟机的安全水平大致相当。博顿利认为，“事实上完全有可能出现比虚拟机管理程序更加安全的容器解决方案，而这将给两种技术谁更安全的争论彻底划上句号。”为了弄清二者在恶意应用面前的暴露水平，可能需要采用某种类型的模糊测试。

　　除此之外，博顿利的工作仅仅只是一个开始。他表示，这项工作的价值在于证明以客观方式衡量应用程序安全性并非不可能。他解释称，“我认为这项工作并不代表着争论的结束;但通过对此次测试的详尽描述，他希望更多的人也可能开始自己的量化衡量尝试。

　　责任编辑：DJ编辑