安全增强式Linux

安全增強式Linux（SELinux，Security-Enhanced Linux）是一个Linux内核的安全模组，其提供了访问控制安全策略机制，包括了强制访问控制（Mandatory Access Control，MAC）。

SELinux是一组内核修改和用户空间工具，已经被添加到各种Linux发行版中。其软件架构力图将安全决策的执行与安全策略分离，并简化涉及执行安全策略的软件的数量。SELinux的核心概念可以追溯回美国国家安全局（NSA）的一些早期项目。

概览

美国国家安全局的安全增强式Linux团队称：

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

整合SELinux的Linux内核将执行限制用户程序和系统服务器访问文件与网络资源的强制访问控制策略。将权限限制到最小以减少或完全清除程序和守护进程在失效或出错的情况（如缓存区溢出或错误配置）下对系统造成危害的可能性。此种限制机制独立与于传统的Linux自主访问控制（Discretionary Access Control, DAC）进行。SELinux没有“root”用户的概念，也没有传统Linux安全机制的缺点。（如依赖于setuid/setgid库）

“未修改过的”Linux系统安全性（即未整合SELinux的系统）依赖于内核、授权应用与其配置的正确性。三者中任意一个发生问题都将有可能导致整个系统被破解。相反，“修改过的”系统安全性（基于SELinux内核）主要基于其内核和配置的正确性。虽然当应用程序的正确性或配置出现问题可能会导致独立的用户程序和系统守护进程发生有限破解，但是它们并不会对其他用户程序和系统守护进程或整个系统的安全性造成威胁。

纯粹来看，SELinux提供了一个从强制访问控制、强制完整性控制、以角色為基礎的存取控制和类型强制架构提取出的概念与功能的混合体。第三方工具可以使开发者构建多种安全策略。

历史

早期工作主要指向在UNIX计算环境（准确而言是POSIX）下标准化强制和自主访问控制条款的方法。这归因于美国国家安全局受信UNIX（TRUSIX）工作组，他们在1987到1991年间接触并发布了一本彩虹书 （#020A），并制造了一个原初模型和最初未发布的关联评估证据原型（#020B）。

SELinux最初设计向Linux社区展示强制访问控制的价值和这些控制加入Linux的方法。起初，组成SELinux的补丁只能通过明确添加在Linux内核源码中来工作；在2.6系列的Linux内核中SELinux已被整合入。

作为最初SELinux的主要开发者，美国国家安全局于2000年12月22日基于GNU通用公共许可证發行了第一版SELinux給了開放原始碼開發社群。

SELinux随后被整合进了Linux内核2.6.0-test3版本的主分支，并在2003年8月8日发布。其他的显要贡献者有紅帽公司、迈克菲、安全计算公司、特瑟思科技（Tresys Technology）和可信计算机解决方案（Trusted Computer Solutions）。FLASK/TE实现通过FreeBSD项目成功移植到了FreeBSD和Darwin操作系统上。

SELinux实现了通量高级安全内核。这种内核包含了以锚爪操作系统为原型的架构部件。这些提供给了强制执行多种强制访问控制策略许多通常支持，包括了基于类型强制、以角色為基礎的存取控制和多层安全概念的策略。FLASK基于马赫衍生的（Mach-derived）分布式受信操作系统（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在Android4.3版本中就已得以实现。

在自由社区所支持的GNU/Linux发行版中，Fedora (作業系統)Fedora是最早采用SELinux的，在Fedora Core 2中就已默认包含了对其的支持。其他发行版中，Debian在Etch发行版中包含了对它的支持，Ubuntu则在8.04版代号坚强的苍鹭（Hardy Heron）中加入。截止openSUSE版本11.1中，它包含了SELinux的“基础实现”。 SUSE Linux Enterprise 11将SELinux作为“技术预览”。

SELinux在基于Linux容器的系统中流向,比如CoreOS和rkt。其作为额外的安全控制来帮助隔离容器和它们的主机十分有用。

使用情形

SELinux可以潜在地通过详细的参数来控制允许系统每个用户的活动、进程以及守护进程。但是，它主要用于限制守护进程比如被更显著定义数据访问和活动权限的数据库引擎或者网页服务器。这限制了被破解的限制守护进程的潜在危害。普通的用户进程通常运行于受限域中，不被SELinux所限制但被经典Linux访问权限所限制。

命令行工具包含： chcon, restorecon, restorecond, runcon, secon, fixfiles, setfiles, load_policy, booleans, getsebool, setsebool, togglesebool setenforce, semodule, postfix-nochroot, check-selinux-installation, semodule_package, checkmodule, selinux-config-enforcing, selinuxenabled, 及 selinux-policy-upgrade

示例

将SELinux设置为强制模式（Enforcing Mode）：

$ sudo setenforce 1

查询SELinux状态：

$ getenforce

与AppArmor的对比

SELinux代表了多个可能解决限制安装软件活动的方法之一。另外一个受欢迎的替代品被称为AppArmor，它在SUSE Linux Enterprise Server（SLES）、OpenSUSE和其他Linux平台中可用。AppArmor原初是作为现不存在的Immunix Linux平台组件之一开发的。由于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支持作为策略配置替代源的"远程策略服务器"概念（可在/etc/selinux/semanage.conf中配置）。AppArmor的中心化管理通常十分复杂，这是因为管理员必须决定策略部署工具以root权限运行（以允许策略更新）或在每台服务器上手动配置。

相似系统

孤立进程也可以通过类似作業系統層虛擬化的机制实现；比如在OLPC项目的首次实现中它使用了沙盒技术在轻量的Vserver环境中隔离独立的应用程序。同样美国国家安全局也在安全增强型Android中采用了一些SELinux概念。

参见

参考文献

外部链接

• 官方网站
• NSA:
  • Security-Enhanced Linux （页面存档备份，存于互联网档案馆） at NSA
  • Mailing list （页面存档备份，存于互联网档案馆）
  • NSA shares security enhancements to Linux. Press release. Jan 2, 2001 [2018-02-19]. （原始内容存档于2018-02-20）. 
• GitHub上的SELinux
• Walsh, Daniel J. Visual how-to guide for SELinux policy enforcement. Opensource.com. 13 Nov 2013 [2018-02-19]. （原始内容存档于2017-07-07）.