Linux【9】-进程管理4-2-1-安全模块--selinux
一、前言
安全增强型 Linux（Security-Enhanced Linux）简称 SELinux，它是一个 Linux 内核模块，也是 Linux 的一个安全子系统。
SELinux 主要由美国国家安全局开发。2.6 及以上版本的 Linux 内核都已经集成了 SELinux 模块。
SELinux 的结构及配置非常复杂，而且有大量概念性的东西，要学精难度较大。很多 Linux 系统管理员嫌麻烦都把 SELinux 关闭了。
如果可以熟练掌握 SELinux 并正确运用，我觉得整个系统基本上可以到达"坚不可摧"的地步了（请永远记住没有绝对的安全）。
掌握 SELinux 的基本概念以及简单的配置方法是每个 Linux 系统管理员的必修课。
本文均在 CentOS 7.4.1708 系统中操作。
二、SELinux 的作用及权限管理机制
我们知道，传统的 Linux 系统中，默认权限是对文件或目录的所有者、所属组和其他人的读、写和执行权限进行控制，这种控制方式称为自主访问控制（DAC）方式；而在 SELinux 中，采用的是强制访问控制（MAC）系统，也就是控制一个进程对具体文件系统上面的文件或目录是否拥有访问权限，而判断进程是否可以访问文件或目录的依据，取决于 SELinux 中设定的很多策略规则。
说到这里，读者有必要详细地了解一下这两个访问控制系统的特点：
- 自主访问控制系统（Discretionary Access Control，DAC）是 Linux 的默认访问控制方式，也就是依据用户的身份和该身份对文件及目录的 rwx 权限来判断是否可以访问。不过，在 DAC 访问控制的实际使用中我们也发现了一些问题：
- root 权限过高，rwx 权限对 root 用户并不生效，一旦 root 用户被窃取或者 root 用户本身的误操作，都是对 Linux 系统的致命威胁。
- Linux 默认权限过于简单，只有所有者、所属组和其他人的身份，权限也只有读、写和执行权限，并不利于权限细分与设定。
- 不合理权限的分配会导致严重后果，比如给系统敏感文件或目录设定 777 权限，或给敏感文件设定特殊权限——SetUID 权限等。
- 强制访问控制（Mandatory Access Control，MAC）是通过 SELinux 的默认策略规则来控制特定的进程对系统的文件资源的访问。也就是说，即使你是 root 用户，但是当你访问文件资源时，如果使用了不正确的进程，那么也是不能访问这个文件资源的。
这样一来，SELinux 控制的就不单单只是用户及权限，还有进程。每个进程能够访问哪个文件资源，以及每个文件资源可以被哪些进程访问，都靠 SELinux 的规则策略来确定。 注意，在 SELinux 中，Linux 的默认权限还是有作用的，也就是说，一个用户要能访问一个文件，既要求这个用户的权限符合 rwx 权限，也要求这个用户的进程符合 SELinux 的规定。
不过，系统中有这么多的进程，也有这么多的文件，如果手工来进行分配和指定，那么工作量过大。所以 SELinux 提供了很多的默认策略规则，这些策略规则已经设定得比较完善，我们稍后再来学习如何查看和管理这些策略规则。
为了使读者清楚地了解 SELinux 所扮演的角色，这里举一个例子，假设 apache 上发现了一个漏洞，使得某个远程用户可以访问系统的敏感文件（如 /etc/shadow）。如果我们的 Linux 中启用了 SELinux，那么，因为 apache 服务的进程并不具备访问 /etc/shadow 的权限，所以这个远程用户通过 apache 访问 /etc/shadow文件就会被 SELinux 所阻挡，起到保护 Linux 系统的作用。
2.1 SELinux的主要作用
我们知道，传统的 Linux 系统安全，采用的是 DAC（自主访问控制方式），而 SELinux 是部署在 Linux 系统中的安全增强功能模块，它通过对进程和文件资源采用 MAC（强制访问控制方式）为 Linux 系统提供了改进的安全性。
需要注意的是，SELinux 的 MAC 并不会完全取代 DAC，恰恰相反，对于 Linux 系统安全来说，它是一个额外的安全层，换句话说，当使用 SELinux 时，DAC 仍然被使用，且会首先被使用，如果允许访问，再使用 SELinux 策略；反之，如果 DAC 规则拒绝访问，则根本无需使用 SELinux 策略。
例如，若用户尝试对没有执行权限（rw-）的文件进行执行操作，那么传统的 DAC 规则就会拒绝用户访问，因此，也就无需再使用 SELinux 策略。
相比传统的 Linux DAC 安全控制方式，SELinux 具有诸多好处，比如说：
- 它使用的是 MAC 控制方式，这被认为是最强的访问控制方式；
- 它赋予了主体（用户或进程）最小的访问特权，这也就意味着，每个主体仅被赋予了完成相关任务所必须的一组有限的权限。通过赋予最小访问特权，可以防止主体对其他用户或进程产生不利的影响；
- SELinux 管理过程中，每个进程都有自己的运行区域（称为域），各进程仅运行在自己的域内，无法访问其他进程和文件，除非被授予了特殊权限。
- SELinux 可以调整到 Permissive 模式，此模式允许查看在系统上执行 SELinux 后所产生的印象。在 Permissive 模式中，SELinux 仍然会记录它所认为的安全漏洞，但并不会阻止它们。
有关 SELinux 模式设置等内容，后续章节会详细介绍。
其实，想要了解 SELinux 的优点，最直接的办法就是查看当 Linux 系统上没有运行 SELinux 时会发生什么事情。
例如，Web 服务器守护进程（httd）正在监听某一端口上所发生的事情，而后进来了一个请求查看主页的来自 Web 浏览器的简单请求。由于不会受到 SELinux 的约束，httpd 守护进程听到请求后，可以完成以下事情：
- 根据相关的所有者和所属组的rwx权限，可以访问任何文件或目录；
- 完成存在安全隐患的活动，比如允许上传文件或更改系统显示；
- 可以监听任何端口的传入请求。
但在一个受 SELinux 约束的系统上，httpd 守护进程受到了更加严格的控制。仍然使用上面的示例，httped仅能监听 SELinux 允许其监听的端口。SELinux 还可以防止 httpd 访问任何没有正确设置安全上下文的文件，并拒绝没有再 SELinux 中显式启用的不安全活动。
因此，从本质上讲，SELinux 最大程序上限制了 Linux 系统中的恶意代码活动。
2.2 DAC
在没有使用 SELinux 的操作系统中，决定一个资源是否能被访问的因素是：某个资源是否拥有对应用户的权限（读、写、执行）。
只要访问这个资源的进程符合以上的条件就可以被访问。
而最致命问题是，root 用户不受任何管制，系统上任何资源都可以无限制地访问。
这种权限管理机制的主体是用户，也称为自主访问控制（DAC）。
2.3 MAC
在使用了 SELinux 的操作系统中，决定一个资源是否能被访问的因素除了上述因素之外，还需要判断每一类进程是否拥有对某一类资源的访问权限。
这样一来，即使进程是以 root 身份运行的，也需要判断这个进程的类型以及允许访问的资源类型才能决定是否允许访问某个资源。进程的活动空间也可以被压缩到最小。
即使是以 root 身份运行的服务进程，一般也只能访问到它所需要的资源。即使程序出了漏洞，影响范围也只有在其允许访问的资源范围内。安全性大大增加。
这种权限管理机制的主体是进程，也称为强制访问控制（MAC）。
而 MAC 又细分为了两种方式，一种叫类别安全（MCS）模式，另一种叫多级安全（MLS）模式。
下文中的操作均为 MCS 模式。
2.4 DAC 和 MAC 的对比
这里引用一张图片来说明。
可以看到，在 DAC 模式下，只要相应目录有相应用户的权限，就可以被访问。而在 MAC 模式下，还要受进程允许访问目录范围的限制。
三、SELinux 的工作模式
通过对 SELinux 的介绍，初学者可以这样认为，在传统 Linux 系统使用访问控制方式的基础上，附加使用 SELinux 可增强系统安全。 那么，SELinux 是如何运行的呢？
3.1 几个基本概念
在解释 SELinux 的工作模式之前，先解释几个概念。
1. 主体（Subject）
就是想要访问文件或目录资源的进程。想要得到资源，基本流程是这样的：由用户调用命令，由命令产生进程，由进程去访问文件或目录资源。在自主访问控制系统中（Linux 默认权限中），靠权限控制的主体是用户；而在强制访问控制系统中（SELinux 中），靠策略规则控制的主体则是进程。
2. 目标（Object）
这个概念比较明确，就是需要访问的文件或目录资源。
3. 政策和规则（Policy & Rule）
Linux 系统中进程与文件的数量庞大，那么限制进程是否可以访问文件的 SELinux 规则数量就更加烦琐，如果每个规则都需要管理员手工设定，那么 SELinux 的可用性就会极低。还好我们不用手工定义规则，SELinux 默认定义了两个策略，规则都已经在这两个策略中写好了，默认只要调用策略就可以正常使用了。这两个默认策略如下：
- -targeted：这是 SELinux 的默认策略，这个策略主要是限制网络服务的，对本机系统的限制极少。我们使用这个策略已经足够了。
- -mls：多级安全保护策略，这个策略限制得更为严格。
系统中通常有大量的文件和进程，为了节省时间和开销，通常我们只是选择性地对某些进程进行管制。
而哪些进程需要管制、要怎么管制是由政策决定的。
一套政策里面有多个规则。部分规则可以按照需求启用或禁用（以下把该类型的规则称为布尔型规则）。
规则是模块化、可扩展的。在安装新的应用程序时，应用程序可通过添加新的模块来添加规则。用户也可以手动地增减规则。
在 CentOS 7 系统中，有三套政策，分别是：
- targeted：对大部分网络服务进程进行管制。这是系统默认使用的政策（下文均使用此政策）。
- minimum：以 targeted 为基础，仅对选定的网络服务进程进行管制。一般不用。
- mls：多级安全保护。对所有的进程进行管制。这是最严格的政策，配置难度非常大。一般不用，除非对安全性有极高的要求。
政策可以在 /etc/selinux/config 中设定。
4. 安全上下文（Security Context）
每个进程、文件和目录都有自己的安全上下文，进程具体是否能够访问文件或目录，就要看这个安全上下文是否匹配。如果进程的安全上下文和文件或目录的安全上下文能够匹配，则该进程可以访问这个文件或目录。当然，判断进程的安全上下文和文件或目录的安全上下文是否匹配，则需要依靠策略中的规则。举个例子，我们需要找对象，男人可以看作主体，女人就是目标了。而男人是否可以追到女人（主体是否可以访问目标），主要看两个人的性格是否合适（主体和目标的安全上下文是否匹配）。不过，两个人的性格是否合适，是需要靠生活习惯、为人处世、家庭环境等具体的条件来进行判断的（安全上下文是否匹配是需要通过策略中的规则来确定的）。
安全上下文是 SELinux 的核心。
- 安全上下文我自己把它分为「进程安全上下文」和「文件安全上下文」。
- 一个「进程安全上下文」一般对应多个「文件安全上下文」。
- 只有两者的安全上下文对应上了，进程才能访问文件。它们的对应关系由政策中的规则决定。
- 文件安全上下文由文件创建的位置和创建文件的进程所决定。而且系统有一套默认值，用户也可以对默认值进行设定。
需要注意的是，单纯的移动文件操作并不会改变文件的安全上下文。
安全上下文的结构及含义
安全上下文有四个字段，分别用冒号隔开。形如：system_u:object_r:admin_home_t:s0。
我们画一张示意图，来表示一下这几个概念之间的关系，如图 1 所示。
图 1 SELinux 运行模式的相关概念
解释一下这张示意图：当主体想要访问目标时，如果系统中启动了 SELinux，则主体的访问请求首先需要和 SELinux 中定义好的策略进行匹配。如果进程符合策略中定义好的规则，则允许访问，这时进程的安全上下文就可以和目标的安全上下文进行匹配；如果比较失败，则拒绝访问，并通过 AVC（Access Vector Cache，访问向量缓存，主要用于记录所有和 SELinux 相关的访问统计信息）生成拒绝访问信息。如果安全上下文匹配，则可以正常访问目标文件。当然，最终是否可以真正地访问到目标文件，还要匹配产生进程（主体）的用户是否对目标文件拥有合理的读、写、执行权限。
我们在进行 SELinux 管理的时候，一般只会修改文件或目录的安全上下文，使其和访问进程的安全上下文匹配或不匹配，用来控制进程是否可以访问文件或目录资源；而很少会去修改策略中的具体规则，因为规则实在太多了，修改起来过于复杂。不过，我们是可以人为定义规则是否生效，用以控制规则的启用与关闭的。
3.2 SELinux 的工作模式
SELinux 提供了 3 种工作模式：Disabled、Permissive 和 Enforcing，而每种模式都为 Linux 系统安全提供了不同的好处。
Disable工作模式（关闭模式）
在 Disable 模式中，SELinux 被关闭，默认的 DAC 访问控制方式被使用。对于那些不需要增强安全性的环境来说，该模式是非常有用的。
例如，若从你的角度看正在运行的应用程序工作正常，但是却产生了大量的 SELinux AVC 拒绝消息，最终可能会填满日志文件，从而导致系统无法使用。在这种情况下，最直接的解决方法就是禁用 SELinux，当然，你也可以在应用程序所访问的文件上设置正确的安全上下文。
需要注意的是，在禁用 SELinux 之前，需要考虑一下是否可能会在系统上再次使用 SELinux，如果决定以后将其设置为 Enforcing 或 Permissive，那么当下次重启系统时，系统将会通过一个自动 SELinux 文件重新进程标记。
关闭 SELinux 的方式也很简单，只需编辑配置文件 /etc/selinux/config，并将文本中 SELINUX= 更改为 SELINUX=disabled 即可，重启系统后，SELinux 就被禁用了。
Permissive工作模式（宽容模式）
在 Permissive 模式中，SELinux 被启用，但安全策略规则并没有被强制执行。当安全策略规则应该拒绝访问时，访问仍然被允许。然而，此时会向日志文件发送一条消息，表示该访问应该被拒绝。
SELinux Permissive 模式主要用于以下几种情况： 审核当前的 SELinux 策略规则； 测试新应用程序，看看将 SELinux 策略规则应用到这些程序时会有什么效果； 解决某一特定服务或应用程序在 SELinux 下不再正常工作的故障。
某些情况下，可使用 audit2allow 命令来读取 SELinux 审核日志并生成新的 SELinux 规则，从而有选择性地允许被拒绝的行为，而这也是一种在不禁用 SELinux 的情况下，让应用程序在 Linux 系统上工作的快速方法。
Enforcing工作模式（强制模式）
从此模式的名称就可以看出，在 Enforcing 模式中， SELinux 被启动，并强制执行所有的安全策略规则。
SELinux 工作模式可以在 /etc/selinux/config 中设定。
如果想从 disabled 切换到 enforcing 或者 permissive 的话，需要重启系统。反过来也一样。
enforcing 和 permissive 模式可以通过 setenforce 1|0 命令快速切换。
需要注意的是，如果系统已经在关闭 SELinux 的状态下运行了一段时间，在打开 SELinux 之后的第一次重启速度可能会比较慢。因为系统必须为磁盘中的文件创建安全上下文（我表示我重启了大约 10 分钟，还以为是死机了……）。
SELinux 日志的记录需要借助 auditd.service 这个服务，请不要禁用它。
3.2 SELinux 工作流程
这里引用一张图片，不必过多解释。
注：上面的安全文本指的就是安全上下文。
四、SELinux配置文件（/etc/selinux/config）
我们知道，SELinux 是预先配置的，可以在不进行任何手动配置的情况下使用 SELinux 功能。然而，一般来说，预先配置的 SELinux 设置很难满足所有的 Linux 系统安全需求。
SELinux 配置只能有 root 用户进行设置和修改。配置和策略文件位于 /etc/selinux 目录中，主配置文件位 /etc/selinux/config 文件，该文件中的内容如下：
[root@localhost ~]# vim /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values：
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing
#指定SELinux的运行模式。有enforcing（强制模式）、permissive（宽容模式）、disabled（不生效）三种模式
# SELINUXTYPE= can take one of these two values：
# targeted - Targeted processes are protected，
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
#指定SELinux的默认策略。有 targeted（针对性保护策略，是默认策略）和 mls（多级安全保护策略）两种策略
主配置文件中，除去以‘#’符号开头的注释行，有效配置参数仅有 2 行。其中，SELinux=enforcing 为 SELinux 默认的工作模式，有效值还可以是 permissive 和 disabled；SELINUXTYPE=targeted 用于指定 SELinux 的默认策略。 有关 SELinux 3中工作默认的介绍，可以阅读《SELinux的工作模式》一节；有关 SELinux 策略，可阅读《SELinux Targeted、MLS和Minimum策略》一节。
这里需要注意，如果从强制模式（enforcing）、宽容模式（permissive）切换到关闭模式（disabled），或者从关闭模式切换到其他两种模式，则必须重启 Linux 系统才能生效，但是强制模式和宽容模式这两种模式互相切换不用重启 Linux 系统就可以生效。这是因为 SELinux 是整合到 Linux 内核中的，所以必须重启才能正确关闭和启动。而且，如果从关闭模式切换到启动模式，那么重启 Linux 系统的速度会比较慢，那是因为需要重新写入安全上下文信息。
四、SELinux 基本操作
4.5 查询系统中的布尔型规则及其状态
命令基本用法
getsebool -a
由于该命令要么查询所有规则，要么只查询一个规则，所以一般都是先查询所有规则然后用 grep 筛选。
用法举例
查询与 httpd 有关的布尔型规则。
getsebool -a | grep httpd
执行结果
httpd_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_connect_ftp --> off
#以下省略
4.6 开关一个布尔型规则
命令基本用法
setsebool [选项]
选项功能-P重启依然生效
用法举例
开启 httpd_anon_write 规则。
setsebool -P httpd_anon_write on
六、讨论
6.1 解决selinux拦截
在配置一些服务的时候，总是会出现被selinux拦截的情况，解决方法往往都是把selinux关闭。这样做会降低了linux的安全性。本次内容就是解决被selinux拦截的分析方法。
在linux下面提供了一个软件用于分析selinux日志信息
安装setroubleshoot
#yum install setroubleshoot
这个软件会把错误信息写入到/var/log/messages
#cat /var/log/messages |grep setroubleshoot
例如：
[root@localhost ~]# cat /var/log/messages |grep setroubleshoot
Nov 5 11:47:09 localhost yum[8860]: Installed: setroubleshoot-plugins-3.0.40-2.el6.noarch
Nov 5 11:47:11 localhost yum[8860]: Installed: setroubleshoot-server-3.0.47-6.el6.i686
Nov 5 11:47:17 localhost yum[8860]: Installed: setroubleshoot-3.0.47-6.el6.i686
Nov 5 11:55:09 localhost setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file /root/.ssh/authorized_keys. For complete SELinux messages. run sealert -l 090d0ada-850d-4a47-9395-1ceb7efe524d
Nov 5 11:55:09 localhost setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file /root/.ssh/authorized_keys. For complete SELinux messages. run sealert -l 090d0ada-850d-4a47-9395-1ceb7efe524d
Nov 5 11:55:09 localhost setroubleshoot: SELinux is preventing /usr/sbin/sshd from getattr access on the file /root/.ssh/authorized_keys. For complete SELinux messages. run sealert -l 936dc62f-3f2c-4d16-9ec5-7043ccf0562b
#sealert -l 090d0ada-850d-4a47-9395-1ceb7efe524d
例如：
[root@localhost ~]# sealert -l 090d0ada-850d-4a47-9395-1ceb7efe524d
SELinux is preventing /usr/sbin/sshd from read access on the file /root/.ssh/authorized_keys.
***** Plugin restorecon (90.5 confidence) suggests *************************
If you want to fix the label.
/root/.ssh/authorized_keys default label should be ssh_home_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /root/.ssh/authorized_keys
***** Plugin sshd_root (9.50 confidence) suggests **************************
If you want to allow sshd to have read access on the authorized_keys file
Then you must fix the labels.
Do
/sbin/restorecon -Rv /root/.ssh
***** Plugin catchall (1.40 confidence) suggests ***************************
If you believe that sshd should be allowed read access on the authorized_keys file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep sshd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
看到上面的解决方法了。
restroecon -Rv /root/.ssh
参考资料
