上個月在Linux安全峰會上的演講，介紹了LXD在容器安全方便存在的問題。LXD是Canonical基于Linux容器（LXC）開發的容器管理程序。Stéphane Graber和Tycho Andersen的議題討論了一些問題的細節。

LXD不是一種新的虛擬化技術，而是一個利用LXC特性的工具。LXC使用由內核提供的名字空間（namespace）和控制組（control groups, cgroups）特性來實現。因此，它使用名字空間API提供的安全功能。

LXD中廣泛使用了cgroups來實施資源配額，對容器的CPU、內存交換、磁盤和網絡流量進行限制。這也使得任何因為共享內核資源引起的問題，會影響到所有運行中的容器。其中一個示例是用于追蹤文件系統變動的inotify句柄。該資源的全局限制是每個用戶512個，這意味著主機上所有運行的容器最多能使用512個句柄。這對于像systemd這樣的應用程序來說是遠遠不夠的。當systemd因為inotify句柄不足退而使用輪訓文件系統時，對系統影響會更大。其他類似的資源還包括網絡表（例如用于保存路由項）和ulimit。

對于上述問題中的一部分，建議的解決方案是虛擬化存在限制的環境，例如將限制綁定到名字空間，使其成為容器的局部屬性。然而，對于類似ulimit這樣的屬性，目前還不完全清楚哪個名字空間比較適合。

LXD以root特權的守護進程運行，這意味它比LXC擁有更多的特權。LXD確實從其容器中移除了一些功能，例如加載/卸載內核模塊，但是保留了大部分功能，因為它無法提前預知容器中運行的應用程序需要哪些功能。

Linux安全模塊（Linux Security Modules, LSM）是一個Linux框架，它允許插入一個安全模塊的實現，在不依賴特定模型的情況下來執行訪問控制。LSM的實現有AppArmor和SELinux。LXC同時支持AppArmor和SELinux，而LXD目前只支持AppArmor。LXD容器的首選隔離方案是名字空間，但是也安裝了一個AppArmor配置文件以避免跨容器訪問資源（例如文件）。

演講的第二部分覆蓋了容器的檢查點和恢復功能。檢查點和恢復進程保存運行中的容器內存狀態，并允許在將來的某個時間點恢復回來。檢查點/恢復功能的技術涉及到通過類似ptrace系統調用來深入獲取進程的狀態。然而，類似seccomp這樣的安全措施可能會阻止類似的系統調用，因此檢查點功能需要特別的處理。

查看英文原文：Security Insights into the LXD Container Hypervisor