IBM Research 已經創造出一種新的軟件安全性衡量方法——Horizontal Attack Profile（簡稱 HAP），其發現適當保護下的容器（Containers）幾乎能夠提供與虛擬機(VM)相媲美的安全水平。

虛擬機是否比容器更加安全？

虛擬機比容器更加安全！——這可能被大多數人認為是正確答案，但 IBM Research 卻發現，容器完全有可能與虛擬機同樣安全，甚至更加安全。

容器

可以被視為不在虛擬機管理程序上運行的超極簡虛擬機。容器不需要安裝主機操作系統，可直接將容器層(比如LXC或libcontainer)安裝在主機操作系統(通常是 Linux 變種)上，直接利用宿主機的內核，抽象層比虛擬機更少，更加輕量化，啟動速度極快。

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

IBM Research 工程師兼頂尖 Linux 內核開發人員詹姆斯·博頓利（James Bottomley）寫道，“目前關于容器與虛擬機管理程序間安全性辯論中的一大核心問題，在于沒人能夠開發出一種真正可靠的安全性衡量方法。所以爭論完全僅限于定性方面（由于接口寬度，虛擬機管理程序“讓人覺得”比容器來得更安全），但實際上還沒有人進行過定量比較。

為了解決這個難題，博頓利創造了HAP方案，旨在以客觀方式衡量并描述系統的安全性水平。博頓利發現，“采用精心設計的安全計算模式（seccomp）配置文件（用于阻止意外系統調用）的Docker容器提供了與虛擬機管理程序大致相當的安全性?！?/p>

垂直攻擊配置文件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 服務器。

博頓利在此次測試當中使用到了：

Docker；

谷歌 gVisor（一套容器運行時沙箱）；

使用KVM的同一個容器沙箱gVisor-kvm（KVM是Linux內置的虛擬機管理程序）

Kata Containers，一套開源輕量化虛擬機；

Nabla，IBM剛剛發布的、具有強大服務器隔離能力的容器類型。

博頓利發現，Nabla 運行時擁有“優于 Kata 虛擬機管理程序容器技術的 HAP，這意味著發現了一種在 HAP方面優于虛擬機管理程序（即安全性更高）的容器系統。”

不過體現出安全優勢的絕不只有 IBM 公司的項目。他同時表示，“具有經過精心策劃的 seccompt 配置文件的 Docker 容器（能夠阻止意外系統調用）同樣能夠提供與虛擬機管理程序基本相當的安全表現?！?/p>

GVisor 的表現則有所不同。好消息是，gVisor 在 Docker 用例方面表現不錯；但在另一個用例中，其表現則不及虛擬機管理程序。

博頓利推測，這是因為“gVisor 試圖通過在 Go 中重寫 Linux 系統調用接口以改善兼容性。但是開發人員并沒有注意到 Go語言運行時實際使用的系統調用量，而這些結果實際上會暴露在外?！比绻牟聹y沒錯，那么博頓利認為 gVisor 的未來版本可以通過重寫來解決這一安全問題。

不過，真正的問題并不在于哪種技術本身更加安全。對于最嚴重的安全問題而言，容器與虛擬機的安全水平大致相當。博頓利認為，“事實上完全有可能出現比虛擬機管理程序更加安全的容器解決方案，而這將給兩種技術誰更安全的爭論徹底劃上句號?！睘榱伺宥咴趷阂鈶妹媲暗谋┞端?，可能需要采用某種類型的模糊測試。

除此之外，博頓利的工作僅僅只是一個開始。他表示，這項工作的價值在于證明以客觀方式衡量應用程序安全性并非不可能。他解釋稱，“我認為這項工作并不代表著爭論的結束；但通過對此次測試的詳盡描述，他希望更多的人也可能開始自己的量化衡量嘗試。