BlackBox：在不受信任的系統上保護容器安全
論文地址：https://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 解密，並且檢驗其完整性。
雲原生技術愛好者社區 雲原生技術愛好者、發佈 docker、Kubernetes、Service Mesh 相關文章、思考和見解，關注雲原生生態。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/azKZ20lfRnaqly4djUvtJg