## 16.5 SELinux 初探
从进入了 CentOS 5.x 之后的 CentOS 版本中 (当然包括 CentOS 7),SELinux 已经是个非常完备的核心模块了!尤其 CentOS 提供了很多管理 SELinux 的指令与机制, 因此在整体架构上面是单纯且容易操作管理的!所以,在没有自行开发网络服务软件以及使用其他第三方协力软件的情况下, 也就是全部使用 CentOS 官方提供的软件来使用我们服务器的情况下,建议大家不要关闭 SELinux 了喔! 让我们来仔细的玩玩这家伙吧!
### 16.5.1 什么是 SELinux
什么是 SELinux 呢?其实他是“ Security Enhanced Linux ”的缩写,字面上的意义就是安全强化的 Linux 之意!那么所谓的“安全强化”是强化哪个部分? 是网络资安还是权限管理?下面就让我们来谈谈吧!
* 当初设计的目标:避免资源的误用
SELinux 是由美国国家安全局 (NSA) 开发的,当初开发这玩意儿的目的是因为很多企业界发现, 通常系统出现问题的原因大部分都在于“内部员工的资源误用”所导致的,实际由外部发动的攻击反而没有这么严重。 那么什么是“员工资源误用”呢?举例来说,如果有个不是很懂系统的系统管理员为了自己设置的方便,将网页所在目录 /var/www/html/ 的权限设置为 drwxrwxrwx 时,你觉得会有什么事情发生?
现在我们知道所有的系统资源都是通过程序来进行存取的,那么 /var/www/html/ 如果设置为 777 , 代表所有程序均可对该目录存取,万一你真的有启动 WWW 服务器软件,那么该软件所触发的程序将可以写入该目录, 而该程序却是对整个 Internet 提供服务的!只要有心人接触到这支程序,而且该程序刚好又有提供使用者进行写入的功能, 那么外部的人很可能就会对你的系统写入些莫名其妙的东西!那可真是不得了!一个小小的 777 问题可是大大的!
为了控管这方面的权限与程序的问题,所以美国国家安全局就着手处理操作系统这方面的控管。 由于 Linux 是自由软件,程序码都是公开的,因此她们便使用 Linux 来作为研究的目标, 最后更将研究的结果整合到 Linux 核心里面去,那就是 SELinux 啦!所以说, SELinux 是整合到核心的一个模块喔! 更多的 SELinux 相关说明可以参考:
* [http://www.nsa.gov/research/selinux/](http://www.nsa.gov/research/selinux/)
这也就是说:其实 SELinux 是在进行程序、文件等细部权限设置依据的一个核心模块! 由于启动网络服务的也是程序,因此刚好也能够控制网络服务能否存取系统资源的一道关卡! 所以,在讲到 SELinux 对系统的存取控制之前,我们得先来回顾一下之前谈到的系统文件权限与使用者之间的关系。 因为先谈完这个你才会知道为何需要 SELinux 的啦!
* 传统的文件权限与帐号关系:自主式存取控制, DAC
我们[第十三章](../Text/index.html)的内容,知道系统的帐号主要分为系统管理员 (root) 与一般用户,而这两种身份能否使用系统上面的文件资源则与 rwx 的权限设置有关。 不过你要注意的是,各种权限设置对 root 是无效的。因此,当某个程序想要对文件进行存取时, 系统就会根据该程序的拥有者/群组,并比对文件的权限,若通过权限检查,就可以存取该文件了。
这种存取文件系统的方式被称为“自主式存取控制 (Discretionary Access Control, DAC)”,基本上,就是依据程序的拥有者与文件资源的 rwx 权限来决定有无存取的能力。 不过这种 DAC 的存取控制有几个困扰,那就是:
* root 具有最高的权限:如果不小心某支程序被有心人士取得, 且该程序属于 root 的权限,那么这支程序就可以在系统上进行任何资源的存取!真是要命!
* 使用者可以取得程序来变更文件资源的存取权限:如果你不小心将某个目录的权限设置为 777 ,由于对任何人的权限会变成 rwx ,因此该目录就会被任何人所任意存取!
这些问题是非常严重的!尤其是当你的系统是被某些漫不经心的系统管理员所掌控时!她们甚至觉得目录权限调为 777 也没有什么了不起的危险哩...
* 以政策规则订定特定程序读取特定文件:委任式存取控制, MAC
现在我们知道 DAC 的困扰就是当使用者取得程序后,他可以借由这支程序与自己默认的权限来处理他自己的文件资源。 万一这个使用者对 Linux 系统不熟,那就很可能会有资源误用的问题产生。为了避免 DAC 容易发生的问题,因此 SELinux 导入了委任式存取控制 (Mandatory Access Control, MAC) 的方法!
委任式存取控制 (MAC) 有趣啦!他可以针对特定的程序与特定的文件资源来进行权限的控管! 也就是说,即使你是 root ,那么在使用不同的程序时,你所能取得的权限并不一定是 root , 而得要看当时该程序的设置而定。如此一来,我们针对控制的“主体”变成了“程序”而不是使用者喔! 此外,这个主体程序也不能任意使用系统文件资源,因为每个文件资源也有针对该主体程序设置可取用的权限! 如此一来,控制项目就细的多了!但整个系统程序那么多、文件那么多,一项一项控制可就没完没了! 所以 SELinux 也提供一些默认的政策 (Policy) ,并在该政策内提供多个规则 (rule) ,让你可以选择是否启用该控制规则!
在委任式存取控制的设置下,我们的程序能够活动的空间就变小了!举例来说, WWW 服务器软件的达成程序为 httpd 这支程序, 而默认情况下, httpd 仅能在 /var/www/ 这个目录下面存取文件,如果 httpd 这个程序想要到其他目录去存取数据时, 除了规则设置要开放外,目标目录也得要设置成 httpd 可读取的模式 (type) 才行喔!限制非常多! 所以,即使不小心 httpd 被 cracker 取得了控制权,他也无权浏览 /etc/shadow 等重要的配置文件喔!
简单的来说,针对 Apache 这个 WWW 网络服务使用 DAC 或 MAC 的结果来说,两者间的关系可以使用下图来说明。 下面这个图示取自 Red Hat 训练教材,真的是很不错~所以被鸟哥借用来说明一下!
![使用 DAC/MAC 产生的不同结果,以 Apache 为例说明](https://box.kancloud.cn/2016-05-13_5735737ab507d.jpg)图16.5.1、使用 DAC/MAC 产生的不同结果,以 Apache 为例说明
左图是没有 SELinux 的 DAC 存取结果,apache 这只 root 所主导的程序,可以在这三个目录内作任何文件的新建与修改~ 相当麻烦~右边则是加上 SELinux 的 MAC 管理的结果,SELinux 仅会针对 Apache 这个“ process ”放行部份的目录, 其他的非正规目录就不会放行给 Apache 使用!因此不管你是谁,就是不能穿透 MAC 的框框!这样有比较了解乎?
### 16.5.2 SELinux 的运行模式
再次的重复说明一下,SELinux 是通过 MAC 的方式来控管程序,他控制的主体是程序, 而目标则是该程序能否读取的“文件资源”!所以先来说明一下这些咚咚的相关性啦![[4]](#ps4)
* 主体 (Subject):
SELinux 主要想要管理的就是程序,因此你可以将“主体”跟本章谈到的 process 划上等号;
* 目标 (Object):
主体程序能否存取的“目标资源”一般就是文件系统。因此这个目标项目可以等文件系统划上等号;
* 政策 (Policy):
由于程序与文件数量庞大,因此 SELinux 会依据某些服务来制订基本的存取安全性政策。这些政策内还会有详细的规则 (rule) 来指定不同的服务开放某些资源的存取与否。在目前的 CentOS 7.x 里面仅有提供三个主要的政策,分别是:
* targeted:针对网络服务限制较多,针对本机限制较少,是默认的政策;
* minimum:由 target 修订而来,仅针对选择的程序来保护!
* mls:完整的 SELinux 限制,限制方面较为严格。建议使用默认的 targeted 政策即可。
* 安全性本文 (security context):
我们刚刚谈到了主体、目标与政策面,但是主体能不能存取目标除了政策指定之外,主体与目标的安全性本文必须一致才能够顺利存取。 这个安全性本文 (security context) 有点类似文件系统的 rwx 啦!安全性本文的内容与设置是非常重要的! 如果设置错误,你的某些服务(主体程序)就无法存取文件系统(目标资源),当然就会一直出现“权限不符”的错误讯息了!
由于 SELinux 重点在保护程序读取文件系统的权限,因此我们将上述的几个说明搭配起来,绘制成下面的流程图,比较好理解:
![SELinux 运行的各元件之相关性](https://box.kancloud.cn/2016-05-13_5735737acbb96.gif)图16.5.2、SELinux 运行的各元件之相关性(本图参考小州老师的上课讲义)
上图的重点在“主体”如何取得“目标”的资源存取权限! 由上图我们可以发现,(1)主体程序必须要通过 SELinux 政策内的规则放行后,就可以与目标资源进行安全性本文的比对, (2)若比对失败则无法存取目标,若比对成功则可以开始存取目标。问题是,最终能否存取目标还是与文件系统的 rwx 权限设置有关喔!如此一来,加入了 SELinux 之后,出现权限不符的情况时,你就得要一步一步的分析可能的问题了!
* 安全性本文 (Security Context)
CentOS 7.x 的 target 政策已经帮我们制订好非常多的规则了,因此你只要知道如何打开/关闭某项规则的放行与否即可。 那个安全性本文比较麻烦!因为你可能需要自行设置文件的安全性本文呢!为何需要自行设置啊? 举例来说,你不也常常进行文件的 rwx 的重新设置吗?这个安全性本文你就将他想成 SELinux 内必备的 rwx 就是了!这样比较好理解啦。
安全性本文存在于主体程序中与目标文件资源中。程序在内存内,所以安全性本文可以存入是没问题。 那文件的安全性本文是记录在哪里呢?事实上,安全性本文是放置到文件的 inode 内的,因此主体程序想要读取目标文件资源时,同样需要读取 inode , 这 inode 内就可以比对安全性本文以及 rwx 等权限值是否正确,而给予适当的读取权限依据。
那么安全性本文到底是什么样的存在呢?我们先来看看 /root 下面的文件的安全性本文好了。 观察安全性本文可使用“ ls -Z ”去观察如下:(注意:你必须已经启动了 SELinux 才行!若尚未启动,这部份请稍微看过一遍即可。下面会介绍如何启动 SELinux 喔!)
```
# 先来观察一下 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 喔!
你也会发现角色的字段最后面使用“ _r ”来结尾!因为是 role 的意思嘛!
* 类型 (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 相互关系](https://box.kancloud.cn/2016-05-13_5735737adcf2e.jpg)图16.5.3、主体程序取得的 domain 与目标文件资源的 type 相互关系以 crond 为例
上图的意义我们可以这样看的:
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 ,该主体程序也无法读取目标文件资源的啦!不过如此一来, 也就可以避免使用者将他的主文件夹设置为 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 的不同所致喔!没办法读就没办法读,先放着~后面再来学怎么处理这问题吧!
### 16.5.3 SELinux 三种模式的启动、关闭与观察
并非所有的 Linux distributions 都支持 SELinux 的,所以你必须要先观察一下你的系统版本为何! 鸟哥这里介绍的 CentOS 7.x 本身就有支持 SELinux 啦!所以你不需要自行编译 SELinux 到你的 Linux 核心中! 目前 SELinux 依据启动与否,共有三种模式,分别如下:
* enforcing:强制模式,代表 SELinux 运行中,且已经正确的开始限制 domain/type 了;
* permissive:宽容模式:代表 SELinux 运行中,不过仅会有警告讯息并不会实际限制 domain/type 的存取。这种模式可以运来作为 SELinux 的 debug 之用;
* disabled:关闭,SELinux 并没有实际运行。
这三种模式跟[图16.5.2](../Text/index.html#fig16.5.2)之间的关系如何呢?我们前面不是谈过主体程序需要经过政策规则、安全本文比对之后,加上 rwx 的权限规范, 若一切合理才会让程序顺利的读取文件吗?那么这个 SELinux 的三种模式与上面谈到的政策规则、安全本文的关系为何呢?我们还是使用图示加上流程来让大家理解一下:
![SELinux 的三种类型与实际运行流程图示意](https://box.kancloud.cn/2016-05-13_5735737b03da1.jpg)图16.5.4、SELinux 的三种类型与实际运行流程图示意
就如上图所示,首先,你得要知道,并不是所有的程序都会被 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
```
如前所述,因为在目前 target 这个政策下面,只有第三个类型 (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 那一行即可喔!
* SELinux 的启动与关闭
上面是默认的政策与启动的模式!你要注意的是,如果改变了政策则需要重新开机;如果由 enforcing 或 permissive 改成 disabled ,或由 disabled 改成其他两个,那也必须要重新开机。这是因为 SELinux 是整合到核心里面去的, 你只可以在 SELinux 运行下切换成为强制 (enforcing) 或宽容 (permissive) 模式,不能够直接关闭 SELinux 的! 如果刚刚你发现 getenforce 出现 disabled 时,请到上述文件修改成为 enforcing 然后重新开机吧!
不过你要注意的是,如果从 disable 转到启动 SELinux 的模式时, 由于系统必须要针对文件写入安全性本文的信息,因此开机过程会花费不少时间在等待重新写入 SELinux 安全性本文 (有时也称为 SELinux Label) ,而且在写完之后还得要再次的重新开机一次喔!你必须要等待粉长一段时间! 等到下次开机成功后,再使用 [getenforce](../Text/index.html#getenforce) 或 [sestatus](../Text/index.html#sestatus) 来观察看看有否成功的启动到 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 的模式下面进行模式的切换喔!
![鸟哥的图示](https://box.kancloud.cn/2016-05-13_5735736501917.gif "鸟哥的图示")
**Tips** 在某些特殊的情况下面,你从 Disabled 切换成 Enforcing 之后,竟然有一堆服务无法顺利启动,都会跟你说在 /lib/xxx 里面的数据没有权限读取,所以启动失败。这大多是由于在重新写入 SELinux type (Relabel) 出错之故,使用 Permissive 就没有这个错误。那如何处理呢?最简单的方法就是在 Permissive 的状态下,使用“ restorecon -Rv / ”重新还原所有 SELinux 的类型,就能够处理这个错误!
### 16.5.4 SELinux 政策内的规则管理
从[图 16.5.4](../Text/index.html#fig16.5.4) 里面,我们知道 SELinux 的三种模式是会影响到主体程序的放行与否。 如果是进入 Enforcing 模式,那么接着下来会影响到主体程序的,当然就是第二关:“ target 政策内的各项规则 (rules) ”了! 好了,那么我们怎么知道目前这个政策里面到底有多少会影响到主体程序的规则呢?很简单,就通过 getsebool 来瞧一瞧即可。
* 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
我们现在知道有这么多的 SELinux 规则,但是每个规则内到底是在限制什么东西?如果你想要知道的话,那就得要使用 seinfo 等工具! 这些工具并没有在我们安装时就安装了,因此请拿出原版光盘,放到光驱,鸟哥假设你将原版光盘挂载到 /mnt 下面,那么接下来这么作, 先安装好我们所需要的软件才行!
```
[root@study ~]# yum install /mnt/Packages/setools-console-*
```
很快的安装完毕之后,我们就可以来使用 seinfo, sesearch 等指令了!
```
[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 条!
```
我们在 16.5.2 里面简单的谈到了几个身份识别 (user) 以及角色 (role) 而已,如果你想要查询目前所有的身份识别与角色,就使用“ seinfo -u ”及“ seinfo -r ”就可以知道了!至于简单的统计数据,就直接输入 seinfo 即可!但是上面还是没有谈到规则相关的东西耶~ 没关系~一个一个来~我们在 16.5.1 的最后面谈到 /etc/cron.d/checktime 的 SELinux type 类型不太对~那我们也知道 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 的选项!因为这样才能将此设置写入配置文件! 这是非常棒的工具组!你一定要知道如何使用 getsebool 与 setsebool 才行!
### 16.5.5 SELinux 安全本文的修改
再次的回到[图 16.5.4](../Text/index.html#fig16.5.4) 上头去,现在我们知道 SELinux 对受限的主体程序有没有影响,第一关考虑 SELinux 的三种类型,第二关考虑 SELinux 的政策规则是否放行,第三关则是开始比对 SELinux type 啦!从刚刚 16.5.4 小节我们也知道可以通过 sesearch 来找到主体程序与文件的 SELinux type 关系! 好,现在总算要来修改文件的 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 的内容,应该就没有错误讯息了
```
其实,鸟哥几乎已经忘了 chcon 这个指令了!因为 restorecon 主动的回复默认的 SELinux type 要简单很多!而且可以一口气恢复整个目录下的文件! 所以,鸟哥建议你几乎只要记得 restorecon 搭配 -Rv 同时加上某个目录这样的指令串即可~修改 SELinux 的 type 就变得非常的轻松啰!
* semanage 默认目录的安全性本文查询与修改
你应该要觉得奇怪,为什么 restorecon 可以“恢复”原本的 SELinux type 呢?那肯定就是有个地方在纪录每个文件/目录的 SELinux 默认类型啰? 没错!是这样~那要如何 (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 的功能很多,不过鸟哥主要用到的仅有 fcontext 这个项目的动作而已。如上所示, 你可以使用 semanage 来查询所有的目录默认值,也能够使用他来增加默认值的设置!如果您学会这些基础的工具, 那么 SELinux 对你来说,也不是什么太难的咚咚啰!
### 16.5.6 一个网络服务案例及登录文件协助
本章在 SELinux 小节当中谈到的各个指令中,尤其是 setsebool, chcon, restorecon 等,都是为了当你的某些网络服务无法正常提供相关功能时, 才需要进行修改的一些指令动作。但是,我们怎么知道哪个时候才需要进行这些指令的修改啊?我们怎么知道系统因为 SELinux 的问题导致网络服务不对劲啊?如果都要靠用户端连线失败才来哭诉,那也太没有效率了!所以,我们的 CentOS 7.x 有提供几支侦测的服务在登录 SELinux 产生的错误喔!那就是 auditd 与 setroubleshootd。
* setroubleshoot --> 错误讯息写入 /var/log/messages
几乎所有 SELinux 相关的程序都会以 se 为开头,这个服务也是以 se 为开头!而 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 的功能不会被启动的。
![鸟哥的图示](https://box.kancloud.cn/2016-05-13_5735736501917.gif "鸟哥的图示")
**Tips** 事实上,CentOS 7.x 对 setroubleshootd 的运行方式是: (1)先由 auditd 去调用 audispd 服务, (2)然后 audispd 服务去启动 sedispatch 程序, (3)sedispatch 再将原本的 auditd 讯息转成 setroubleshootd 的讯息,进一步储存下来的!
```
[root@study ~]# rpm -qa | grep setroubleshoot
setroubleshoot-plugins-3.0.59-1.el7.noarch
setroubleshoot-3.2.17-3.el7.x86_64
setroubleshoot-server-3.2.17-3.el7.x86_64
```
在默认的情况下,这个 setroubleshoot 应该都是会安装的!是否正确安装可以使用上述的表格指令去查询。万一没有安装,请使用 yum install 去安装吧! 再说一遍,安装完毕最好重新启动 auditd 这个服务喔!不过,刚刚装好且顺利启动后, setroubleshoot 还是不会有作用,为啥? 因为我们并没有任何受限的网络服务主体程序在运行啊!所以,下面我们将使用一个简单的 FTP 服务器软件为例,让你了解到我们上头讲到的许多重点的应用!
* 实例状况说明:通过 vsftpd 这个 FTP 服务器来存取系统上的文件
现在的年轻小伙子们传数据都用 line, FB, dropbox, google 云端磁盘等等,不过在网络早期传送大容量的文件,还是以 FTP 这个协定为主! 现在为了速度,经常有 p2p 的软件提供大容量文件的传输,但以鸟哥这个老人家来说,可能 FTP 传送数据还是比较有保障... 在 CentOS 7.x 的环境下,达成 FTP 的默认服务器软件主要是 vsftpd 这一支喔!
详细的 FTP 协定我们在服务器篇再来谈,这里只是简单的利用 vsftpd 这个软件与 FTP 的协定来讲解 SELinux 的问题与错误克服而已。 不过既然要使用到 FTP 协定,一些简单的知识还是得要存在才好!否则等一下我们没有办法了解为啥要这么做! 首先,你得要知道,用户端需要使用“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 这只服务器软件,同时启动这只服务,另外,我们也希望未来开机都能够启动这只服务! 因此需要这样做 (鸟哥假设你的 CentOS 7.x 的原版光盘已经挂载于 /mnt 了喔!):
```
[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 :::* LISTEN 6256/vsftpd
tcp6 0 0 :::22 :::* LISTEN 1326/sshd
tcp6 0 0 ::1:25 :::* LISTEN 2349/master
# 要注意看,上面的特殊字体那行有出现,才代表 vsftpd 这只服务有启动喔!!
```
* 匿名者无法下载的问题
现在让我们来仿真一些 FTP 的常用状态!假设你想要将 /etc/securetty 以及主要的 /etc/sysctl.conf 放置给所有人下载, 那么你可能会这样做!
```
[root@study ~]# cp -a /etc/securetty /etc/sysctl.conf /var/ftp/pub
[root@study ~]# ll /var/ftp/pub
-rw-------. 1 root root 221 Oct 29 2014 securetty # 先假设你没有看到这个问题!
-rw-r--r--. 1 root root 225 Mar 6 11:05 sysctl.conf
```
一般来说,默认要给用户下载的 FTP 文件会放置到上面表格当中的 /var/ftp/pub 目录喔!现在让我们使用简单的终端机浏览器 curl 来观察看看! 看你能不能查询到上述两个文件的内容呢?
```
# 1\. 先看看 FTP 根目录下面有什么文件存在?
[root@study ~]# curl ftp://localhost
drwxr-xr-x 2 0 0 40 Aug 08 00:51 pub
# 确实有存在一个名为 pub 的文件喔!那就是在 /var/ftp 下面的 pub 啰!
# 2\. 再往下看看,能不能看到 pub 内的文件呢?
[root@study ~]# curl ftp://localhost/pub/ # 因为是目录,要加上 / 才好!
-rw------- 1 0 0 221 Oct 29 2014 securetty
-rw-r--r-- 1 0 0 225 Mar 06 03:05 sysctl.conf
# 3\. 承上,继续看一下 sysctl.conf 的内容好了!
[root@study ~]# curl ftp://localhost/pub/sysctl.conf
# System default settings live in /usr/lib/sysctl.d/00-system.conf.
# To override those settings, enter new settings here, or in an /etc/sysctl.d/<name>.conf file
#
# For more information, see sysctl.conf(5) and sysctl.d(5).
# 真的有看到这个文件的内容喔!所以确定是可以让 vsftpd 读取到这文件的!
# 4\. 再来瞧瞧 securetty 好了!
[root@study ~]# curl ftp://localhost/pub/securetty
curl: (78) RETR response: 550
# 看不到耶!但是,基本的原因应该是权限问题喔!因为 vsftpd 默认放在 /var/ftp/pub 内的数据,
# 不论什么 SELinux type 几乎都可以被读取的才对喔!所以要这样处理!
# 5\. 修订权限之后再一次观察 securetty 看看!
[root@study ~]# chmod a+r /var/ftp/pub/securetty
[root@study ~]# curl ftp://localhost/pub/securetty
# 此时你就可以看到实际的文件内容啰!
# 6\. 修订 SELinux type 的内容 (非必备)
[root@study ~]# restorecon -Rv /var/ftp
```
上面这个例子在告诉你,要先从权限的角度来瞧一瞧,如果无法被读取,可能就是因为没有 r 或没有 rx 啰!并不一定是由 SELinux 引起的! 了解乎?好~再来瞧瞧如果是一般帐号呢?如何登陆?
* 无法从主文件夹下载文件的问题分析与解决
我们前面创建了 ftptest 帐号,那如何使用文字界面来登陆呢?就使用如下的方式来处理。同时请注意,因为文字体的 FTP 用户端软件, 默认会将用户丢到根目录而不是主文件夹,因此,你的 URL 可能需要修订一下如下!
```
# 0\. 为了让 curl 这个文字浏览器可以传输数据,我们先创建一些数据在 ftptest 主文件夹
[root@study ~]# echo "testing" > ~ftptest/test.txt
[root@study ~]# cp -a /etc/hosts /etc/sysctl.conf ~ftptest/
[root@study ~]# ll ~ftptest/
-rw-r--r--. 1 root root 158 Jun 7 2013 hosts
-rw-r--r--. 1 root root 225 Mar 6 11:05 sysctl.conf
-rw-r--r--. 1 root root 8 Aug 9 01:05 test.txt
# 1\. 一般帐号直接登陆 FTP 服务器,同时变换目录到主文件夹去!
[root@study ~]# curl ftp://ftptest:myftp123@localhost/~/
-rw-r--r-- 1 0 0 158 Jun 07 2013 hosts
-rw-r--r-- 1 0 0 225 Mar 06 03:05 sysctl.conf
-rw-r--r-- 1 0 0 8 Aug 08 17:05 test.txt
# 真的有数据~看文件最左边的权限也是没问题,所以,来读一下 test.txt 的内容看看
# 2\. 开始下载 test.txt, sysctl.conf 等有权限可以阅读的文件看看!
[root@study ~]# curl ftp://ftptest:myftp123@localhost/~/test.txt
curl: (78) RETR response: 550
# 竟然说没有权限!明明我们的 rwx 是正常没问题!那是否有可能是 SELinux 造成的?
# 3\. 先将 SELinux 从 Enforce 转成 Permissive 看看情况!同时观察登录文件
[root@study ~]# setenforce 0
[root@study ~]# curl ftp://ftptest:myftp123@localhost/~/test.txt
testing
[root@study ~]# setenforce 1 # 确定问题后,一定要转成 Enforcing 啊!
# 确定有数据内容!所以,确定就是 SELinux 造成无法读取的问题~那怎办?要改规则?还是改 type?
# 因为都不知道,所以,就检查一下登录文件看看有没有相关的信息可以提供给我们处理!
[root@study ~]# vim /var/log/messages
Aug 9 02:55:58 station3-39 setroubleshoot: SELinux is preventing /usr/sbin/vsftpd
from lock access on the file /home/ftptest/test.txt. For complete SELinux messages.
run sealert -l 3a57aad3-a128-461b-966a-5bb2b0ffa0f9
Aug 9 02:55:58 station3-39 python: SELinux is preventing /usr/sbin/vsftpd from
lock access on the file /home/ftptest/test.txt.
***** Plugin catchall_boolean (47.5 confidence) suggests ******************
If you want to allow ftp to home dir
Then you must tell SELinux about this by enabling the 'ftp_home_dir' boolean.
You can read 'None' man page for more details.
Do
setsebool -P ftp_home_dir 1
***** Plugin catchall_boolean (47.5 confidence) suggests ******************
If you want to allow ftpd to full access
Then you must tell SELinux about this by enabling the 'ftpd_full_access' boolean.
You can read 'None' man page for more details.
Do
setsebool -P ftpd_full_access 1
***** Plugin catchall (6.38 confidence) suggests **************************
.....(下面省略).....
# 基本上,你会看到有个特殊字体的部份,就是 sealert 那一行。虽然下面已经列出可能的解决方案了,
# 就是一堆底线那些东西。至少就有三个解决方案 (最后一个没列出来),哪种才是正确的?
# 为了了解正确的解决方案,我们还是还执行一下 sealert 那行吧!看看情况再说!
# 4\. 通过 sealert 的解决方案来处理问题
[root@study ~]# sealert -l 3a57aad3-a128-461b-966a-5bb2b0ffa0f9
SELinux is preventing /usr/sbin/vsftpd from lock access on the file /home/ftptest/test.txt.
# 下面说有 47.5% 的概率是由于这个原因所发生,并且可以使用 setsebool 去解决的意思!
***** Plugin catchall_boolean (47.5 confidence) suggests ******************
If you want to allow ftp to home dir
Then you must tell SELinux about this by enabling the 'ftp_home_dir' boolean.
You can read 'None' man page for more details.
Do
setsebool -P ftp_home_dir 1
# 下面说也是有 47.5% 的概率是由此产生的!
***** Plugin catchall_boolean (47.5 confidence) suggests ******************
If you want to allow ftpd to full access
Then you must tell SELinux about this by enabling the 'ftpd_full_access' boolean.
You can read 'None' man page for more details.
Do
setsebool -P ftpd_full_access 1
# 下面说,仅有 6.38% 的可信度是由这个情况产生的!
***** Plugin catchall (6.38 confidence) suggests **************************
If you believe that vsftpd should be allowed lock access on the test.txt 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 vsftpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
# 下面就重要了!是整个问题发生的主因~最好还是稍微瞧一瞧!
Additional Information:
Source Context system_u:system_r:ftpd_t:s0-s0:c0.c1023
Target Context unconfined_u:object_r:user_home_t:s0
Target Objects /home/ftptest/test.txt [ file ]
Source vsftpd
Source Path /usr/sbin/vsftpd
Port <Unknown>
Host station3-39.gocloud.vm
Source RPM Packages vsftpd-3.0.2-9.el7.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.13.1-23.el7.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Permissive
Host Name station3-39.gocloud.vm
Platform Linux station3-39.gocloud.vm 3.10.0-229.el7.x86_64
#1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64
Alert Count 3
First Seen 2015-08-09 01:00:12 CST
Last Seen 2015-08-09 02:55:57 CST
Local ID 3a57aad3-a128-461b-966a-5bb2b0ffa0f9
Raw Audit Messages
type=AVC msg=audit(1439060157.358:635): avc: denied { lock } for pid=5029 comm="vsftpd"
path="/home/ftptest/test.txt" dev="dm-2" ino=141 scontext=system_u:system_r:ftpd_t:s0-s0:
c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
type=SYSCALL msg=audit(1439060157.358:635): arch=x86_64 syscall=fcntl success=yes exit=0
a0=4 a1=7 a2=7fffceb8cbb0 a3=0 items=0 ppid=5024 pid=5029 auid=4294967295 uid=1001 gid=1001
euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=(none) ses=4294967295
comm=vsftpd exe=/usr/sbin/vsftpd subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null)
Hash: vsftpd,ftpd_t,user_home_t,file,lock
```
经过上面的测试,现在我们知道主要的问题发生在 SELinux 的 type 不是 vsftpd_t 所能读取的原因~ 经过仔细观察 test.txt 文件的类型,我们知道他原本就是主文件夹,因此是 user_home_t 也没啥了不起的啊!是正确的~ 因此,分析两个比较可信 (47.5%) 的解决方案后,可能是与 ftp_home_dir 比较有关啊!所以,我们应该不需要修改 SELinux type, 修改的应该是 SELinux rules 才对!所以,这样做看看:
```
# 1\. 先确认一下 SELinux 的模式,然后再瞧一瞧能否下载 test.txt,最终使用处理方式来解决~
[root@study ~]# getenforce
Enforcing
[root@study ~]# curl ftp://ftptest:myftp123@localhost/~/test.txt
curl: (78) RETR response: 550
# 确定还是无法读取的喔!
[root@study ~]# setsebool -P ftp_home_dir 1
[root@study ~]# curl ftp://ftptest:myftp123@localhost/~/test.txt
testing
# OK!太赞了!处理完毕!现在使用者可以在自己的主文件夹上传/下载文件了!
# 2\. 开始下载其他文件试看看啰!
[root@study ~]# curl ftp://ftptest:myftp123@localhost/~/sysctl.conf
# System default settings live in /usr/lib/sysctl.d/00-system.conf.
# To override those settings, enter new settings here, or in an /etc/sysctl.d/<name>.conf file
#
# For more information, see sysctl.conf(5) and sysctl.d(5).
```
没问题喔!通过修改 SELinux rule 的布林值,现在我们就可以使用一般帐号在 FTP 服务来上传/下载数据啰!非常愉快吧! 那万一我们还有其他的目录也想要通过 FTP 来提供这个 ftptest 用户上传与下载呢?往下瞧瞧~
* 一般帐号用户从非正规目录上传/下载文件
假设我们还想要提供 /srv/gogogo 这个目录给 ftptest 用户使用,那又该如何处理呢?假设我们都没有考虑 SELinux , 那就是这样的情况:
```
# 1\. 先处理好所需要的目录数据
[root@study ~]# mkdir /srv/gogogo
[root@study ~]# chgrp ftptest /srv/gogogo
[root@study ~]# echo "test" > /srv/gogogo/test.txt
# 2\. 开始直接使用 ftp 观察一下数据!
[root@study ~]# curl ftp://ftptest:myftp123@localhost//srv/gogogo/test.txt
curl: (78) RETR response: 550
# 有问题喔!来瞧瞧登录文件怎么说!
[root@study ~]# grep sealert /var/log/messages | tail
Aug 9 04:23:12 station3-39 setroubleshoot: SELinux is preventing /usr/sbin/vsftpd from
read access on the file test.txt. For complete SELinux messages. run sealert -l
08d3c0a2-5160-49ab-b199-47a51a5fc8dd
[root@study ~]# sealert -l 08d3c0a2-5160-49ab-b199-47a51a5fc8dd
SELinux is preventing /usr/sbin/vsftpd from read access on the file test.txt.
# 虽然这个可信度比较高~不过,因为会全部放行 FTP ,所以不太考虑!
***** Plugin catchall_boolean (57.6 confidence) suggests ******************
If you want to allow ftpd to full access
Then you must tell SELinux about this by enabling the 'ftpd_full_access' boolean.
You can read 'None' man page for more details.
Do
setsebool -P ftpd_full_access 1
# 因为是非正规目录的使用,所以这边加上默认 SELinux type 恐怕会是比较正确的选择!
***** Plugin catchall_labels (36.2 confidence) suggests *******************
If you want to allow vsftpd to have read access on the test.txt file
Then you need to change the label on test.txt
Do
# semanage fcontext -a -t FILE_TYPE 'test.txt'
where FILE_TYPE is one of the following: NetworkManager_tmp_t, abrt_helper_exec_t, abrt_tmp_t,
abrt_upload_watch_tmp_t, abrt_var_cache_t, abrt_var_run_t, admin_crontab_tmp_t, afs_cache_t,
alsa_home_t, alsa_tmp_t, amanda_tmp_t, antivirus_home_t, antivirus_tmp_t, apcupsd_tmp_t, ...
Then execute:
restorecon -v 'test.txt'
***** Plugin catchall (7.64 confidence) suggests **************************
If you believe that vsftpd should be allowed read access on the test.txt 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 vsftpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:ftpd_t:s0-s0:c0.c1023
Target Context unconfined_u:object_r:var_t:s0
Target Objects test.txt [ file ]
Source vsftpd
.....(下面省略).....
```
因为是非正规目录啊,所以感觉上似乎与 semanage 那一行的解决方案比较相关~接下来就是要找到 FTP 的 SELinux type 来解决啰! 所以,让我们查一下 FTP 相关的数据啰!
```
# 3\. 先查看一下 /var/ftp 这个地方的 SELinux type 吧!
[root@study ~]# ll -Zd /var/ftp
drwxr-xr-x. root root system_u:object_r:public_content_t:s0 /var/ftp
# 4\. 以 sealert 建议的方法来处理好 SELinux type 啰!
[root@study ~]# semanage fcontext -a -t public_content_t "/srv/gogogo(/.*)?"
[root@study ~]# restorecon -Rv /srv/gogogo
[root@study ~]# curl ftp://ftptest:myftp123@localhost//srv/gogogo/test.txt
test
# 喔耶!终于再次搞定喔!
```
在这个范例中,我们是修改了 SELinux type 喔!与前一个修改 SELinux rule 不太一样!要理解理解喔!
* 无法变更 FTP 连线端口问题分析与解决
在某些情况下,可能你的服务器软件需要开放在非正规的端口,举例来说,如果因为某些政策问题,导致 FTP 启动的正常的 21 号端口无法使用, 因此你想要启用在 555 号端口时,该如何处理呢?基本上,既然 SELinux 的主体程序大多是被受限的网络服务,没道理不限制放行的端口啊! 所以,很可能会出问题~那就得要想想办法才行!
```
# 1\. 先处理 vsftpd 的配置文件,加入换 port 的参数才行!
[root@study ~]# vim /etc/vsftpd/vsftpd.conf
# 请按下大写的 G 跑到最后一行,然后新增加下面这行设置!前面不可以留白!
listen_port=555
# 2\. 重新启动 vsftpd 并且观察登录文件的变化!
[root@study ~]# systemctl restart vsftpd
[root@study ~]# grep sealert /var/log/messages
Aug 9 06:34:46 station3-39 setroubleshoot: SELinux is preventing /usr/sbin/vsftpd from
name_bind access on the tcp_socket port 555\. For complete SELinux messages. run
sealert -l 288118e7-c386-4086-9fed-2fe78865c704
[root@study ~]# sealert -l 288118e7-c386-4086-9fed-2fe78865c704
SELinux is preventing /usr/sbin/vsftpd from name_bind access on the tcp_socket port 555.
***** Plugin bind_ports (92.2 confidence) suggests ************************
If you want to allow /usr/sbin/vsftpd to bind to network port 555
Then you need to modify the port type.
Do
# semanage port -a -t PORT_TYPE -p tcp 555
where PORT_TYPE is one of the following: certmaster_port_t, cluster_port_t,
ephemeral_port_t, ftp_data_port_t, ftp_port_t, hadoop_datanode_port_t, hplip_port_t,
port_t, postgrey_port_t, unreserved_port_t.
.....(后面省略).....
# 看一下信任度,高达 92.2% 耶!几乎就是这家伙~因此不必再看~就是他了!比较重要的是,
# 解决方案里面,那个 PORT_TYPE 有很多选择~但我们是要打开 FTP 端口嘛!所以,
# 就由后续数据找到 ftp_port_t 那个项目啰!带入实验看看!
# 3\. 实际带入 SELinux 端口修订后,在重新启动 vsftpd 看看
[root@study ~]# semanage port -a -t ftp_port_t -p tcp 555
[root@study ~]# systemctl restart 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 1167/sshd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1598/master
tcp6 0 0 :::555 :::* LISTEN 8436/vsftpd
tcp6 0 0 :::22 :::* LISTEN 1167/sshd
tcp6 0 0 ::1:25 :::* LISTEN 1598/master
# 4\. 实验看看这个 port 能不能用?
[root@study ~]# curl ftp://localhost:555/pub/
-rw-r--r-- 1 0 0 221 Oct 29 2014 securetty
-rw-r--r-- 1 0 0 225 Mar 06 03:05 sysctl.conf
```
通过上面的几个小练习,你会知道在正规或非正规的环境下,如何处理你的 SELinux 问题哩!仔细研究看看啰!
- 鸟哥的Linux私房菜:基础学习篇 第四版
- 目录及概述
- 第零章、计算机概论
- 0.1 电脑:辅助人脑的好工具
- 0.2 个人电脑架构与相关设备元件
- 0.3 数据表示方式
- 0.4 软件程序运行
- 0.5 重点回顾
- 0.6 本章习题
- 0.7 参考资料与延伸阅读
- 第一章、Linux是什么与如何学习
- 1.1 Linux是什么
- 1.2 Torvalds的Linux发展
- 1.3 Linux当前应用的角色
- 1.4 Linux 该如何学习
- 1.5 重点回顾
- 1.6 本章习题
- 1.7 参考资料与延伸阅读
- 第二章、主机规划与磁盘分区
- 2.1 Linux与硬件的搭配
- 2.2 磁盘分区
- 2.3 安装Linux前的规划
- 2.4 重点回顾
- 2.5 本章习题
- 2.6 参考资料与延伸阅读
- 第三章、安装 CentOS7.x
- 3.1 本练习机的规划--尤其是分区参数
- 3.2 开始安装CentOS 7
- 3.3 多重开机安装流程与管理(Option)
- 3.4 重点回顾
- 3.5 本章习题
- 3.6 参考资料与延伸阅读
- 第四章、首次登陆与线上求助
- 4.1 首次登陆系统
- 4.2 文字模式下指令的下达
- 4.3 Linux系统的线上求助man page与info page
- 4.4 超简单文书编辑器: nano
- 4.5 正确的关机方法
- 4.6 重点回顾
- 4.7 本章习题
- 4.8 参考资料与延伸阅读
- 第五章、Linux 的文件权限与目录配置
- 5.1 使用者与群组
- 5.2 Linux 文件权限概念
- 5.3 Linux目录配置
- 5.4 重点回顾
- 5.5 本章练习
- 5.6 参考资料与延伸阅读
- 第六章、Linux 文件与目录管理
- 6.1 目录与路径
- 6.2 文件与目录管理
- 6.3 文件内容查阅
- 6.4 文件与目录的默认权限与隐藏权限
- 6.5 指令与文件的搜寻
- 6.6 极重要的复习!权限与指令间的关系
- 6.7 重点回顾
- 6.8 本章习题:
- 6.9 参考资料与延伸阅读
- 第七章、Linux 磁盘与文件系统管理
- 7.1 认识 Linux 文件系统
- 7.2 文件系统的简单操作
- 7.3 磁盘的分区、格式化、检验与挂载
- 7.4 设置开机挂载
- 7.5 内存交换空间(swap)之创建
- 7.6 文件系统的特殊观察与操作
- 7.7 重点回顾
- 7.8 本章习题 - 第一题一定要做
- 7.9 参考资料与延伸阅读
- 第八章、文件与文件系统的压缩,打包与备份
- 8.1 压缩文件的用途与技术
- 8.2 Linux 系统常见的压缩指令
- 8.3 打包指令: tar
- 8.4 XFS 文件系统的备份与还原
- 8.5 光盘写入工具
- 8.6 其他常见的压缩与备份工具
- 8.7 重点回顾
- 8.8 本章习题
- 8.9 参考资料与延伸阅读
- 第九章、vim 程序编辑器
- 9.1 vi 与 vim
- 9.2 vi 的使用
- 9.3 vim 的额外功能
- 9.4 其他 vim 使用注意事项
- 9.5 重点回顾
- 9.6 本章练习
- 9.7 参考资料与延伸阅读
- 第十章、认识与学习BASH
- 10.1 认识 BASH 这个 Shell
- 10.2 Shell 的变量功能
- 10.3 命令别名与历史命令
- 10.4 Bash Shell 的操作环境:
- 10.5 数据流重导向
- 10.6 管线命令 (pipe)
- 10.7 重点回顾
- 10.8 本章习题
- 10.9 参考资料与延伸阅读
- 第十一章、正则表达式与文件格式化处理
- 11.1 开始之前:什么是正则表达式
- 11.2 基础正则表达式
- 11.3 延伸正则表达式
- 11.4 文件的格式化与相关处理
- 11.5 重点回顾
- 11.6 本章习题
- 11.7 参考资料与延伸阅读
- 第十二章、学习 Shell Scripts
- 12.1 什么是 Shell scripts
- 12.2 简单的 shell script 练习
- 12.3 善用判断式
- 12.4 条件判断式
- 12.5 循环 (loop)
- 12.6 shell script 的追踪与 debug
- 12.7 重点回顾
- 12.8 本章习题
- 第十三章、Linux 帐号管理与 ACL 权限设置
- 13.1 Linux 的帐号与群组
- 13.2 帐号管理
- 13.3 主机的细部权限规划:ACL 的使用
- 13.4 使用者身份切换
- 13.5 使用者的特殊 shell 与 PAM 模块
- 13.6 Linux 主机上的使用者讯息传递
- 13.7 CentOS 7 环境下大量创建帐号的方法
- 13.8 重点回顾
- 13.9 本章习题
- 13.10 参考资料与延伸阅读
- 第十四章、磁盘配额(Quota)与进阶文件系统管理
- 14.1 磁盘配额 (Quota) 的应用与实作
- 14.2 软件磁盘阵列 (Software RAID)
- 14.3 逻辑卷轴管理员 (Logical Volume Manager)
- 14.4 重点回顾
- 14.5 本章习题
- 14.6 参考资料与延伸阅读
- 第十五章、例行性工作调度(crontab)
- 15.1 什么是例行性工作调度
- 15.2 仅执行一次的工作调度
- 15.3 循环执行的例行性工作调度
- 15.4 可唤醒停机期间的工作任务
- 15.5 重点回顾
- 15.6 本章习题
- 第十六章、程序管理与 SELinux 初探
- 16.1 什么是程序 (process)
- 16.2 工作管理 (job control)
- 16.3 程序管理
- 16.4 特殊文件与程序
- 16.5 SELinux 初探
- 16.6 重点回顾
- 16.7 本章习题
- 16.8 参考资料与延伸阅读
- 第十七章、认识系统服务 (daemons)
- 17.1 什么是 daemon 与服务 (service)
- 17.2 通过 systemctl 管理服务
- 17.3 systemctl 针对 service 类型的配置文件
- 17.4 systemctl 针对 timer 的配置文件
- 17.5 CentOS 7.x 默认启动的服务简易说明
- 17.6 重点回顾
- 17.7 本章习题
- 17.8 参考资料与延伸阅读
- 第十八章、认识与分析登录文件
- 18.1 什么是登录文件
- 18.2 rsyslog.service :记录登录文件的服务
- 18.3 登录文件的轮替(logrotate)
- 18.4 systemd-journald.service 简介
- 18.5 分析登录文件
- 18.6 重点回顾
- 18.7 本章习题
- 18.8 参考资料与延伸阅读
- 第十九章、开机流程、模块管理与 Loader
- 19.1 Linux 的开机流程分析
- 19.2 核心与核心模块
- 19.3 Boot Loader: Grub2
- 19.4 开机过程的问题解决
- 19.5 重点回顾
- 19.6 本章习题
- 19.7 参考资料与延伸阅读
- 第二十章、基础系统设置与备份策略
- 20.1 系统基本设置
- 20.2 服务器硬件数据的收集
- 20.3 备份要点
- 20.4 备份的种类、频率与工具的选择
- 20.5 鸟哥的备份策略
- 20.6 灾难复原的考虑
- 20.7 重点回顾
- 20.8 本章习题
- 20.9 参考资料与延伸阅读
- 第二十一章、软件安装:源代码与 Tarball
- 20.1 开放源码的软件安装与升级简介
- 21.2 使用传统程序语言进行编译的简单范例
- 21.3 用 make 进行宏编译
- 21.4 Tarball 的管理与建议
- 21.5 函数库管理
- 21.6 检验软件正确性
- 21.7 重点回顾
- 21.8 本章习题
- 21.9 参考资料与延伸阅读
- 第二十二章、软件安装 RPM, SRPM 与 YUM
- 22.1 软件管理员简介
- 22.2 RPM 软件管理程序: rpm
- 22.3 YUM 线上升级机制
- 22.4 SRPM 的使用 : rpmbuild (Optional)
- 22.5 重点回顾
- 22.6 本章习题
- 22.7 参考资料与延伸阅读
- 第二十三章、X Window 设置介绍
- 23.1 什么是 X Window System
- 23.2 X Server 配置文件解析与设置
- 23.3 显卡驱动程序安装范例
- 23.4 重点回顾
- 23.5 本章习题
- 23.6 参考资料与延伸阅读
- 第二十四章、Linux 核心编译与管理
- 24.1 编译前的任务:认识核心与取得核心源代码
- 24.2 核心编译的前处理与核心功能选择
- 24.3 核心的编译与安装
- 24.4 额外(单一)核心模块编译
- 24.5 以最新核心版本编译 CentOS 7.x 的核心
- 24.6 重点回顾
- 24.7 本章习题
- 24.8 参考资料与延伸阅读