MCS：多容器隔離的關鍵
MCS（Multi-Category Security） 是 targeted 政策中用來區隔「同一個 type、但不同實例」的機制，最常見的應用就是容器。每個容器執行時會被分配一組獨立的分類標籤，例如 s0:c52,c144：
ls -Z /var/lib/containers/storage/...
容器 A 的程序是 s0:c52,c144，容器 B 是 s0:c100,c200，即使兩者的 type 相同（都是 container_t），MCS 規則仍會阻止容器 A 存取標記為容器 B 分類的檔案——這就是「同一台主機上的容器彼此隔離」的重要防線之一。
容器掛載 Volume 的 Context 問題
延續第四章的 :Z / :z：當你看到容器內程式回報「Permission denied」，但 ls -l 看到的 Unix 權限完全正常時，先用：
ls -Z /path/on/host
確認該路徑的 type 與 MCS 分類，是否符合容器執行時被分配到的分類。多數情況下，重新用 :Z/:z 掛載，或對該路徑執行 chcon/restorecon，就能解決問題。
自訂政策模組的撰寫方式
除了 audit2allow 自動產生，也可以手動撰寫 .te（Type Enforcement）檔案，用 checkmodule、semodule_package 編譯後安裝。這部分屬於進階主題，建議先熟悉前面章節的工具，真的有客製化需求時再深入研究 SELinux Policy 開發文件。
最佳實務整理
- 不要圖方便就
setenforce 0或SELINUX=disabled：先用 Permissive 模式蒐集足夠的稽核紀錄，分析後再切回 Enforcing - 優先順序：能用 Boolean 解決就不要寫客製化政策；能用
restorecon還原就不要手動chcon semanage fcontext規則要寫對範圍：避免規則過於寬鬆（例如整個/都套用某個 type）- 容器環境：善用
:Z/:z，並理解 MCS 分類是容器隔離的重要機制，不要為了省事而把容器設成特權模式（--privileged）跳過 SELinux 檢查
與其他主題的關聯
SELinux 常常跟「使用者與權限管理」（Linux 基礎入門）、「容器的資料與網路管理」（Podman / Docker 基礎入門）一起出現。當你發現一個問題同時牽涉到 Unix 權限、容器掛載、SELinux context 三者時，建議按照「DAC 權限 → SELinux context → SELinux Boolean/Policy」的順序逐一排查，會比較有條理。