本文介紹了構建受 LSM 保護的容器所需的工具，但還有很多工作需要做：
對於 Smack，必須選擇需要標記為 host 的文件。
對於 SELinux，應該對其進行調優，然後將一個 container 接口放置到上游引用策略。
盡管這些工作正在進行當中，在獲得更多關於受 LSM 保護的容器的經驗之前，您不應該完全信賴這些機制來阻止不可信的根用戶。
盡管目前在創建容器方面還沒有最佳實踐，但仍然有一些想法是值得考慮的。首先，記住您正試圖實現兩個有些矛盾的目標：最小化容器（以及主機）之間的復制，同時需要確保安全隔離。實現這些目標的方法之一是，創建一個最小的完整 rootfs，其中不運行任何容器，並且將它的類型標記為所有容器都可以讀取的類型。然後使用 lxc-sshd 腳本的定制版本創建每個基於原型的實際容器，以為容器的大部分文件系統創建只讀裝載，同時為容器提供一個可以存儲文件的私有可寫位置（比如 /scratch）。由於每個容器都有一個私有的裝載名稱空間，所以它能夠綁定裝載任何私有的和/或對於其私有共享目錄可寫的文件或目錄。例如，如果它需要一個私有 /lib，則可以執行 mount --bind /scratch/rootfs/lib /lib。同樣地，管理員也能確保每個容器都在啟動時執行 mount --bind /scratch/shadow /etc/shadow。
對於 SELinux 和 Smack，我演示的這個方法的一個明顯缺點就是容器管理員不能在自己的容器的內部利用 LSM 控制信息流。並且為簡單起見，容器中的所有任務都使用 MAC 策略統一處理。在另一篇文章中，我將探討如何允許容器管理員指定自己的 LSM 策略，同時又能夠約束它們。
安全 Linux 容器實現指南
輕量級容器 又稱作 Virtual Private Servers (VPS) 或 Jails，它們是經常用於限制不可信應用程序或用戶的工具。但是最近構造的輕量級容器沒有提供充分的安全保證。使用 SELinux 或 Smack 策略增強這些容器之後，就可以在 Linux 中實現更加安全的容器。本文介紹如何創建受 Linux 安全模塊保護的更加安全的容器。SELinux 和 Smack 策略的開發都在進行當中，並且在各自社區的幫助下不斷得到改善。
人們聽到容器時的第一反應是 “如何才能創建安全的容器？”。本文通過使用 Linux 安全模塊（Linux Security Modules，LSM）增強容器的安全性來解決這個問題。本文特別演示了如何設定安全目標，並通過 Smack 和 SELinux 安全模塊實現目標。
要了解 Linux 容器的背景知識，請閱讀 “linux.chinaitlab.com/administer/777960_2.html" target=_blank>LXC：Linux 容器工具”（developerWorks，2009 年 2 月）。
Linux 容器是根據幾種 Linux 技術構建的概念性工件：
資源名稱空間 允許在容器內部查找進程、文件、SYSV IPC 資源、網絡接口等等。
控制組（Control groups）允許限制放置到容器中的資源。
功能綁定（Capability bounding）設置 限制容器的訪問特權。
必須協調使用這些技術，以實現符合設想的容器。目前已有兩個項目提供這個功能：
Libvirt 是能夠使用 Xen 管理程序、qemu 模擬器、kvmis 甚至是輕量級容器創建虛擬機的大型項目。
Liblxc 是一個較小的庫和用戶空間命令集合，它們的目的之一是幫助內核開發人員快速輕松地測試容器的功能。
因為 “LXC：Linux 容器工具” 是基於 liblxc 編寫的，所以我在這裡繼續使用 liblxc；不過這裡完成的操作也能夠使用 libvirt 的容器支持輕松完成。
主要元素 1：LSM
在開始之前，如果不太了解 LSM，現在可以快速浏覽一下。根據 Wikipedia 中的定義：Linux Security Modules (LSM) 是一個允許 Linux 內核支持各種計算機安全模型的框架，同時也避免依賴於特定安全實現。這個框架由 GNU General Public License 條款授權使用，並且是 Linux 2.6 之後的 Linux 內核的標准部分。設計 LSM 的目的是為成功實現強制訪問控制模塊提供一切必要元素，同時最小化對 Linux 內核的更改。LSM 避免了 Systrace 中的系統調用插入，因為它不支持多處理器內核，並且容易受 TOCTTOU (race) 攻擊。相反，當某個用戶級別的系統將要訪問重要的內部內核對象（比如 inode 和任務控制塊）時，LSM 將在內核中插入 “鉤子（hook）”（向上調用模塊）。這個項目專門用於解決訪問控制問題，以避免對主流內核進行大量的復雜修改。該項目並不打算成為通用的 “鉤子” 或 “向上調用” 機制，也不支持虛擬化。LSM 訪問控制的目標與解決系統審計問題密切相關，但又有所區別。審計要求記錄每次訪問嘗試。LSM 不能解決這個問題，因為這需要大量的鉤子，以檢測內核 “短路” 故障系統在什麼地方發出調用，並在接近重要對象時返回錯誤代碼。
