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。因此當前缺少一種輕量化的安全容器方案。

設計

為了實現輕量級安全容器，作者提出了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可能返回一個棧地址空間，導致棧上的數據被覆蓋重寫。

為了解決這個問題，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等。

測試結果：

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解密，並且檢驗其完整性。

推薦

中間件的過去、現在和未來

論如何解決學習通被拖庫導致的數據泄漏問題