SELinux 是什么？

一、SELinux的历史

SELinux全称是Security Enhanced Linux，由美国国家安全部(National Security Agency)领导开发的GPL项目，它拥有一个灵活而强制性的访问控制结构，旨在提高Linux系统的安全性，提供强健的安全保证，可防御未知攻击，相当于B1级的军事安全性能。比MS NT的C2等高得多。

SELinux起源于自1980开始的微内核和操作系统安全的研究，这两条研究线路最后形成了一个叫做的分布式信任计算机（Distribute Trusted Mach (DTMach)）的项目，它融合了早期研究项目的成果（LOCK【锁】，它包含一组安全内核类型强制；Trusted Mach【信任计算机】，它将多层安全控制合并到计算机微内核中）。美国国家安全局的研究组织参加了DTMach项目，付出了巨大努力，并且继续参与了大量的后续安全微内核项目。最终，这些工作和努力导致了一个新的项目产生，那就是Flask，它支持更丰富的动态类型的强制机制。

由于不同平台对这这项技术没有广泛使用，NAS认为需要在大量的社团中展示这个技术，以说明它的持久生命力，并收集广泛的使用支持意见。在1999年夏天，NSA开始在Linux内核中实现Flask安全架构，在2000年十二月，NSA发布了这项研究的第一个公共版本，叫做安全增强的Linux。因为是在主流的操作系统中实现的，所以SELinux开始受到Linux社区的注意，SELinux最迟是在2.2.x内核中以一套内核补丁的形式发布的。

随着2001年Linux内核高级会议在加拿大渥太华顺利召开，Linux安全模型（LSM[7]）项目开始为Linux内核创建灵活的框架，允许不同的安全扩展添加到Linux中。NSA和SELinux社区是SELinux的主要贡献者，SELinux帮助LSM实现了大量的需求，为了与LSM一起工作，NSA开始修改SELinux使用LSM框架。2002年八月LSM核心特性被集成到Linux内核主线，同时被合并到Linux 2.6内核。2003年八月，NSA在开源社区的帮助下，完成了SELinux到LSM框架的迁移，至此，SELinux进入Linux 2.6内核主线，SELinux已经成为一种全功能的LSM模块，包括在核心Linux代码集中。

数个Linux发行版开始在2.6内核中不同程度使用SELinux特性，但最主要是靠Red Hat发起的Fedora Core项目才使SELinux具备企业级应用能力，NSA和Red Hat开始联合集成SELinux，将其作为Fedora Core Linux发行版的一部分。在Red Hat参与之前，SELinux总是作为一个附加的软件包，需要专家级任务才能进行集成。Red Hat开始采取行动让SELinux成为主流发行版的一部分，完成了用户空间工具和服务的修改，默认开启增强的安全保护。从Fedora Core 2开始，SELinux和它的支持基础架构以及工具得到改进。在2005年早些时候，Red Hat发布了它的Enterprise Linux 4（REL 4），在这个版本中，SELinux默认就是完全开启的，SELinux和强制访问控制已经进入了主流操作系统和市场。

SELinux仍然是一个相对较新和复杂的技术，重要的研究和开发在继续不断地改进它的功能。

应用SELinux后，可以减轻恶意攻击或恶意软件带来的灾难，并提供对机密性和完整性有很高要求的信息很高的安全保障。普通Linux安全和传统Unix系统一样，基于自主存取控制方法，即DAC，只要符合规定的权限，如规定的所有者和文件属性等，就可存取资源。在传统的安全机制下，一些通过setuid/setgid的程序就产生了严重安全隐患，甚至一些错误的配置就可引发巨大的漏洞，被轻易攻击。

而SELinux则基于强制存取控制方法，即MAC，透过强制性的安全策略，应用程序或用户必须同时符合DAC及对应SELinux的MAC才能进行正常操作，否则都将遭到拒绝或失败，而这些问题将不会影响其他正常运作的程序和应用，并保持它们的安全系统结构。

二、SELinux 的作用及权限管理机制

2.1 SELinux 的作用

SELinux 主要作用就是最大限度地减小系统中服务进程可访问的资源（最小权限原则）。

2.2 DAC

在没有使用 SELinux 的操作系统中，决定一个资源是否能被访问的因素是：某个资源是否拥有对应用户的权限（读、写、执行）。

只要访问这个资源的进程符合以上的条件就可以被访问。

而最致命问题是，root 用户不受任何管制，系统上任何资源都可以无限制地访问。

这种权限管理机制的主体是用户，也称为自主访问控制（DAC）；

2.3 MAC

在使用了 SELinux 的操作系统中，决定一个资源是否能被访问的因素除了上述因素之外，还需要判断每一类进程是否拥有对某一类资源的访问权限。

这样一来，即使进程是以 root 身份运行的，也需要判断这个进程的类型以及允许访问的资源类型才能决定是否允许访问某个资源。进程的活动空间也可以被压缩到最小。

即使是以 root 身份运行的服务进程，一般也只能访问到它所需要的资源。即使程序出了漏洞，影响范围也只有在其允许访问的资源范围内。安全性大大增加。

这种权限管理机制的主体是进程，也称为强制访问控制（MAC）。

而 MAC 又细分为了两种方式，一种叫类别安全（MCS）模式，另一种叫多级安全（MLS）模式。

三、SELinux 基本概念

3.1 主体（Subject）

可以完全等同于进程。

3.2 对象（Object）

被主体访问的资源。可以是文件、目录、端口、设备等。

3.3 政策和规则（Policy & Rule）

一套政策里面有多个规则。部分规则可以按照需求启用或禁用（以下把该类型的规则称为布尔型规则）。

3.4 安全上下文（Security Context）

安全上下文是 SELinux 的核心。

安全上下文我自己把它分为「进程安全上下文」和「文件安全上下文」。

一个「进程安全上下文」一般对应多个「文件安全上下文」。只有两者的安全上下文对应上了，进程才能访问文件。它们的对应关系由政策中的规则决定。

3.5 SELinux 的工作模式

SELinux 有三种工作模式，分别是：

1. enforcing：强制模式。违反 SELinux 规则的行为将被阻止并记录到日志中。

2. permissive：宽容模式。违反 SELinux 规则的行为只会记录到日志中。一般为调试用。

3. disabled：关闭 SELinux。

3.6 SELinux 工作流程

这里引用一张图片，不必过多解释。

四、SELinux 基本操作

4.1 查询文件或目录的安全上下文

 ls -Z

查询 /etc/hosts 的安全上下文。

4.2 查询进程的安全上下文

 ps auxZ | grep -v grep | grep

举例：

查询 Nginx 相关进程的安全上下文。

 ps auxZ | grep -v grep | grep nginx

4.3 手动修改文件或目录的安全上下文

 chcon [...]

选项功能-u 修改安全上下文的用户字段-r 修改安全上下文的角色字段-t 修改安全上下文的类型字段-l 修改安全上下文的级别字段--reference 修改与指定文件或目录相一致的安全上下文-R递归操作-h修改软链接的安全上下文（不加此选项则修改软链接对应文件）

4.4 把文件或目录的安全上下文恢复到默认值

 restorecon [选项] [...]

选项功能-v打印操作过程-R递归操作