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

虛擬機(jī)是否比容器更加安全？

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

容器

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

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

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

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

垂直攻擊配置文件VAP

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

HAP 原理

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

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

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

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

運(yùn)行的代碼越多越可能存在HAP安全漏洞

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

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

redis-bench-set；

redis-bench-get；

python-tornado；

node-express。

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

博頓利在此次測試當(dāng)中使用到了：

Docker；

谷歌 gVisor（一套容器運(yùn)行時沙箱）；

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

Kata Containers，一套開源輕量化虛擬機(jī)；

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

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

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

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

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

不過，真正的問題并不在于哪種技術(shù)本身更加安全。對于最嚴(yán)重的安全問題而言，容器與虛擬機(jī)的安全水平大致相當(dāng)。博頓利認(rèn)為，“事實(shí)上完全有可能出現(xiàn)比虛擬機(jī)管理程序更加安全的容器解決方案，而這將給兩種技術(shù)誰更安全的爭論徹底劃上句號。”為了弄清二者在惡意應(yīng)用面前的暴露水平，可能需要采用某種類型的模糊測試。

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