安全增强式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/库）
“未修改过的”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）。/TE实现通过FreeBSD项目成功移植到了FreeBSD和Darwin操作系统上。
SELinux实现了。这种内核包含了以为原型的架构部件。这些提供给了强制执行多种强制访问控制策略许多通常支持，包括了基于、以角色为基础的存取控制和概念的策略。FLASK基于马赫衍生的（Mach-derived）（DTOS）和来自对DTOS的设计和实现有着影响的的一个研究项目——受信马赫（Trusted Mach）。
用户、策略和安全上下文.
SELinux用户和角色不需要与实际系统用户与角色相关。对每个正在进行的用户或进程，SELinux分配一个三字符串上下文，包含了用户名、角色和域（或者类型）。此系统比通常所需要的系统更灵活：作为规定之一，大多数真实用户享有着相同的SELinux用户名，且所有的访问控制都经由第三个标签——域来进行。在一个进程被允许进入域的情况下必须在策略中配置。命令codice_1允许启动进程进入一个显性定义上下文（用户、角色和域）环境中，但如果政策中未允许的话那么SELinux可能会拒绝此请求。
文件、网络端口和其他硬件均有可能含有SELinux上下文，由一个名字、角色（不常使用）和类型组成。文件系统在文件和安全上下文之间的映射被称为标记（Labeling）。标记在策略文件中被定义但也可以在不更改策略的情况下手动调整。硬件类型十分详细，比如codice_2（显示/bin下的所有文件）或codice_3（PostgreSQL端口5432）。远程文件系统的SELinux上下文可以在被挂载时显性定义。
SELinux给Shell命令codice_4、codice_5等中添加了codice_6开关使得文件或进程的安全上下文可见。
典型的政策规则包含了显性权限；用户必须拥有哪些域才能用给定目标进行特定的行为（读、执行，网络端口中则是绑定或连接）等等。也可以进行更多复杂的映射，包括在角色级和安全级进行。
一个典型的策略包含了一个映射文件（标记）文件、一个规则文件和一个定义域过渡的界面文件。这三个文件必须被同时使用SELinux工具编译来生成单一的策略文件。生成的策略文件可以被载入到内核中并工作。载入和卸载策略并不需要重启。策略文件既有可能是手打也可能是用容易使用的SELinux管理工具生成。它们通常先在允许模式（Permissive Mode）下测试，在此模式下违反策略的行为都将被记录但被允许。codice_7工具可以随后使用来生成扩展SELinux策略以允许受限应用的合法活动的附加规则。
特性.
SELinux特性包含了：
实现.
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在基于的系统中流向,比如CoreOS和rkt。其作为额外的安全控制来帮助隔离容器和它们的主机十分有用。
使用情形.
SELinux可以潜在地通过详细的参数来控制允许系统每个用户的活动、进程以及守护进程。但是，它主要用于限制守护进程比如被更显著定义数据访问和活动权限的数据库引擎或者网页服务器。这限制了被破解的限制守护进程的潜在危害。普通的用户进程通常运行于受限域中，不被SELinux所限制但被经典Linux访问权限所限制。
命令行工具包含：
codice_8,
codice_9,
codice_10,
codice_1,
codice_12,
codice_13,
codice_14,
codice_15,
codice_16,
codice_17,
codice_18,
codice_19
codice_20,
codice_21,
codice_22,
codice_23,
codice_24,
codice_25,
codice_26,
codice_27,
及 codice_28
示例.
将SELinux设置为强制模式（Enforcing Mode）：
查询SELinux状态：
与AppArmor的对比.
SELinux代表了多个可能解决限制安装软件活动的方法之一。另外一个受欢迎的替代品被称为AppArmor，它在（SLES）、OpenSUSE和其他Linux平台中可用。AppArmor原初是作为现不存在的平台组件之一开发的。由于AppArmor和SELinux大相径庭，它们产生了两种完全不同的软件访问限制软件。虽然SELinux重新提出了特定的概念以提供更丰富的策略选择表达集，但AppArmor通过扩展用于自主访问控制级的特定相同自主访问控制管理语言设计来简化其使用。
它们之间存在几个显著的不同：
相似系统.
孤立进程也可以通过类似作业系统层虚拟化的机制实现；比如在OLPC项目的首次实现中它使用了沙盒技术在轻量的环境中隔离独立的应用程序。同样美国国家安全局也在安全增强型Android中采用了一些SELinux概念。