BlackBox:在不受信任的系統上保護容器安全
論文地址:http://www.usenix.org/system/files/osdi22-vant-hof.pdf
這篇論文使用了硬件虛擬化對容器進行隔離,從而實現了輕量化的容器隔離與安全加強。文章的核心想法並不新奇,有很多類似的工作採用了虛擬化以及VMFUNC做內存隔離。其核心的貢獻點,在於能夠支持未經修改Docker應用,以及對syscall的支持較為完整。由此可見,Solid的工作也是會受到PC們的青睞。
背景
容器作為共享計算的基礎設施,被廣泛地運用在應用程序的部署,打包與應用隔離中。相較於虛擬機的方式,容器所需要的資源更加少,有更好的啟動性能與IO的性能。但是,容器以來與特權OS作為安全的保障,然後以Linux為代表的商用OS代碼量大,複雜存在很多攻擊的漏洞。攻擊者可以通過攻擊OS從而實現對容器中數據和內容的攻擊。
近幾年也有不少的工作,通過不同的軟硬件機制,對容器的安全進行加強。例如,基於硬件Enclave的方式對容器中的代碼和數據進行強隔離,但是需要應用開發者重寫代碼,並且會引入較高的CPU計算的開銷。而基於虛擬化的方式,也會增加虛擬化的開銷同時引入guest OS的代碼擴大的TCB。因此當前缺少一種輕量化的安全容器方案。
設計
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4bae6704e28237be11306c5bc7d31255f19339783ec4a160833197a7a5aad56e92.jpg)
為了實現輕量級安全容器,作者提出了BlackBox的設計,它能夠提供細粒度的內存隔離,同時保護容器的完整性和機密性,並且不需要相信OS。如上圖所示,在BlackBox中引入了一個新的安全監視器:container security monitor (CSM), 它負責提供一個受保護的內存空間protected physical address space(PPASes),保證所有外部的代碼無法訪問受保護的內存地址中的數據,同時內部的代碼也無法訪問其他的PPASes空間。
BlackBox重用了虛擬化技術,只用於對內存的隔離,而不需要做任何虛擬化相關的工作,從而極大減少了TCB的大小(不需要GuestOS的介入)。BlackBox不需要修改容器中運行的應用程序。應用程序和OS之間的交互會受到CSM的檢查(例如系統調用,中斷和異常),如果一個受保護的容器需要切換到OS中運行,CSM會將所有與容器相關的寄存器保存並清零;反之,CSM會恢復容器的上下文,並且給予其訪問對應PPAse的權限。其中syscall的參數是唯一一個容器內的內容需要被OS訪問。CSM會將syscal的參數拷貝到OS的內存中,同時對IO的數據進行端到端的加密。為了保證沒有惡意的代碼運行在容器中,所有加載到容器中的代碼,都需要容器的提供者簽名並且加密,由CSM負責解密並加載。
內存隔離
CSM保證OS無法直接訪問容器中的內存,為了減少CSM的TCB,CSM允許OS進行內存分配。但是與此同時,需要防止OS發起基於內存的Iago攻擊。例如用户希望通過mmap得到一塊沒有被使用過的內存,但是OS可能返回一個棧地址空間,導致棧上的數據被覆蓋重寫。
![](http://mdimg.wxwenku.com/getimg/6b990ce30fa9193e296dd37902816f4b90f6dd8660544607f56daf5837c28d995a767107df872ea4f0376ef725a5584e.jpg)
為了解決這個問題,BlackBox不允許OS直接修改容器的頁表,而需要CSM介入。CSM會對頁表修改的操作做兩個檢查:
(1)所有映射的虛擬地址是一個合法的地址;
(2)映射的物理地址不在容器所有的PPAS中。
除此之外,BlackBox還提供額外的接口允許OS以CoW的方式獲得container中內存數據,但是需要經過CSM的額外的安全檢查;同時BlackBox也支持動態的內存回收。
很多系統調用會需要傳遞內存數據,在BlackBox中採用了和OS共享的緩存,作為系統調用源內存地址。CSM會將需要傳遞的內存數據拷貝到該緩存區中。對於系統調用的返回值,CSM也會做檢查,保證所有的返回值落在預定義的返回值區間內。
進程間通信
類似於pipe以及Unix socket這類system cal允許實現進程間通信。當container想要和外部通信前,會將需要傳遞的數據加密並拷貝到syscall的共享內存中。數據的加密傳輸同樣應用在read/recvmsg這類調用時。在實現IPC的時候,需要使用futex進行同步保護,因為futex需要OS和container共享同一個futex的標記,所以CSM提供了一個新的CSM call允許OS通過該接口讀取在container中存儲的futex標記。同時,還需要實現通知的機制,BlackBox採用了signal的機制,但是由於OS需要創建一個signal的棧,所以在創建的時候,OS將signal的棧建立在PPAS之外,當處理signal的時候,CSM會將signal的棧移到PPAS之中。當signal執行結束之後,再將signal的棧移到PPAS之外。
容器的文件系統
為了減少TCB,BlackBox讓應用加密保護敏感的數據,並且允許OS加載加密的二進制文件並且正常執行。
實驗
作者在兩個Arm的平台:Raspberry Pi 4 Model B with a 4-core Cortex-A72以及AMD Seattle Rev.B0 server with an 8-core Cortex-A57 64-bit ARMv8-A 2 GHz AMD Opteron A1100 SoC進行的測試。比較了BlackBox和docker之間的性能。作者選擇了四個比較的對象(以native沒有采用容器隔離作為baseline):
(1)Docker以及未經修改了Linux容器;
(2)BlackBox以及未經修改的Linux容器,但使能了NPT;
(3)BlackBox使用CSM對容器進行管理,但是沒有使能加密IPC;
(4)BlackBox採用了CSM以及加密的IPC等。
![](http://mdimg.wxwenku.com/getimg/356ed03bdc643f9448b3f6485edc229b8884721ea0492248b1f8178575977f296bd3321ed259878df972ab250e582a1e.jpg)
測試結果:
null syscall上BlackBox雖然會導致一定的overhead,但是主要的開銷在seccomp做的syscall過濾。而CSM call在Arm的架構上因為有獨自的EL2的寄存器,所以開銷只在於存儲與恢復通用寄存器,因此不是主要的開銷。
讀和寫會造成小於兩倍的開銷,因為需要將讀寫的內容先拷貝到共享的syscall緩存中。Fork會造成小於三倍的開銷,因為在exec的時候會調用mmap需要進行額外的檢查,同時加載的binary需要經過解密。
加密的IPC在大多數的場景中的開銷都比較小,但是在pipe, UNIX socket等IPC機制中的開銷非常的明顯。當然,這部分開銷也是顯而易見的,因為需要對傳輸的數據進行加解密保護。
作者在memcached, MySQL, and Nginx這些應用上測試結果表明,在真實應用上BlackBox的開銷小於15%
總結
該論文采用的方法:NPT對內存進行隔離,以及一個安全monitor對容器和OS之間的交互進行保護,都是非常成熟的技術。同時在測試部分,也只是和docker進行了比較,沒有和其他安全容器的技術進行比較,在部分benchmark上的性能相較於其他方式,並沒有明顯的提高。
Q&A
Q1:因為BlackBox假設OS是不可信,如何保證運行在OS之下的CSM是可信的呢?
A1:我們認為系統的啟動是可信的,我們通過安全啟動的方式驗證CSM代碼的完整性
Q2:有提供運行時驗證的機制嗎?開發者如何知道,應用程序被安全並完整地加載到了BlackBox之中?
A2:應用程序會被開發者加密,在加載的時候有CSM解密,並且檢驗其完整性。
推薦
隨手關注或者”在看“,誠摯感謝!
- BlackBox:在不受信任的系統上保護容器安全
- 中間件的過去、現在和未來
- 為什麼我們選擇 Thanos 進行長期指標存儲?
- 如何在 Kubernetes 中運行不受信任的容器
- 論如何解決學習通被拖庫導致的數據泄漏問題
- 高效應用程序必須配置的7個JVM參數
- 主備|彈性|多活,如何正確的選擇多雲架構?
- Istio 已經遠遠超越 SpringCloud、dubbo等傳統開發框架
- 搞搞 Prometheus 的吿警原理
- 使用 Cilium 服務網格的下一代相互身份驗證
- 如何保護K8S中的Deployment資源對象
- 徹底搞懂 K8S Pod Pending 故障原因及解決方案
- CVE-2022-0492:權限提升漏洞導致容器逃逸
- 如何更安全的升級Kubernetes節點
- Kubernetes 集羣需要重點關注的 6 個指標
- Kubernetes 集羣零信任訪問架構設計
- 微服務架構與 gRPC 和 REST 的集成挑戰
- 如何檢測分佈式系統中的故障節點
- Cluster out:一種構建現代應用程序的設計方法
- Fail-fast | 一種可靠的軟件設計策略