Linux学习-SELinux 初探

什么是 SELinux

什么是 SELinux 呢?其实他是『 Security Enhanced Linux 』的缩写，字面上的意义就是安全强化的 Linux 之意!

---

• 当初设计的目标:避免资源的误用

SELinux 是由美国国家安全局 (NSA) 开发的，当初开发这玩意儿的目的是因为很多企业界发现，通 常系统出现问题的原因大部分都在于『内部员工的资源误用』所导致的，实际由外部发动的攻击反而没有这么严重。

也就是说:其实 SELinux 是在进行进程、文件等细部权限设定依据的一个核心模块! 由于启动网 络服务的也是进程，因此刚好也能够控制网络服务能否存取系统资源的一道关卡!

---

• 传统的文件权限与账号关系:自主式访问控制,DAC

我们知道系统的账号主要分为系统管理员 (root) 与一般用户，而这两种身份能否使用系统上面的文件资源则与 rwx 的权限设定有关。不过你要注意的是，各种权限设定对 root 是无效的。因此，当某个进程想要对文件进行存取时， 系统就会根据该进程的拥有者/群组，并比对文 件的权限，若通过权限检查，就可以存取该文件了。

这种存取文件系统的方式被称为『自主式访问控制 (Discretionary Access Control, DAC)』，基本上， 就是依据进程的拥有者与文件资源的 rwx 权限来决定有无存取的能力。不过这种 DAC 的访问控制 有几个困扰，那就是:

• root 具有最高的权限:如果不小心某支进程被有心人士取得， 且该进程属于 root 的权限，那么这支进程 就可以在系统上进行任何资源的存取!

• 使用者可以取得进程来变更文件资源的访问权限:如果你不小心将某个目录的权限设定为 777 ，由于对任 何人的权限会变成 rwx ，因此该目录就会被任何人所任意存取!

---

• 以政策规则订定特定进程读取特定文件:委任式访问控制, MAC

为了避免 DAC 容易发生的问题，因此 SELinux 导入了委任式访问控制 (Mandatory Access Control, MAC) 的方法!

委任式访问控制 (MAC) 有趣啦!他可以针对特定的进程与特定的文件资源来进行权限的控管! 也就是说，即使你是 root ，那么在使用不同的进程时，你所能取得的权限并不一定是 root ， 而得要 看当时该进程的设定而定。如此一来，我们针对控制的『主体』变成了『进程』而不是使用者喔! 此 外，这个主体进程也不能任意使用系统文件资源，因为每个文件资源也有针对该主体进程设定可取用 的权限!如此一来，控件目就细的多了!但整个系统进程那么多、文件那么多，一项一项控制可就 没完没了! 所以 SELinux 也提供一些预设的政策 (Policy) ，并在该政策内提供多个规则 (rule) ， 让你可以选择是否启用该控制规则!

简单的来说，针对 Apache 这个 WWW 网络服务使用 DAC 或 MAC 的结果来说，两者间的关系 可以使用下图来说明。

左图是没有 SELinux 的 DAC 存取结果，apache 这只 root 所主导的进程，可以在这三个目录内作任何文件的新建与修改~右边则是加上 SELinux 的 MAC 管理的结果，SELinux 仅会 针对 Apache 这个『 process 』放行部份的目录， 其他的非正规目录就不会放行给 Apache 使用!

SELinux 的运作模式

SELinux 是透过 MAC 的方式来控管进程，他控制的主体是进程， 而目标则 是该进程能否读取的『文件资源』!

• 主体 (Subject):

SELinux 主要想要管理的就是进程，因此你可以将process 划上等号

• 目标 (Object):

主体进程能否存取的『目标资源』一般就是文件系统。因此这个目标项目可以等文件系统划上等号;

• 政策 (Policy):

由于进程与文件数量庞大，因此 SELinux 会依据某些服务来制订基本的存取安全性政策。这些政策内还会有详细的规则 (rule) 来指定不同的服务开放某些资源的存取与否。在目前的 CentOS 7.x 里面仅有提供三个 主要的政策，分别是:

• targeted:针对网络服务限制较多，针对本机限制较少，是预设的政策;
• minimum:由 target 修订而来，仅针对选择的进程来保护!
• mls:完整的 SELinux 限制，限制方面较为严格。

• 安全性本文 (security context):

主体能不能存取目标除了政策指定之外，主体与目标的安全性 本文必须一致才能够顺利存取。安全性本文 (security context) 有点类似文件系统的 rwx 啦!安全性本 文的内容与设定是非常重要的!如果设定错误，你的某些服务(主体进程)就无法存取文件系统(目标资源)，就会一直出现权限不符的错误讯息了。

上图的重点在『主体』如何取得『目标』的资源访问权限! 由上图我们可以发现，(1)主体进程必须 要通过 SELinux 政策内的规则放行后，就可以与目标资源进行安全性本文的比对， (2)若比对失败 则无法存取目标，若比对成功则可以开始存取目标。问题是，最终能否存取目标还是与文件系统的 rwx 权限设定有关喔!

---

• 安全性本文 (Security Context)

CentOS 7.x 的 target 政策已经帮我们制订好非常多的规则了，因此你只要知道如何开启/关闭某项规 则的放行与否即可。 那个安全性本文比较麻烦!因为你可能需要自行配置文件案的安全性本文呢! 为何需要自行设定啊? 举例来说，你不也常常进行文件的 rwx 的重新设定吗?这个安全性本文你就 将他想成 SELinux 内必备的 rwx 就是了!

安全性本文存在于主体进程中与目标文件资源中。进程在内存内，所以安全性本文可以存入是没问题。 那文件的安全性本文是记录在哪里呢?事实上，安全性本文是放置到文件的 inode 内的，因此主体 进程想要读取目标文件资源时，同样需要读取 inode ， 这 inode 内就可以比对安全性本文以及 rwx 等权限值是否正确，而给予适当的读取权限依据。

那么安全性本文到底是什么样的存在呢?我们先来看看 /root 底下的文件的安全性本文好了。观察 安全性本文可使用『 ls -Z 』去观察如下:

# 先来观察一下 root 家目录底下的『文件的 SELinux 相关信息』
[root@study ~]# ls -Z
-rw-------. root root system_u:object_r:admin_home_t:s0     anaconda-ks.cfg
-rw-r--r--. root root system_u:object_r:admin_home_t:s0     initial-setup-ks.cfg
-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 regular_express.txt
# 上述特殊字体的部分，就是安全性本文的内容!仅列出数个预设的文件

如上所示，安全性本文主要用冒号分为三个字段，这三个字段的意义为:

Identify:role:type
身份识别:角色:类型

三个字段的意义仔细的说明:

• 身份识别 (Identify):

相当于账号方面的身份识别!主要的身份识别常见有底下几种常见的类型:

• unconfined_u:不受限的用户，也就是说，该文件来自于不受限的进程所产生的!一般来说，我们使用可登 入账号来取得 bash 之后， 预设的 bash 环境是不受 SELinux 管制的~因为 bash 并不是什么特别的网络服务!因此，在这个不受 SELinux 所限制的 bash 进程所产生的文件，其身份识别大多就是 unconfined_u 这个『不受限』用户啰!

• system_u:系统用户，大部分就是系统自己产生的文件啰!

如果是系统或软件本身所提供的文件，大多就是 system_u 这个身份名称，而如果是 我们用户透过 bash 自己建立的文件，大多则是不受限的 unconfined_u 身份~如果是网络服务 所产生的文件，或者是系统服务运作过程产生的文件，则大部分的识别就会是 system_u

因此你看上面的三个文件中，系统安装 主动产生的 anaconda-ks.cfs 及 initial-setup-ks.cfg 就会是 system_u，而我们自己从网络上面抓 下来的 regular_express.txt 就会是 unconfined_u 这个识别

• 角色 (Role):

透过角色字段，我们可以知道这个资料是属于进程、文件资源还是代表使用者。一般的角色有:

• object_r:代表的是文件或目录等文件资源，这应该是最常见的啰;

• system_r:代表的就是进程啦!不过，一般使用者也会被指定成为 system_r 喔!

• 类型 (Type) (最重要!):

在预设的 targeted 政策中， Identify 与 Role 字段基本上是不重要的!重要的在于这个类型 (type) 字段! 基本上，一个主体进程能不能读取到这个文件资源，与类型字段有关!而类型字 段在文件与进程的定义不太相同，分别是:

• type:在文件资源 (Object) 上面称为类型 (Type);

• domain:在主体进程 (Subject) 则称为领域 (domain) 了!

domain 需要与 type 搭配，则该进程才能够顺利的读取文件资源啦!

---

• 进程与文件 SELinux type 字段的相关性

首先我们来瞧瞧主体进程在这三个字段的意义为何!透过身份识别与角 色字段的定义， 我们可以约略知道某个进程所代表的意义喔!先来动手瞧一瞧目前系统中的进程在 SELinux 底下的安全本文为何?

# 再来观察一下系统『进程的 SELinux 相关信息』
[root@study ~]# ps -eZ
LABEL                             PID TTY          TIME CMD
system_u:system_r:init_t:s0         1 ?        00:00:03 systemd
system_u:system_r:kernel_t:s0       2 ?        00:00:00 kthreadd
system_u:system_r:kernel_t:s0       3 ?        00:00:00 ksoftirqd/0
.....(中間省略).....
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 31513 ? 00:00:00 sshd
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 31535 pts/0 00:00:00 bash
# 基本上进程主要就分为两大类，一种是系统有受限的 system_u:system_r，另一种则可能是用户自己的，
# 比较不受限的进程 (通常是本机用户自己执行的程序)，亦即是 unconfined_u:unconfined_r 这两种!

基本上，这些对应资料在 targeted 政策下的对应如下:

身份识别	角色	该对应在 targeted 的意义
unconfined_u	unconfined_r	一般可登入使用者的进程啰!比较没有受限的进程之意!大多数都是用户已经顺利 登入系统 (不论是网络还是本机登入来取得可用的 shell) 后， 所用来操作系统的 进程!如 bash, X window 相关软件等。
system_u	system_r	由于为系统账号，因此是非交谈式的系统运作进程，大多数的系统进程均是这种类型!

如上所述，在预设的 target 政策下，其实最重要的字段是类型字段 (type)， 主体与目标之间是 否具有可以读写的权限，与进程的 domain 及文件的 type 有关!

这两者的关系我们可以使用 crond 以及他的配置文件来说明! 亦即是 /usr/sbin/crond, /etc/crontab, /etc/cron.d 等文件来说明。 首先，看 看这几个咚咚的安全性本文内容先:

# 1. 先看看 crond 这个『进程』的安全本文内容:
[root@study ~]# ps -eZ | grep cron
system_u:system_r:crond_t:s0-s0:c0.c1023 1338 ? 00:00:01 crond
system_u:system_r:crond_t:s0-s0:c0.c1023 1340 ? 00:00:00 atd
# 这个安全本文的类型名称为 crond_t 格式!

# 2. 再来瞧瞧执行档、配置文件等等的安全本文内容为何!

```<p>---恢复内容结束---</p>### 什么是 SELinux

什么是 SELinux 呢?其实他是『 Security Enhanced Linux 』的缩写，字面上的意义就是安全强化的 Linux 之意!

--- 

* 当初设计的目标:避免资源的误用

SELinux 是由美国国家安全局 (NSA) 开发的，当初开发这玩意儿的目的是因为很多企业界发现，通 常系统出现问题的原因大部分都在于『内部员工的资源误用』所导致的，实际由外部发动的攻击反而没有这么严重。

也就是说:其实 SELinux 是在进行进程、文件等细部权限设定依据的一个核心模块! 由于启动网 络服务的也是进程，因此刚好也能够控制网络服务能否存取系统资源的一道关卡!

---

* 传统的文件权限与账号关系:自主式访问控制,DAC

我们知道系统的账号主要分为系统管理员 (root) 与一般用户，而这两种身份能否使用系统上面的文件资源则与 rwx 的权限设定有关。不过你要注意的是，各种权限设定对 root 是无效的。因此，当某个进程想要对文件进行存取时， 系统就会根据该进程的拥有者/群组，并比对文 件的权限，若通过权限检查，就可以存取该文件了。

这种存取文件系统的方式被称为『自主式访问控制 (Discretionary Access Control, DAC)』，基本上， 就是依据进程的拥有者与文件资源的 rwx 权限来决定有无存取的能力。不过这种 DAC 的访问控制 有几个困扰，那就是:

* root 具有最高的权限:如果不小心某支进程被有心人士取得， 且该进程属于 root 的权限，那么这支进程 就可以在系统上进行任何资源的存取!

* 使用者可以取得进程来变更文件资源的访问权限:如果你不小心将某个目录的权限设定为 777 ，由于对任 何人的权限会变成 rwx ，因此该目录就会被任何人所任意存取!

---

* 以政策规则订定特定进程读取特定文件:委任式访问控制, MAC

为了避免 DAC 容易发生的问题，因此 SELinux 导入了委任式访问控制 (Mandatory Access Control, MAC) 的方法!

委任式访问控制 (MAC) 有趣啦!他可以针对特定的进程与特定的文件资源来进行权限的控管! 也就是说，即使你是 root ，那么在使用不同的进程时，你所能取得的权限并不一定是 root ， 而得要 看当时该进程的设定而定。如此一来，我们针对控制的『主体』变成了『进程』而不是使用者喔! 此 外，这个主体进程也不能任意使用系统文件资源，因为每个文件资源也有针对该主体进程设定可取用 的权限!如此一来，控件目就细的多了!但整个系统进程那么多、文件那么多，一项一项控制可就 没完没了! 所以 SELinux 也提供一些预设的政策 (Policy) ，并在该政策内提供多个规则 (rule) ， 让你可以选择是否启用该控制规则!

简单的来说，针对 Apache 这个 WWW 网络服务使用 DAC 或 MAC 的结果来说，两者间的关系 可以使用下图来说明。 

![使用DAC/MAC产生的不同结果，以Apache为例说明](http://images2017.cnblogs.com/blog/1254925/201710/1254925-20171030100943746-1403101533.png)

左图是没有 SELinux 的 DAC 存取结果，apache 这只 root 所主导的进程，可以在这三个目录内作任何文件的新建与修改~右边则是加上 SELinux 的 MAC 管理的结果，SELinux 仅会 针对 Apache 这个『 process 』放行部份的目录， 其他的非正规目录就不会放行给 Apache 使用!

### SELinux 的运作模式

SELinux 是透过 MAC 的方式来控管进程，他控制的主体是进程， 而目标则 是该进程能否读取的『文件资源』!

* 主体 (Subject):

SELinux 主要想要管理的就是进程，因此你可以将process 划上等号

* 目标 (Object):

主体进程能否存取的『目标资源』一般就是文件系统。因此这个目标项目可以等文件系统划上等号;

* 政策 (Policy):

由于进程与文件数量庞大，因此 SELinux 会依据某些服务来制订基本的存取安全性政策。这些政策内还会有详细的规则 (rule) 来指定不同的服务开放某些资源的存取与否。在目前的 CentOS 7.x 里面仅有提供三个 主要的政策，分别是:

+ targeted:针对网络服务限制较多，针对本机限制较少，是预设的政策;
+ minimum:由 target 修订而来，仅针对选择的进程来保护!
+ mls:完整的 SELinux 限制，限制方面较为严格。

* 安全性本文 (security context):

主体能不能存取目标除了政策指定之外，主体与目标的安全性 本文必须一致才能够顺利存取。安全性本文 (security context) 有点类似文件系统的 rwx 啦!安全性本 文的内容与设定是非常重要的!如果设定错误，你的某些服务(主体进程)就无法存取文件系统(目标资源)，就会一直出现权限不符的错误讯息了。

![SELinux运作的各组件](http://images2017.cnblogs.com/blog/1254925/201710/1254925-20171030101613574-1937737133.png)

上图的重点在『主体』如何取得『目标』的资源访问权限! 由上图我们可以发现，(1)主体进程必须 要通过 SELinux 政策内的规则放行后，就可以与目标资源进行安全性本文的比对， (2)若比对失败 则无法存取目标，若比对成功则可以开始存取目标。问题是，最终能否存取目标还是与文件系统的 rwx 权限设定有关喔!

---

* 安全性本文 (Security Context)

CentOS 7.x 的 target 政策已经帮我们制订好非常多的规则了，因此你只要知道如何开启/关闭某项规 则的放行与否即可。 那个安全性本文比较麻烦!因为你可能需要自行配置文件案的安全性本文呢! 为何需要自行设定啊? 举例来说，你不也常常进行文件的 rwx 的重新设定吗?这个安全性本文你就 将他想成 SELinux 内必备的 rwx 就是了!

安全性本文存在于主体进程中与目标文件资源中。进程在内存内，所以安全性本文可以存入是没问题。 那文件的安全性本文是记录在哪里呢?事实上，安全性本文是放置到文件的 inode 内的，因此主体 进程想要读取目标文件资源时，同样需要读取 inode ， 这 inode 内就可以比对安全性本文以及 rwx 等权限值是否正确，而给予适当的读取权限依据。

那么安全性本文到底是什么样的存在呢?我们先来看看 /root 底下的文件的安全性本文好了。观察 安全性本文可使用『 ls -Z 』去观察如下:

先来观察一下 root 家目录底下的『文件的 SELinux 相关信息』

[root@study ~]# ls -Z

-rw-------. root root system_u:object_r:admin_home_t:s0 anaconda-ks.cfg

-rw-r--r--. root root system_u:object_r:admin_home_t:s0 initial-setup-ks.cfg

-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 regular_express.txt

上述特殊字体的部分，就是安全性本文的内容!仅列出数个预设的文件

如上所示，安全性本文主要用冒号分为三个字段，这三个字段的意义为:

Identify:role:type

身份识别:角色:类型

三个字段的意义仔细的说明:

* 身份识别 (Identify):

相当于账号方面的身份识别!主要的身份识别常见有底下几种常见的类型:

+ unconfined_u:不受限的用户，也就是说，该文件来自于不受限的进程所产生的!一般来说，我们使用可登 入账号来取得 bash 之后， 预设的 bash 环境是不受 SELinux 管制的~因为 bash 并不是什么特别的网络服务!因此，在这个不受 SELinux 所限制的 bash 进程所产生的文件，其身份识别大多就是 unconfined_u 这个『不受限』用户啰!

+ system_u:系统用户，大部分就是系统自己产生的文件啰!

如果是系统或软件本身所提供的文件，大多就是 system_u 这个身份名称，而如果是 我们用户透过 bash 自己建立的文件，大多则是不受限的 unconfined_u 身份~如果是网络服务 所产生的文件，或者是系统服务运作过程产生的文件，则大部分的识别就会是 system_u

因此你看上面的三个文件中，系统安装 主动产生的 anaconda-ks.cfs 及 initial-setup-ks.cfg 就会是 system_u，而我们自己从网络上面抓 下来的 regular_express.txt 就会是 unconfined_u 这个识别

* 角色 (Role):

透过角色字段，我们可以知道这个资料是属于进程、文件资源还是代表使用者。一般的角色有:

+ object_r:代表的是文件或目录等文件资源，这应该是最常见的啰;

+ system_r:代表的就是进程啦!不过，一般使用者也会被指定成为 system_r 喔!

* 类型 (Type) (最重要!):

在预设的 targeted 政策中， Identify 与 Role 字段基本上是不重要的!重要的在于这个类型 (type) 字段! 基本上，一个主体进程能不能读取到这个文件资源，与类型字段有关!而类型字 段在文件与进程的定义不太相同，分别是:

+ type:在文件资源 (Object) 上面称为类型 (Type);

+ domain:在主体进程 (Subject) 则称为领域 (domain) 了!

domain 需要与 type 搭配，则该进程才能够顺利的读取文件资源啦!

---

* 进程与文件 SELinux type 字段的相关性

首先我们来瞧瞧主体进程在这三个字段的意义为何!透过身份识别与角 色字段的定义， 我们可以约略知道某个进程所代表的意义喔!先来动手瞧一瞧目前系统中的进程在 SELinux 底下的安全本文为何?

再来观察一下系统『进程的 SELinux 相关信息』

[root@study ~]# ps -eZ

LABEL PID TTY TIME CMD

system_u:system_r:init_t:s0 1 ? 00:00:03 systemd

system_u:system_r:kernel_t:s0 2 ? 00:00:00 kthreadd

system_u:system_r:kernel_t:s0 3 ? 00:00:00 ksoftirqd/0

.....(中間省略).....

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 31513 ? 00:00:00 sshd

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 31535 pts/0 00:00:00 bash

基本上进程主要就分为两大类，一种是系统有受限的 system_u:system_r，另一种则可能是用户自己的，

比较不受限的进程 (通常是本机用户自己执行的程序)，亦即是 unconfined_u:unconfined_r 这两种!

基本上，这些对应资料在 targeted 政策下的对应如下:

|身份识别|角色|该对应在 targeted 的意义|
|--|--|--|
|unconfined_u|unconfined_r|一般可登入使用者的进程啰!比较没有受限的进程之意!大多数都是用户已经顺利 登入系统 (不论是网络还是本机登入来取得可用的 shell) 后， 所用来操作系统的 进程!如 bash, X window 相关软件等。|
|system_u|system_r|由于为系统账号，因此是非交谈式的系统运作进程，大多数的系统进程均是这种类型!|

如上所述，在预设的 target 政策下，其实最重要的字段是类型字段 (type)， 主体与目标之间是 否具有可以读写的权限，与进程的 domain 及文件的 type 有关!

这两者的关系我们可以使用 crond 以及他的配置文件来说明! 亦即是 /usr/sbin/crond, /etc/crontab, /etc/cron.d 等文件来说明。 首先，看 看这几个咚咚的安全性本文内容先:

1. 先看看 crond 这个『进程』的安全本文内容:

[root@study ~]# ps -eZ | grep cron

system_u:system_r:crond_t:s0-s0:c0.c1023 1338 ? 00:00:01 crond

system_u:system_r:crond_t:s0-s0:c0.c1023 1340 ? 00:00:00 atd

这个安全本文的类型名称为 crond_t 格式!

2. 再来瞧瞧执行档、配置文件等等的安全本文内容为何!

[root@study ~]# ll -Zd /usr/sbin/crond /etc/crontab /etc/cron.d

drwxr-xr-x. root root system_u:object_r:system_cron_spool_t:s0 /etc/cron.d

-rw-r--r--. root root system_u:object_r:system_cron_spool_t:s0 /etc/crontab

-rwxr-xr-x. root root system_u:object_r:crond_exec_t:s0 /usr/sbin/crond

当我们执行 /usr/sbin/crond 之后，这个程序变成的进程的 domain 类型会是 crond_t 这一个~而这个 crond_t 能够读取的配置文件则为 system_cron_spool_t 这种的类型。因此不论 /etc/crontab, /etc/cron.d 以及 /var/spool/cron 都会是相关的 SELinux 类型 (/var/spool/cron 为 user_cron_spool_t)。 文字看起 来不太容易了解，我们使用图示来说明这几个东西的关系!

![主体进程取得的 domain 与目标文件资源的 type 相互关系以 crond 为例](http://images2017.cnblogs.com/blog/1254925/201710/1254925-20171030105750918-882918400.png)

上图的意义我们可以这样看的:

1. 首先，我们触发一个可执行的目标文件，那就是具有 crond_exec_t 这个类型的 /usr/sbin/crond 文件;
2. 该文件的类型会让这个文件所造成的主体进程 (Subject) 具有 crond 这个领域 (domain)， 我们的政策针对这个领域已经制定了许多规则，其中包括这个领域可以读取的目标资源类型;
3. 由于 crond domain 被设定为可以读取 system_cron_spool_t 这个类型的目标文件 (Object)， 因此你的配置文件放到 /etc/cron.d/ 目录下，就能够被 crond 那支进程所读取了;
4. 但最终能不能读到正确的资料，还得要看 rwx 是否符合 Linux 权限的规范!

上述的流程告诉我们几个重点，第一个是政策内需要制订详细的 domain/type 相关性;第二个是若文 件的 type 设定错误， 那么即使权限设定为 rwx 全开的 777 ，该主体进程也无法读取目标文件资 源。

让我们来做个测试练习吧!

万一你的 crond 配置文件的 SELinux 并 不是 system_cron_spool_t 时， 该配置文件真的可以顺利的被读取运作吗?来看看底下的范例!

1. 先假设你因为不熟的缘故，因此是在『root 家目录』建立一个如下的 cron 设定:

[root@study ~]# vim checktime

10 * * * * root sleep 60s

2. 检查后才发现文件放错目录了，又不想要保留副本，因此使用 mv 移动到正确目录:

[root@study ~]# mv checktime /etc/cron.d

[root@study ~]# ll /etc/cron.d/checktime

-rw-r--r--. 1 root root 27 Aug 7 18:41 /etc/cron.d/checktime

仔细看喔，权限是 644 ，确定没有问题!任何进程都能够读取喔!

3. 强制重新启动 crond ，然后偷看一下登录档，看看有没有问题发生!

[root@study ~]# systemctl restart crond

[root@study ~]# tail /var/log/cron

Aug 7 18:46:01 study crond[28174]: ((null)) Unauthorized SELinux context=system_u:system_r: system_cronjob_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:admin_home_t:s0(/etc/cron.d/checktime)

Aug 7 18:46:01 study crond[28174]: (root) FAILED (loading cron table)

上面的意思是，有错误!因为原本的安全本文与文件的实际安全本文无法搭配的缘故!

从上面的测试案例来看，我们的配置文件确实没有办法被 crond 这个服务所读取喔!而原 因在登录档内就有说明， 主要就是来自 SELinux 安全本文 (context) type 的不同所致喔!

### SELinux 三种模式的启动、关闭与观察

并非所有的 Linux distributions 都支持 SELinux 的，所以你必须要先观察一下你的系统版本为何! 鸟哥这里介绍的 CentOS 7.x 本身就有支持 SELinux 啦!所以你不需要自行编译 SELinux 到你的 Linux 核心中! 目前 SELinux 依据启动与否，共有三种模式，分别如下:

* enforcing:强制模式，代表 SELinux 运作中，且已经正确的开始限制 domain/type 了;

* permissive:宽容模式:代表 SELinux 运作中，不过仅会有警告讯息并不会实际限制 domain/type 的存取。这种模式可以运来作为 SELinux 的 debug 之用;

* disabled:关闭，SELinux 并没有实际运作。

主体进程需要经过政策规则、安全本文 比对之后，加上 rwx 的权限规范， 若一切合理才会让进程顺利的读取文件。那么这个 SELinux 的三种模式与上面谈到的政策规则、安全本文的关系为何呢?我们还是使用图标加上流程来让大家理 解一下:

![SELinux 的三种类型与实际运作流程图示意](http://images2017.cnblogs.com/blog/1254925/201710/1254925-20171030111318996-756944949.png)

就如上图所示，首先，你得要知道，并不是所有的进程都会被 SELinux 所管制，因此最左边会出现 一个所谓的『有受限的进程主体』!那如何观察有没有受限 (confined )呢? 很简单啊!就透过 ps -eZ 去撷取!举例来说，我们来找一找 crond 与 bash 这两只进程是否有被限制吧?

[root@study ~]# ps -eZ | grep -E 'cron|bash'

system_u:system_r:crond_t:s0-s0:c0.c1023 1340 ? 00:00:00 atd

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 13888 tty2 00:00:00 bash

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 28054 pts/0 00:00:00 bash

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 28094 pts/0 00:00:00 bash

system_u:system_r:crond_t:s0-s0:c0.c1023 28174 ? 00:00:00 crond

在目前tartget这个政策底下，只有第三个类型 (type) 字段会有影响，因此我们上表 仅列出第三个字段的数据而已。 我们可以看到， crond 确实是有受限的主体进程，而 bash 因为是 本机进程，因此就是不受限 (unconfined_t) 的类型!也就是说， bash 是不需要经过图 16.5.4 的流 程，而是直接去判断 rwx 而已。

了解了受限的主体进程的意义之后，再来了解一下，三种模式的运作吧!首先，如果是 Disabled 的 模式，那么 SELinux 将不会运作，当然受限的进程也不会经过 SELinux ， 也是直接去判断 rwx 而 已。那如果是宽容 (permissive) 模式呢?这种模式也是不会将主体进程抵挡 (所以箭头是可以直接穿 透的喔!)，不过万一没有通过政策规则，或者是安全本文的比对时， 那么该读写动作将会被纪录起 来 (log)，可作为未来检查问题的判断依据。

至于最终那个 Enforcing 模式，就是实际将受限主体进入规则比对、安全本文比对的流程，若失败， 就直接抵挡主体进程的读写行为，并且将他记录下来。 如果通通没问题，这才进入到 rwx 权限的判断!这样可以理解三种模式的行为了吗?

怎么知道目前的 SELinux 模式呢?就透过 getenforce 吧!

[root@study ~]# getenforce

Enforcing <==诺!就显示出目前的模式为 Enforcing 啰!

另外，我们又如何知道 SELinux 的政策 (Policy) 为何呢?这时可以使用 sestatus 来观察:

[root@study ~]# sestatus [-vb]

选项与参数:

-v :检查列于 /etc/sestatus.conf 内的文件与进程的安全性本文内容;

-b :将目前政策的规则布尔值列出，亦即某些规则 (rule) 是否要启动 (0/1) 之意;

范例一:列出目前的 SELinux 使用哪个政策 (Policy)?

[root@study ~]# sestatus

SELinux status: enabled <是否启动 SELinux

SELinuxfs mount: /sys/fs/selinux <SELinux 的相关文件数据挂载点

SELinux root directory: /etc/selinux <SELinux 的根目录所在

Loaded policy name: targeted <目前的政策为何?

Current mode: enforcing <目前的模式

Mode from config file: enforcing <目前配置文件内规范的 SELinux 模式

Policy MLS status: enabled <是否含有 MLS 的模式机制

Policy deny_unknown status: allowed <是否预设抵挡未知的主体进程

Max kernel policy version: 28

目前是启动的，而且是 Enforcing 模式，而由配置文件查询得知亦为 Enforcing 模式。 此 外，目前的预设政策为 targeted 这一个。你应该要有疑问的是，SELinux 的配置文件是哪个文件啊? 其实就是 /etc/selinux/config 这个文件喔!我们来看看内容:

[root@study ~]# vim /etc/selinux/config

SELINUX=enforcing <调整 enforcing|disabled|permissive

SELINUXTYPE=targeted <目前仅有 targeted, mls, minimum 三种政策

---

* SELinux 的启动与关闭

注意的是，如果改变了政策则需要重新启动;如果由 enforcing 或 permissive 改成 disabled ，或由 disabled 改成其他两个，那也必须要重新启动。因为 SELinux 是整合到核心里面去的，你只可以在 SELinux 运作下切换成为强制 (enforcing) 或宽容 (permissive) 模式，不能够直接关闭 SELinux 的!如果刚刚你发现 getenforce 出现 disabled 时，请到上述文件 修改成为 enforcing 然后重新启动吧!

如果你已经在 Enforcing 的模式，但是可能由于一些设定的问题导致 SELinux 让某些服务无法正常 的运作，此时你可以将 Enforcing 的模式改为宽容 (permissive) 的模式，让 SELinux 只会警告无法顺利联机的讯息，而不是直接抵挡主体进程的读取权限。让 SELinux 模式在 enforcing 与 permissive 之间切换的方法为:

[root@study ~]# setenforce [0|1]

选项与参数:

0 :转成 permissive 宽容模式;

1 :转成 Enforcing 强制模式

范例一:将 SELinux 在 Enforcing 与 permissive 之间切换与观察

[root@study ~]# setenforce 0

[root@study ~]# getenforce

Permissive

[root@study ~]# setenforce 1

[root@study ~]# getenforce

Enforcing

请注意， setenforce 无法在 Disabled 的模式底下进行模式的切换喔!

### SELinux 政策内的规则管理

SELinux 的三种模式是会影响到主体进程的放行与否。 如果是进入 Enforcing 模式，那么接着下来会影响到主体进程的，当然就是第二关: target 政策内的各项规则 (rules) 』了!

---

* SELinux 各个规则的布尔值查询 getsebool

如果想要查询系统上面全部规则的启动与否 (on/off，亦即布尔值)，很简单的透过 sestatus -b 或 getsebool -a 均可!

[root@study ~]# getsebool [-a] [规则的名称]

选项与参数:

-a :列出目前系统上面的所有 SELinux 规则的布尔值为开启或关闭值

范例一:查询本系统内所有的布尔值设定状况

[root@study ~]# getsebool -a

abrt_anon_write --> off

abrt_handle_event --> off

....(中間省略)....

cron_can_relabel --> off # 这个跟 cornd 比较有关!

cron_userdomain_transition --> on

....(中間省略)....

httpd_enable_homedirs --> off # 这当然就是跟网页，亦即 http 有关的啰!

....(底下省略)....

这么多的 SELinux 规则喔!每个规则后面都列出现在是允许放行还是不许放行的布尔值喔!

---

* SELinux 各个规则规范的主体进程能够读取的文件 SELinux type 查询 seinfo, sesearch

每个规则内到底是在限制什么东西?如果你想要知道 的话，那就得要使用 seinfo 等工具!

[root@study ~]# seinfo [-Atrub]

选项与参数:

-A :列出 SELinux 的状态、规则布尔值、身份识别、角色、类别等所有信息

-u :列出 SELinux 的所有身份识别 (user) 种类

-r :列出 SELinux 的所有角色 (role) 种类

-t :列出 SELinux 的所有类别 (type) 种类

-b :列出所有规则的种类 (布尔值)

范例一:列出 SELinux 在此政策下的统计状态

[root@study ~]# seinfo

Statistics for policy file: /sys/fs/selinux/policy

Policy Version & Type: v.28 (binary, mls)

Classes: 83 Permissions: 255

Sensitivities: 1 Categories: 1024

Types: 4620 Attributes: 357

Users: 8 Roles: 14

Booleans: 295 Cond. Expr.: 346

Allow: 102249 Neverallow: 0

Auditallow: 160 Dontaudit: 8413

Type_trans: 16863 Type_change: 74

Type_member: 35 Role allow: 30

Role_trans: 412 Range_trans: 5439

....(底下省略)....

从上面我们可以看到这个政策是 targeted ，此政策的安全本文类别有 4620 个;

而各种 SELinux 的规则 (Booleans) 共制订了 295 条!

那我们也知道 crond 这个 进程的 type 是 crond_t ， 能不能找一下 crond_t 能够读取的文件 SELinux type 有哪些呢?

[root@study ~]# sesearch [-A] [-s 主体类别] [-t 目标类别] [-b 布尔值]

选项与参数:

-A :列出后面数据中，允许『读取或放行』的相关数据

-t :后面还要接类别，例如 -t httpd_t

-b :后面还要接 SELinux 的规则，例如 -b httpd_enable_ftp_server

范例一:找出 crond_t 这个主体进程能够读取的文件 SELinux type

[root@study ~]# sesearch -A -s crond_t | grep spool

allow crond_t system_cron_spool_t : file { ioctl read write create getattr ..

allow crond_t system_cron_spool_t : dir { ioctl read getattr lock search op..

allow crond_t user_cron_spool_t : file { ioctl read write create getattr se..

allow crond_t user_cron_spool_t : dir { ioctl read write getattr lock add_n..

allow crond_t user_cron_spool_t : lnk_file { read getattr } ;

allow 后面接主体进程以及文件的 SELinux type，上面的数据是撷取出来的，

意思是说，crond_t 可以读取 system_cron_spool_t 的文件/目录类型~等等!

范例二:找出 crond_t 是否能够读取 /etc/cron.d/checktime 这个我们自定义的配置文件?

[root@study ~]# ll -Z /etc/cron.d/checktime

-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 /etc/cron.d/checktime

两个重点，一个是 SELinux type 为 admin_home_t，一个是文件 (file)

[root@study ~]# sesearch -A -s crond_t | grep admin_home_t

allow domain admin_home_t : dir { getattr search open } ;

allow domain admin_home_t : lnk_file { read getattr } ;

allow crond_t admin_home_t : dir { ioctl read getattr lock search open } ;

allow crond_t admin_home_t : lnk_file { read getattr } ;

仔细看!看仔细~虽然有 crond_t admin_home_t 存在，但是这是总体的信息，

并没有针对某些规则的寻找~所以还是不确定 checktime 能否被读取。但是，基本上就是 SELinux

type 出问题~因此才会无法读取的!

所以，现在我们知道 /etc/cron.d/checktime 这个我们自己复制过去的文件会没有办法被读取的原因， 就是因为 SELinux type 错误啦! 根本就无法被读取~好~那现在我们来查一查，那 getsebool -a 里 面看到的 httpd_enable_homedirs 到底是什么?又是规范了哪些主体进程能够读取的 SELinux type 呢?

[root@study ~]# semanage boolean -l | grep httpd_enable_homedirs

SELinux boolean State Default Description

httpd_enable_homedirs (off , off) Allow httpd to enable homedirs

httpd_enable_homedirs 的功能是允许 httpd 进程去读取用户家目录的意思~

[root@study ~]# sesearch -A -b httpd_enable_homedirs

范例三:列出 httpd_enable_homedirs 这个规则当中，主体进程能够读取的文件 SELinux type

Found 43 semantic av rules:

allow httpd_t home_root_t : dir { ioctl read getattr lock search open } ;

allow httpd_t home_root_t : lnk_file { read getattr } ;

allow httpd_t user_home_type : dir { getattr search open } ;

allow httpd_t user_home_type : lnk_file { read getattr } ;

....(后面省略)....

从上面的数据才可以理解，在这个规则中，主要是放行 httpd_t 能否读取用户家目录的文件!

所以，如果这个规则没有启动，基本上， httpd_t 这种进程就无法读取用户家目录下的文件!

----

* 修改 SELinux 规则的布尔值 setsebool

那么如果查询到某个 SELinux rule，并且以 sesearch 知道该规则的用途后，想要关闭或启动他，又该如何处置?

[root@study ~]# setsebool [-P] 『规则名称』 [0|1]

选项与参数:

-P :直接将设定值写入配置文件，该设定数据未来会生效的!

范例一:查询 httpd_enable_homedirs 这个规则的状态，并且修改这个规则成为不同的布尔值

[root@study ~]# getsebool httpd_enable_homedirs

httpd_enable_homedirs --> off <==结果是 off ，依题意给他启动看看!

[root@study ~]# setsebool -P httpd_enable_homedirs 1 # 会跑很久很久!请耐心等待!

[root@study ~]# getsebool httpd_enable_homedirs

httpd_enable_homedirs --> on

这个 setsebool 最好记得一定要加上 -P 的选项!因为这样才能将此设定写入配置文件!

### SELinux 安全本文的修改

现在我们知道 SELinux 对受限的主体进程有没有影响，第一关考虑 SELinux 的三种类型，第二关考虑 SELinux 的政策规则是否放行，第三关则是开始比对 SELinux type 啦!

---

* 使用 chcon 手动修改文件的 SELinux type

[root@study ~]# chcon [-R] [-t type] [-u user] [-r role] 文件

[root@study ~]# chcon [-R] --reference=范例文件 文件

选项与参数:

-R :连同该目录下的次目录也同时修改;

-t :后面接安全性本文的类型字段!例如 httpd_sys_content_t ;

-u :后面接身份识别，例如 system_u; (不重要)

-r :后面街角色，例如 system_r; (不重要)

-v :若有变化成功，请将变动的结果列出来 --reference=范例文件:拿某个文件当范例来修改后续接的文件的类型!

范例一:查询一下 /etc/hosts 的 SELinux type，并将该类型套用到 /etc/cron.d/checktime 上

[root@study ~]# ll -Z /etc/hosts

-rw-r--r--. root root system_u:object_r:net_conf_t:s0 /etc/hosts

[root@study ~]# chcon -v -t net_conf_t /etc/cron.d/checktime

changing security context of ‘/etc/cron.d/checktime’

[root@study ~]# ll -Z /etc/cron.d/checktime

-rw-r--r--. root root unconfined_u:object_r:net_conf_t:s0 /etc/cron.d/checktime

范例二:直接以 /etc/shadow SELinux type 套用到 /etc/cron.d/checktime 上!

[root@study ~]# chcon -v --reference=/etc/shadow /etc/cron.d/checktime

[root@study ~]# ll -Z /etc/shadow /etc/cron.d/checktime

-rw-r--r--. root root system_u:object_r:shadow_t:s0 /etc/cron.d/checktime

----------. root root system_u:object_r:shadow_t:s0 /etc/shadow

上面的练习『都没有正确的解答!』因为正确的 SELinux type 应该就是要以 /etc/cron.d/ 底下的文件 为标准来处理才对啊~ 好了~既然如此~能不能让 SELinux 自己解决默认目录下的 SELinux type 呢?可以!就用 restorecon 吧!

---

* 使用 restorecon 让文件恢复正确的 SELinux type

[root@study ~]# restorecon [-Rv] 文件或目录

选项与参数:

-R :连同次目录一起修改;

-v :将过程显示到屏幕上

范例三:将 /etc/cron.d/ 底下的文件通通恢复成预设的 SELinux type!

[root@study ~]# restorecon -Rv /etc/cron.d

restorecon reset /etc/cron.d/checktime context system_u:object_r:shadow_t:s0-> system_u:object_r:system_cron_spool_t:s0

表示将 checktime 由 shadow_t 改为 system_cron_spool_t

范例四:重新启动 crond 看看有没有正确启动 checktime 啰!?

[root@study ~]# systemctl restart crond

[root@study ~]# tail /var/log/cron

再去瞧瞧这个 /var/log/cron 的内容，应该就没有错误讯息了

---

* semanage 默认目录的安全性本文查询与修改

那要如何 (1)查询预设的 SELinux type 以及 (2)如何增加/修改/删除预设的 SELinux type 呢?很简单~透过 semanage 即可!他是这样 使用的:

[root@study ~]# semanage {login|user|port|interface|fcontext|translation} -l

[root@study ~]# semanage fcontext -{a|d|m} [-frst] file_spec

选项与参数:

fcontext :主要用在安全性本文方面的用途， -l 为查询的意思;

-a :增加的意思，你可以增加一些目录的默认安全性本文类型设定;

-m :修改的意思;

-d :删除的意思。

范例一:查询一下 /etc /etc/cron.d 的预设 SELinux type 为何?

[root@study ~]# semanage fcontext -l | grep -E '^/etc |^/etc/cron'

SELinux fcontext type Context

/etc all files system_u:object_r:etc_t:s0

/etc/cron.d(/.*)? all files system_u:object_r:system_cron_spool_t:s0

看到上面输出的最后一行，那也是为啥我们直接使用 vim 去 /etc/cron.d 底下建立新文件时，预设的 SELinux type 就是正确的! 同时，我们也会知道使用 restorecon 回复正确的 SELinux type 时，系 统会去判断默认的类型为何的依据。现在让我们来想一想， 如果 (当然是假的!不可能这么干) 我 们要建立一个 /srv/mycron 的目录，这个目录默认也是需要变成 system_cron_spool_t 时， 我们应该 要如何处理呢?基本上可以这样作:

1. 先建立 /srv/mycron 同时在内部放入配置文件，同时观察 SELinux type

[root@study ~]# mkdir /srv/mycron

[root@study ~]# cp /etc/cron.d/checktime /srv/mycron

[root@study ~]# ll -dZ /srv/mycron /srv/mycron/checktime

drwxr-xr-x. root root unconfined_u:object_r:var_t:s0 /srv/mycron

-rw-r--r--. root root unconfined_u:object_r:var_t:s0 /srv/mycron/checktime

2. 观察一下上层 /srv 的 SELinux type

[root@study ~]# semanage fcontext -l | grep '^/srv'

SELinux fcontext type Context

/srv all files system_u:object_r:var_t:s0

怪不得 mycron 会是 var_t 啰!

3. 将 mycron 默认值改为 system_cron_spool_t 啰!

[root@study ~]# semanage fcontext -a -t system_cron_spool_t "/srv/mycron(/.)?"

[root@study ~]# semanage fcontext -l | grep '^/srv/mycron'

SELinux fcontext type Context

/srv/mycron(/.)? all files system_u:object_r:system_cron_spool_t:s0

4. 恢复 /srv/mycron 以及子目录相关的 SELinux type 喔!

[root@study ~]# restorecon -Rv /srv/mycron

[root@study ~]# ll -dZ /srv/mycron /srv/mycron/*

drwxr-xr-x. root root unconfined_u:object_r:system_cron_spool_t:s0 /srv/mycron

-rw-r--r--. root root unconfined_u:object_r:system_cron_spool_t:s0 /srv/mycron/checktime

有了默认值，未来就不会不小心被乱改了!这样比较妥当些~

如上所示， 你可 以使用 semanage 来查询所有的目录默认值，也能够使用他来增加默认值的设定!

### 一个网络服务案例及登录文件协助

CentOS 7.x 有提供 几支侦测的服务在登录 SELinux 产生的错误喔!那就是 auditd 与 setroubleshootd。

---

* setroubleshoot --> 错误讯息写入 /var/log/messages

troubleshoot 大 家都知道是错误克服，因此这个 setroubleshoot 自然就得要启动他啦!这个服务会将关于 SELinux 的 错误讯息与克服方法记录到 /var/log/messages 与 /var/log/setroubleshoot/* 里头。这玩意儿总共需要两个软件，分别是 setroublshoot 与 setroubleshoot-server，如果你没有安装，请自行使用 yum 安装吧!

此外，原本的 SELinux 信息本来是以两个服务来记录的，分别是 auditd 与 setroubleshootd。既然是 同样的信息，因此 CentOS 6.x (含 7.x) 以后将两者整合在 auditd 当中啦!所以，并没有
setroubleshootd 的服务存在了喔!因此，当你安装好了 setroubleshoot-server 之后，请记得要重新启 动 auditd，否则 setroubleshootd 的功能不会被启动的。

tips 事实上，CentOS 7.x 对 setroubleshootd 的运作方式是:(1)先由 auditd 去呼叫 audispd服务， (2)然后 audispd 服务去启动 sedispatch 程序， (3)sedispatch 再将原本的 auditd 讯息转成 setroubleshootd 的讯息，进一步储存下来的!

---

* 实例状况说明:透过 vsftpd 这个 FTP 服务器来存取系统上的文件

在 CentOS 7.x 的环境下，达成 FTP 的默认服务器软件主要是 vsftpd 这一支!

首先，你得要知道，客户端需要使用『FTP 账 号登入 FTP 服务器』才行!而有一个称为『匿名 (anonymous) 』的账号可以登入系统! 但是这个 匿名的账号登入后，只能存取某一个特定的目录，而无法脱离该目录~!

在 vsftpd 中，一般用户与匿名者的家目录说明如下:

* 匿名者:如果使用浏览器来联机到 FTP 服务器的话，那预设就是使用匿名者登入系统。而匿名者的家目录 默认是在 /var/ftp 当中! 同时，匿名者在家目录下只能下载数据，不能上传数据到 FTP 服务器。同时， 匿名者无法离开 FTP 服务器的 /var/ftp 目录喔!

* 一般 FTP 账号:在预设的情况下，所有 UID 大于 1000 的账号，都可以使用 FTP 来登入系统! 而登入 系统之后，所有的账号都能够取得自己家目录底下的文件数据!当然预设是可以上传、下载文件的!

为了避免跟之前章节的用户产生误解的情况，这里我们先建立一个名为 ftptest 的账号，且账号密码为 myftp123， 先来建立一下吧!

[root@study ~]# useradd -s /sbin/nologin ftptest

[root@study ~]# echo "myftp123" | passwd --stdin ftptest

接下来当然就是安装 vsftpd 这只服务器软件，同时启动这只服务，另外，我们也希望未来开机都能 够启动这只服务!

[root@study ~]# yum install /mnt/Packages/vsftpd-3*

[root@study ~]# systemctl start vsftpd

[root@study ~]# systemctl enable vsftpd

[root@study ~]# netstat -tlnp

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1326/sshd

tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2349/master

tcp6 0 0 :::21 ::