安全增強式 Linux（SELinux，SecurityEnhanced Linux）是一個 Linux 核心的安全模組，其提供了訪問控制安全策略機制，包括了強制訪問控制（Mandatory Access Control，MAC）。 SELinux 是一組核心修改和使用者空間工具，已經被新增到各種 Linux 發行版中。其軟體架構力圖將安全決策的執行與安全策略分離，並簡化涉及執行安全策略的軟體的數量。SELinux 的核心概念可以追溯回美國國家安全域性（NSA）的一些早期專案。 概覽 美國國家安全域性的安全增強式 Linux 團隊稱： 安全增強式 Linux 是一組給 Linux 核心的修補程式，並提供一些更強、更安全的強制存取控制架構來和核心的主要子系統共同運作。基於機密及完整性原則，它提供一個架構來強制資訊的分離，以對付入侵的威脅或任何企圖略過安全架構的應用程式。藉此限制惡意或設計不良的程式可能造成的破壞。它包含一組安全性原則組態設定檔的範本以符合一般的安全性目標 整合 SELinux 的 Linux 核心將執行限制使用者程式和系統伺服器訪問檔案與網路資源的強制訪問控制策略。將許可權限制到最小以減少或完全清除程式和守護程序在失效或出錯的情況（如快取區溢位或錯誤配置）下對系統造成危害的可能性。此種限制機制獨立與於傳統的 Linux 自主訪問控制（Discretionary Access Control DAC）進行。SELinux 沒有 root 使用者的概念，也沒有傳統 Linux 安全機制的缺點。（如依賴於 setuid 庫） 未修改過的 Linux 系統安全性（即未整合 SELinux 的系統）依賴於核心、授權應用與其配置的正確性。三者中任意一個發生問題都將有可能導致整個系統被破解。相反，修改過的 系統安全性（基於 SELinux 核心）主要基於其核心和配置的正確性。雖然當應用程式的正確性或配置出現問題可能會導致獨立的使用者程式和系統守護程序發生有限破解，但是它們並不會對其他使用者程式和系統守護程序或整個系統的安全性造成威脅。 純粹來看，SELinux 提供了一個從強制訪問控制、強制完整性控制、以角色為基礎的存取控制和提取出的概念與功能的混合體。第三方工具可以使開發者構建多種安全策略。 歷史 早期工作主要指向在 UNIX 計算環境（準確而言是 POSIX）下標準化強制和自主訪問控制條款的方法。這歸因於美國國家安全域性受信 UNIX（TRUSIX）工作組，他們在 1987 到 1991 年間接觸併發布了一本 （020A），並製造了一個原初模型和最初未釋出的關聯評估證據原型（020B）。 SELinux 最初設計向 Linux 社群展示強制訪問控制的價值和這些控制加入 Linux 的方法。起初，組成 SELinux 的補丁只能透過明確新增在 Linux 核心原始碼中來工作；在 26 系列的 Linux 核心中 SELinux 已被整合入。 作為最初 SELinux 的主要開發者，美國國家安全域性於 2000 年 12 月 22 日基於 GNU 通用公共許可證發行了第一版 SELinux 給了開放原始碼開發社群。比較 SELinux 隨後被整合進了 Linux 核心 260test3 版本的主分支，並在 2003 年 8 月 8 日釋出。其他的顯要貢獻者有紅帽公司、邁克菲、、特瑟思科技（Tresys Technology）和可信計算機解決方案（Trusted Computer Solutions）。TE 實現透過 FreeBSD 專案成功移植到了 FreeBSD 和 Darwin 作業系統上。 SELinux 實現了。這種核心包含了以為原型的架構部件。這些提供給了強制執行多種強制訪問控制策略許多通常支援，包括了基於、以角色為基礎的存取控制和概念的策略。FLASK 基於馬赫衍生的（Machderived）（DTOS）和來自對 DTOS 的設計和實現有著影響的的一個研究專案 受信馬赫（Trusted Mach）。 使用者、策略和安全上下文 SELinux 使用者和角色不需要與實際系統使用者與角色相關。對每個正在進行的使用者或程序，SELinux 分配一個三字串上下文，包含了使用者名稱、角色和域（或者型別）。此係統比通常所需要的系統更靈活：作為規定之一，大多數真實使用者享有著相同的 SELinux 使用者名稱，且所有的訪問控制都經由第三個標籤 域來進行。在一個程序被允許進入域的情況下必須在策略中配置。命令 runcon 允許啟動程序進入一個顯性定義上下文（使用者、角色和域）環境中，但如果政策中未允許的話那麼 SELinux 可能會拒絕此請求。 檔案、網路埠和其他硬體均有可能含有 SELinux 上下文，由一個名字、角色（不常使用）和型別組成。檔案系統在檔案和安全上下文之間的對映被稱為標記（Labeling）。標記在策略檔案中被定義但也可以在不更改策略的情況下手動調整。硬體型別十分詳細，比如 bin_t（顯示 bin 下的所有檔案）或 postgresql_port_t（PostgreSQL 埠 5432）。遠端檔案系統的 SELinux 上下文可以在被掛載時顯性定義。 SELinux 給 Shell 命令 ls、ps 等中添加了 Z 開關使得檔案或程序的安全上下文可見。 典型的政策規則包含了顯性許可權；使用者必須擁有哪些域才能用給定目標進行特定的行為（讀、執行，網路埠中則是繫結或連線）等等。也可以進行更多複雜的對映，包括在角色級和安全級進行。 一個典型的策略包含了一個對映檔案（標記）檔案、一個規則檔案和一個定義域過渡的介面檔案。這三個檔案必須被同時使用 SELinux 工具編譯來生成單一的策略檔案。生成的策略檔案可以被載入到核心中並工作。載入和解除安裝策略並不需要重啟。策略檔案既有可能是手打也可能是用容易使用的 SELinux 管理工具生成。它們通常先在允許模式（Permissive Mode）下測試，在此模式下違反策略的行為都將被記錄但被允許。audit2allow 工具可以隨後使用來生成擴充套件 SELinux 策略以允許受限應用的合法活動的附加規則。 特性 SELinux 特性包含了： 在執行情況下將策略完全分離 定義充分的策略介面 支援問詢策略並執行訪問控制的應用程式（例如 Cron 在正確的上下文環境中執行工作） 獨立於特定政策和策略語言 獨立於特定安全標籤格式與內容 對核心目標和服務的獨立標記 支援策略更改 分離保護系統完整性（域名類）和資料保密的措施 靈活的策略 控制程序初始化與繼承和程式執行 控制檔案系統、目錄、檔案和開放性檔案描述符 控制套接字、資訊和網路介面 控制使用 容量（Capabilities） 在訪問決定中透過訪問向量快取（Access Vector Cache AVC）預快取資訊 實現 SELinux 透過 Red Hat Enterprise Linux 第四版及其所有未來的發行版中的商業支援得以可用。它的存在也在對應版本的 CentOS 和 Scientific Linux 中呈現。RHEL4 中所支援的策略目標為最大化簡易使用程度而並沒有它能成為的那樣有約束性。RHEL 的未來版本準備將在目標策略中寫入更多的目標，也就意味著有更多的限制策略。SELinux 在 Android43 版本中就已得以實現。 在自由社群所支援的 GNULinux 發行版中，Fedora 作業系統 Fedora 是最早採用 SELinux 的，在 Fedora Core 2 中就已預設包含了對其的支援。其他發行版中，Debian 在 Etch 發行版中包含了對它的支援，Ubuntu 則在 804 版代號堅強的蒼鷺（Hardy Heron）中加入。截止 openSUSE 版本 111 中，它包含了 SELinux 的 基礎實現。 SUSE Linux Enterprise 11 將 SELinux 作為 技術預覽。 SELinux 在基於的系統中流向，比如 CoreOS 和 rkt。其作為額外的安全控制來幫助隔離容器和它們的主機十分有用。 使用情形 SELinux 可以潛在地透過詳細的引數來控制允許系統每個使用者的活動、程序以及守護程序。但是，它主要用於限制守護程序比如被更顯著定義資料訪問和活動許可權的資料庫引擎或者網頁伺服器。這限制了被破解的限制守護程序的潛在危害。普通的使用者程序通常運行於受限域中，不被 SELinux 所限制但被經典 Linux 訪問許可權所限制。 命令列工具包含： chcon restorecon restorecond runcon secon fixfiles setfiles load_policy booleans getsebool setsebool togglesebool setenforce semodule postfixnochroot checkselinuxinstallation semodule_package checkmodule selinuxconfigenforcing selinuxenabled 及 selinuxpolicyupgrade 示例 將 SELinux 設定為強制模式（Enforcing Mode）： sudo setenforce 1 查詢 SELinux 狀態： getenforce 與 AppArmor 的對比 SELinux 代表了多個可能解決限制安裝軟體活動的方法之一。另外一個受歡迎的替代品被稱為 AppArmor，它在（SLES）、OpenSUSE 和其他 Linux 平臺中可用。AppArmor 原初是作為現不存在的平臺元件之一開發的。由於 AppArmor 和 SELinux 大相徑庭，它們產生了兩種完全不同的軟體訪問限制軟體。雖然 SELinux 重新提出了特定的概念以提供更豐富的策略選擇表達集，但 AppArmor 透過擴充套件用於自主訪問控制級的特定相同自主訪問控制管理語言設計來簡化其使用。 它們之間存在幾個顯著的不同： 一個重要的區別是，AppArmor 透過路徑名而非 inode 識別目標檔案。這意味著在 AppArmor 下，一個不可訪問的檔案可以透過建立硬連結得以訪問（此時檔案路徑產生變化，而 inode 不變）；而在 SELinux 下，即使透過建立了硬連結改變檔案路徑，訪問也會被阻止。 結果，AppArmor 可被稱為不是一個型別強制系統，因為檔案並沒有被分配型別；相反，它們僅僅在配置檔案中被引用。 SELinux 和 AppArmor 在管理和整合系統的方面存在著極大的不同。 由於其尋求使用強制訪問控制級執行來重建傳統的自主訪問控制，AppArmor 的一系列操作也認為比大多數 SELinux 實現要小得多。例如，AppArmor 的一系列操作包含了：讀、寫、附加、執行、鎖定和連結。大多數的 SELinux 實現將支援一系列多於其的操作序列。比如，SELinux 通常支援相同許可權，但同時對於 mknod 包含了控制、繫結到網路包、隱性使用 POSIX 的能力、載入並解除安裝核心模組和多種訪問共享記憶體的方法等。 AppArmor 沒有能明確限制 POSIX 功能的控制項。由於當前功能實現的方法不包含操作主題的概念（只有執行者和操作本身），防止執行者外的強制控制領域（即沙箱）授權檔案操作通常由 MAC 層完成。AppArmor 可以防止其策略被更改和檔案系統被掛載 解除安裝，但不能防止使用者踏出他們的控制域。 例如，人們通常認為桌面員工更改他們所不擁有的特定檔案（例如：部門檔案共享）的所有權或許可權是有益的。你絕對不會想給使用者機器的 root 許可權，所以你會給他們 CAP_FOWNER 或 CAP_DAC_OVERRIDE。在 SELinux 下，管理員或平臺供應商可以透過配置 SELinux 禁止所有其他未受限使用者的能力，然後新建一個給員工的受限域以在登陸後進行過渡。這種情況可以給員工修改許可權的能力，但僅限於合適型別的檔案。 AppArmor 沒有多層安全的概念，因此也沒有硬性的或強制執行。 AppArmor 的配置透過唯一常規平面檔案完成。SELinux（在大多數實現中為預設）則使用平面檔案組合（在編譯前由管理員和開發者編寫人類可讀的策略）和擴充套件屬性完成。 SELinux 支援作為策略配置替代源的 遠端策略伺服器 概念（可在 etcselinuxsemanageconf 中配置）。AppArmor 的中心化管理通常十分複雜，這是因為管理員必須決定策略部署工具以 root 許可權執行（以允許策略更新）或在每臺伺服器上手動配置。 相似系統 孤立程序也可以透過類似作業系統層虛擬化的機制實現；比如在 OLPC 專案的首次實現中它使用了沙盒技術在輕量的環境中隔離獨立的應用程式。同樣美國國家安全域性也在安全增強型 Android 中採用了一些 SELinux 概念。 參見 參考文獻 外部連結 NSA SecurityEnhanced Linux at NSA Mailing list CategoryLinux 核心功能 CategoryLinux 安全軟體 Category 美國國家安全域性 Category 紅帽軟體 CategoryUnix 檔案系統技術