跳至內容

安全增強式Linux

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
安全增強式Linux
Fedora 8中的SELinux管理介面
Fedora 8中的SELinux管理介面
原作者NSA與Red Hat
開發者Red Hat
首次發布1998年1月1日，​26年前​（1998-01-01）
目前版本3.4（2022年5月18日，​2年前​（2022-05-18）[1]）
原始碼庫
編輯維基數據鏈結
程式語言C
作業系統Linux
類型安全性、 Linux安全模組 （LSM）
許可協定GNU GPL
網站SELinuxProject.org/page/Main Page

安全增強式Linux（SELinux，Security-Enhanced Linux）是一個Linux核心的安全模組，其提供了訪問控制安全策略機制，包括了強制訪問控制（Mandatory Access Control，MAC）。

SELinux是一組核心修改和使用者空間工具，已經被添加到各種Linux發行版中。其軟體架構力圖將安全決策的執行與安全策略分離，並簡化涉及執行安全策略的軟體的數量。[2][3]SELinux的核心概念可以追溯回美國國家安全局（NSA）的一些早期專案。

概覽

美國國家安全局的安全增強式Linux團隊稱：[4]

安全增強式Linux是一組給Linux核心的修補程式，並提供一些更強、更安全的強制存取控制架構來和核心的主要子系統共同運作。基於機密及完整性原則，它提供一個架構來強制資訊的分離，以對付入侵的威脅或任何企圖略過安全架構的應用程式。藉此限制惡意或設計不良的程式可能造成的破壞。它包含一組安全性原則組態設定檔的範本以符合一般的安全性目標

整合SELinux的Linux核心將執行限制使用者程式和系統伺服器訪問檔案與網路資源的強制訪問控制策略。將權限限制到最小以減少或完全清除程式和守護行程在失效或出錯的情況（如快取區溢位或錯誤組態）下對系統造成危害的可能性。此種限制機制獨立與於傳統的Linux自主訪問控制（Discretionary Access Control, DAC）進行。SELinux沒有「root」使用者的概念，也沒有傳統Linux安全機制的缺點。（如依賴於setuid/setgid（英語：setgid）庫）

「未修改過的」Linux系統安全性（即未整合SELinux的系統）依賴於核心、授權應用與其組態的正確性。三者中任意一個發生問題都將有可能導致整個系統被破解。相反，「修改過的」系統安全性（基於SELinux核心）主要基於其核心和組態的正確性。雖然當應用程式的正確性或組態出現問題可能會導致獨立的使用者程式和系統守護行程發生有限破解，但是它們並不會對其他使用者程式和系統守護行程或整個系統的安全性造成威脅。

純粹來看，SELinux提供了一個從強制訪問控制、強制完整性控制、以角色為基礎的存取控制和類型強制架構（英語：type enforcement architecture）提取出的概念與功能的混合體。第三方工具可以使開發者構建多種安全策略。

歷史

早期工作主要指向在UNIX計算環境（準確而言是POSIX）下標準化強制和自主訪問控制條款的方法。這歸因於美國國家安全局受信UNIX（TRUSIX）工作群組，他們在1987到1991年間接觸並發布了一本彩虹書 （#020A），並製造了一個原初模型和最初未發布的關聯評估證據原型（#020B）。

SELinux最初設計向Linux社群展示強制訪問控制的價值和這些控制加入Linux的方法。起初，組成SELinux的修補程式只能通過明確添加在Linux核心原始碼中來工作；在2.6系列的Linux核心中SELinux已被整合入。

作為最初SELinux的主要開發者，美國國家安全局於2000年12月22日基於GNU通用公共許可證發行了第一版SELinux給了開放原始碼開發社群。[5]

SELinux隨後被整合進了Linux核心2.6.0-test3版本的主分支，並在2003年8月8日發布。其他的顯要貢獻者有紅帽公司、邁克菲、安全計算公司（英語：Secure Computing Corporation）、特瑟思科技（Tresys Technology）和可信電腦解決方案（Trusted Computer Solutions）。FLASK（英語：FLASK）/TE實現通過FreeBSD專案成功移植到了FreeBSD和Darwin作業系統上。

SELinux實現了通量進階安全核心（英語：FLASK）。這種核心包含了以錨爪作業系統（英語：Fluke operating system）為原型的架構部件。這些提供給了強制執行多種強制訪問控制策略許多通常支援，包括了基於類型強制（英語：type enforcement）、以角色為基礎的存取控制和多層安全（英語：multilevel security）概念的策略。FLASK基於馬赫衍生的（Mach-derived）分散式受信作業系統（英語：Distributed Trusted Operating System）（DTOS）和來自對DTOS的設計和實現有著影響的受信資訊系統（英語：Trusted Information System）的一個研究專案——受信馬赫（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在正確的上下文環境中執行工作）
  • 獨立於特定政策和策略語言
  • 獨立於特定安全標籤格式與內容
  • 對核心目標和服務的獨立標記
  • 支援策略更改
  • 分離保護系統完整性（域名類）和資料保密（多層安全（英語：multilevel security））的措施
  • 靈活的策略
  • 控制行程初始化與繼承和程式執行
  • 控制檔案系統、目錄、檔案和開放性檔案描述子
  • 控制通訊端、資訊和網路介面
  • 控制使用「容量」（Capabilities）
  • 在訪問決定中通過訪問向量快取（Access Vector Cache, AVC）預快取資訊[6]

實現

SELinux通過Red Hat Enterprise Linux第四版及其所有未來的發行版中的商業支援得以可用。它的存在也在對應版本的CentOS和Scientific Linux中呈現。RHEL4中所支援的策略目標為最大化簡易使用程度而並沒有它能成為的那樣有約束性。RHEL的未來版本準備將在目標策略中寫入更多的目標，也就意味著有更多的限制策略。SELinux在Android4.3版本中就已得以實現。[7]

在自由社群所支援的GNU/Linux發行版中，Fedora (作業系統)Fedora是最早採用SELinux的，在Fedora Core 2中就已預設包含了對其的支援。其他發行版中，Debian在Etch發行版中包含了對它的支援[8]，Ubuntu則在8.04版代號堅強的蒼鷺（Hardy Heron）中加入。[9]截止openSUSE版本11.1中，它包含了SELinux的「基礎實現」。[10] SUSE Linux Enterprise 11將SELinux作為「技術預覽」。[11]

SELinux在基於Linux容器（英語：linux containers）的系統中流向,比如CoreOS和rkt。[12]其作為額外的安全控制來幫助隔離容器和它們的主機十分有用。

使用情形

SELinux可以潛在地通過詳細的參數來控制允許系統每個使用者的活動、行程以及守護行程。但是，它主要用於限制守護行程比如被更顯著定義資料訪問和活動權限的資料庫引擎或者網頁伺服器。這限制了被破解的限制守護行程的潛在危害。普通的使用者行程通常執行於受限域中，不被SELinux所限制但被經典Linux存取權限所限制。

命令列工具包含：[13] chcon,[14] restorecon,[15] restorecond,[16] runcon,[17] secon,[18] fixfiles,[19] setfiles,[20] load_policy,[21] booleans,[22] getsebool,[23] setsebool,[24] togglesebool[25] setenforce, semodule, postfix-nochroot, check-selinux-installation, semodule_package, checkmodule, selinux-config-enforcing,[26] selinuxenabled,[27] 及 selinux-policy-upgrade[28]

範例

將SELinux設定為強制模式（Enforcing Mode）：

$ sudo setenforce 1

查詢SELinux狀態：

$ getenforce

與AppArmor的對比

SELinux代表了多個可能解決限制安裝軟體活動的方法之一。另外一個受歡迎的替代品被稱為AppArmor，它在SUSE Linux Enterprise Server（SLES）、OpenSUSE和其他Linux平台中可用。AppArmor原初是作為現不存在的Immunix Linux（英語：Immunix）平台組件之一開發的。由於AppArmor和SELinux大相逕庭，它們產生了兩種完全不同的軟體訪問限制軟體。雖然SELinux重新提出了特定的概念以提供更豐富的策略選擇表達集，但AppArmor通過擴充用於自主訪問控制級的特定相同自主訪問控制管理語言設計來簡化其使用。

它們之間存在幾個顯著的不同：

  • 一個重要的區別是，AppArmor通過路徑名而非inode辨識目的檔。這意味著在AppArmor下，一個不可訪問的檔案可以通過建立硬連結得以訪問（此時檔案路徑產生變化，而inode不變）；而在SELinux下，即使通過建立了硬連結改變檔案路徑，訪問也會被阻止。
    • 結果，AppArmor可被稱為不是一個類型強制系統，因為檔案並沒有被分配類型；相反，它們僅僅在設定檔中被參照。
  • SELinux和AppArmor在管理和整合系統的方面存在著極大的不同。[29]
  • 由於其尋求使用強制訪問控制級執行來重建傳統的自主訪問控制，AppArmor的一系列操作也認為比大多數SELinux實現要小得多。例如，AppArmor的一系列操作包含了：讀、寫、附加、執行、鎖定和連結。[30]大多數的SELinux實現將支援一系列多於其的操作序列。比如，SELinux通常支援相同權限，但同時對於mknod包含了控制、繫結到網路包、隱性使用POSIX的能力、載入並解除安裝核心模組和多種訪問共享主記憶體的方法等。
  • AppArmor沒有能明確限制POSIX功能的控制項。由於當前功能實現的方法不包含操作主題的概念（只有執行者和操作本身），防止執行者外的強制控制領域（即沙箱）授權檔案操作通常由MAC層完成。AppArmor可以防止其策略被更改和檔案系統被掛載/解除安裝，但不能防止使用者踏出他們的控制域。
    • 例如，人們通常認為桌面員工更改他們所不擁有的特定檔案（例如：部門檔案分享）的所有權或權限是有益的。你絕對不會想給使用者機器的root權限，所以你會給他們CAP_FOWNER或CAP_DAC_OVERRIDE。在SELinux下，管理員或平台供應商可以通過組態SELinux禁止所有其他未受限使用者的能力，然後新建一個給員工的受限域以在登陸後進行過渡。這種情況可以給員工修改權限的能力，但僅限於合適類型的檔案。
  • AppArmor沒有多層安全的概念，因此也沒有硬性的貝爾-拉帕杜拉模型（英語：Bell–LaPadula model）或比巴模型（英語：Biba Model）強制執行。
  • AppArmor的組態通過唯一常規平面檔案完成。SELinux（在大多數實現中為預設）則使用平面檔案組合（在編譯前由管理員和開發者編寫人類可讀的策略）和擴充屬性完成。
  • SELinux支援作為策略組態替代源的"遠端策略伺服器"概念（可在/etc/selinux/semanage.conf中組態）。AppArmor的中心化管理通常十分複雜，這是因為管理員必須決定策略部署工具以root權限執行（以允許策略更新）或在每台伺服器上手動組態。

相似系統

參見：三星Knox

孤立行程也可以通過類似作業系統層虛擬化的機制實現；比如在OLPC專案的首次實現中[31]它使用了沙盒技術在輕量的Vserver（英語：Vserver）環境中隔離獨立的應用程式。同樣美國國家安全局也在安全增強型Android中採用了一些SELinux概念。[32]

參見

參考文獻

  1. ^ Lawrence, Steve. Release. selinux. SELinux Project. 2022-05-18 [2022-05-18]. （原始內容存檔於2021-01-06）. 
  2. ^ SELinux Frequently Asked Questions (FAQ) - NSA/CSS. National Security Agency. [2013-02-06]. （原始內容存檔於2018-09-18）. 
  3. ^ Loscocco, Peter; Smalley, Stephen. Integrating Flexible Support for Security Policies into the Linux Operating System (PDF). February 2001 [2018-02-19]. （原始內容存檔 (PDF)於2018-09-18）. 
  4. ^ Security-Enhanced Linux - NSA/CSS. National Security Agency. 2009-01-15 [2013-02-06]. （原始內容存檔於2019-07-19）. 
  5. ^ 比較 National Security Agency Shares Security Enhancements to Linux. NSA Press Release. Fort George G. Meade, Maryland: National Security Agency Central Security Service. 2001-01-02 [2011-11-17]. （原始內容存檔於2018-02-20）. The NSA is pleased to announce that it has developed, and is making available to the public, a prototype version of a security-enhanced Linux operating system. 
  6. ^ Fedora Documentation Project. Fedora 13 Security-Enhanced Linux User Guide. Fultus Corporation. 2010: 18 [2012-02-22]. ISBN 978-1-59682-215-3. （原始內容存檔於2020-06-08）. SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). Caching decisions decreases how often SELinux rules need to checked, which increases performance. 
  7. ^ Security-Enhanced Linux in Android. Android Open Source Project. [2016-01-31]. （原始內容存檔於2018-01-04）. 
  8. ^ SELinux. debian.org. [2018-02-19]. （原始內容存檔於2020-08-13）. 
  9. ^ How To Install SELinux on Ubuntu 8.04 "Hardy Heron". Ubuntu Tutorials. [2018-02-19]. （原始內容存檔於2017-07-05）. 
  10. ^ openSUSE News. openSUSE News. [2018-02-19]. （原始內容存檔於2020-09-28）. 
  11. ^ Release Notes for SUSE Linux Enterprise Desktop 11. Novell. [2013-02-06]. （原始內容存檔於2016-03-13）. 
  12. ^ SELinux on CoreOS. CoreOS Docs. [2018-02-19]. （原始內容存檔於2018-09-26）. 
  13. ^ SELinux/Commands - FedoraProject. [2015-11-25]. （原始內容存檔於2020-10-24）. 
  14. ^ chcon. Linuxcommand.org. [2013-02-06]. （原始內容存檔於2004-10-24）. 
  15. ^ restorecon(8) - Linux man page. Linux.die.net. [2013-02-06]. （原始內容存檔於2021-02-27）. 
  16. ^ restorecond(8) - Linux man page. Linux.die.net. [2013-02-06]. （原始內容存檔於2017-08-27）. 
  17. ^ runcon(1) - Linux man page. Linux.die.net. [2013-02-06]. （原始內容存檔於2020-05-01）. 
  18. ^ secon(1) - Linux man page. Linux.die.net. [2013-02-06]. （原始內容存檔於2019-10-26）. 
  19. ^ fixfiles(8): fix file SELinux security contexts - Linux man page. Linux.die.net. [2013-02-06]. （原始內容存檔於2020-05-03）. 
  20. ^ setfiles(8): set file SELinux security contexts - Linux man page. Linux.die.net. [2013-02-06]. （原始內容存檔於2020-05-01）. 
  21. ^ load_policy(8) - Linux man page. Linux.die.net. [2013-02-06]. （原始內容存檔於2019-10-26）. 
  22. ^ booleans(8) - Linux man page. Linux.die.net. [2013-02-06]. （原始內容存檔於2020-06-03）. 
  23. ^ getsebool(8): SELinux boolean value - Linux man page. Linux.die.net. [2013-02-06]. （原始內容存檔於2020-06-03）. 
  24. ^ setsebool(8): set SELinux boolean value - Linux man page. Linux.die.net. [2013-02-06]. （原始內容存檔於2019-10-26）. 
  25. ^ togglesebool(8) - Linux man page. Linux.die.net. [2013-02-06]. （原始內容存檔於2020-08-26）. 
  26. ^ Ubuntu Manpage: selinux-config-enforcing - change /etc/selinux/config to set enforcing. Canonical. [2013-02-06]. （原始內容存檔於2012-12-20）. 
  27. ^ Ubuntu Manpage: selinuxenabled - tool to be used within shell scripts to determine if. Canonical. [2013-02-06]. （原始內容存檔於2013-02-09）. 
  28. ^ Ubuntu Manpage: selinux-policy-upgrade - upgrade the modules in the SE Linux policy. Canonical. [2013-02-06]. （原始內容存檔於2012-04-04）. 
  29. ^ SELinux backgrounds. SELinux. Security Guide. SUSE. [2018-02-19]. （原始內容存檔於2016-07-01）. 
  30. ^ apparmor.d - syntax of security profiles for AppArmor. [2018-02-19]. （原始內容存檔於2013-10-17）. 
  31. ^ Rainbow. laptop.org. [2018-02-19]. （原始內容存檔於2020-12-25）. 
  32. ^ SELinux Related Work. NSA.gov. [2018-02-19]. （原始內容存檔於2018-02-20）. 

外部連結

取自「https://zh.wikipedia.org/w/index.php?title=安全增强式Linux&oldid=84362787」