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)，“采用精心設計的安全計算模式（seccomp）配置文件（用于阻止意外系統(tǒng)調(diào)用）的Docker容器提供了與虛擬機管理程序大致相當?shù)陌踩?。?/p>

垂直攻擊配置文件VAP

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

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)進行衡量時不可采取這樣的假設，但幸運的是 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)（無論它是裸機、虛擬機還是容器）運行某個特定應用程序使用了多少行代碼。其運行的代碼越多，存在HAP級別的安全漏洞的可能性就越大。

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

redis-bench-set；

redis-bench-get；

python-tornado；

node-express。

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

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

Docker；

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

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

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

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

博頓利發(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)。”

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ù)誰更安全的爭論徹底劃上句號?！睘榱伺宥咴趷阂鈶妹媲暗谋┞端剑赡苄枰捎媚撤N類型的模糊測試。

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