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

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

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

容器

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

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

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

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

垂直攻擊配置文件VAP

博頓利首先定義了垂直攻擊配置文件（簡稱 VAP）。該配置文件中的全部代碼用于通過遍歷提供服務(wù)，從而實現(xiàn)數(shù)據(jù)庫輸入與輸出信息的更新。與其它程序一樣，這部分代碼自然也存在 Bug。盡管其 Bug 密度各不相同，但一般來講遍歷的代碼越多，其中存在安全漏洞的可能性就越大。HAP就是堆棧安全漏洞（可以跳轉(zhuǎn)進入到物理服務(wù)器主機或虛擬機）。

HAP 原理

HAP 是最為嚴重的一類安全漏洞。博頓利將其稱之為“潛在的商業(yè)破壞事件”。當問到如何利用HAP來衡量系統(tǒng)安全時，博頓利解釋稱：

衡量 HAP 的定量方法表明，安全人員可以選定 Linux 內(nèi)核代碼的 Bug 密度，并將其乘以所運行系統(tǒng)在達成穩(wěn)定狀態(tài)后（意味著其似乎不再遍歷任何新的內(nèi)核路徑）會經(jīng)過的惟一代碼量。

這種方法假定 Bug 密度是均勻的，因此 HAP 將近似于穩(wěn)定狀態(tài)下所遍歷過的代碼量。顯然，對正在運行的系統(tǒng)進行衡量時不可采取這樣的假設(shè)，但幸運的是 Linux 內(nèi)核中存在一種名為 ftrace 的機制，可用于對特定用戶空間進程所調(diào)用的一切函數(shù)進行追蹤，從而給出合理的遍歷代碼行近似值。（注意，這里只是一個近似值，因為我們在測量函數(shù)中的總代碼行數(shù)時由于 ftrace 無法提供足夠的細節(jié)，而沒有考慮到內(nèi)部代碼流的情況。）

此外，這種方法對于一切容器都非常有效。控制流通過系統(tǒng)調(diào)用信息由一組已聲明進程發(fā)出，但其并不適用于虛擬機管理程序。這是因為除了對接口進行直接超調(diào)用外，大家還需要從后臺守護程序處添加追蹤（例如 kvm vhost 內(nèi)核線程或 Xen 中的 dom0）。

運行的代碼越多越可能存在HAP安全漏洞

簡而言之，你衡量一個系統(tǒng)（無論它是裸機、虛擬機還是容器）運行某個特定應(yīng)用程序使用了多少行代碼。其運行的代碼越多，存在HAP級別的安全漏洞的可能性就越大。

在確定了 HAP 以及如何對其加以衡量之后，博頓利隨后運行了幾輪基準測試：

redis-bench-set；

redis-bench-get；

python-tornado；

node-express。

后兩者亦運行有配備簡單外部事務(wù)客戶端的 Web 服務(wù)器。

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

Docker；

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

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

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

Nabla，IBM剛剛發(fā)布的、具有強大服務(wù)器隔離能力的容器類型。

博頓利發(fā)現(xiàn)，Nabla 運行時擁有“優(yōu)于 Kata 虛擬機管理程序容器技術(shù)的 HAP，這意味著發(fā)現(xiàn)了一種在 HAP方面優(yōu)于虛擬機管理程序（即安全性更高）的容器系統(tǒng)。”

不過體現(xiàn)出安全優(yōu)勢的絕不只有 IBM 公司的項目。他同時表示，“具有經(jīng)過精心策劃的 seccompt 配置文件的 Docker 容器（能夠阻止意外系統(tǒng)調(diào)用）同樣能夠提供與虛擬機管理程序基本相當?shù)陌踩憩F(xiàn)?！?/p>

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

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

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

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