文章目录

SELinux详解
- 什么是SELinux
- - 当初设计的目标：避免资源的误用
  - 传统的文件权限与账号主要的关系：自主访问控制(DOC)
  - 以策略规则制定特定进程读取特定文件：强制访问控制(MAC)
- SELinux的运行模式
- - 安全上下文
  - 进程与文件SELinux类型字段的相关性
- SELinux 3种模式的启动、关闭与查看
- - 三种模式的运行状态
  - SELinux的启动与关闭
- SELinux策略内的规则管理
- - SELinux各个规则的布尔值查询getsebool
  - SELinux类型查询seinfo、sesearch
  - - seinfo(查询目前所有的身份识别与角色)
    - sesearch(查看SELinux的类型)
  - 修改SELinux规则的布尔值setsebool
- SELinux安全上下文修改
- - chcon手动修改文件的SELinux类型
  - restorecon让文件恢复正确的SELinux类型
  - semanage默认目录的安全上下文查询与修改

SELinux详解

什么是SELinux

什么是SELinux呢？其实它是【Security-Enhanced Linux】的英文缩写，字母上的意思就是安全强化Linux的意思。

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

SELinux是由美国国家安全局(NSA)开发的，当初开发的原因是很多企业发现，系统出现问题的原因大部分都在于【内部员工的资源误用】，实际由外部发动的攻击反而没有那么严重。那么什么是【员工资源误用】呢？举例来说，如果有个不是很懂系统的系统管理员为了自己设置的方便，将网页所在目录【/var/www/html/】的权限设置为【drwxrwxrwx】。

那么如果【/var/www/html】设置为777，代表所有进程均可对该目录读写，万一你真的启动了WWW服务器软件，那么该软件所触发的进程将可以写入该目录，而该进程却是对整个Internet提供服务的。只要有心人接触到这个进程，而且该进程刚好又提供了用户进行写入的功能，那么外部的人很可能就会想你的系统写入些莫名其妙的东西。

为了管理这方面的权限与进程的问题，美国国家安全局开始着手处理操作系统这方面的管理。由于Linux是自由软件，程序代码都是公开的，因此它们便使用Linux来作为研究的目标，最后更将研究结果整合到Linux内核中，那就是SELinux。所以说，SELinux是整合到内核的一个模块。

这也就是说：其实SELinux是在进行进程、文件等详细权限配置时依据的一个内核模块。由于启动网络服务的也是进程，因此刚好也是能够控制网络服务能否读写系统资源的第一道关卡。

传统的文件权限与账号主要的关系：自主访问控制(DOC)

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

这种读写文件系统的方式被称为【自主访问控制(DOC)】。基本上，就是依据进程的拥有者于文件资源的rwx权限来决定有无读写的权限。不过这种DAC的访问控制有几个缺点，就是：

root具有最高权限：如果不小心某个进程被有心人获取，且该进程属于root权限，那么这个进程就可以在系统上执行任何资源的读写。
用户可以获取进程来修改文件资源的访问权限：如果你不小心将某个目录的权限设置为777，由于对任何人的权限都会变成rwx，因此该目录就会被任何人所任意读写。

以策略规则制定特定进程读取特定文件：强制访问控制(MAC)

现在我们知道DAC的困扰就是当用户获取进程后，它可以借由这个进程与自己默认的权限来处理它自己的文件资源。万一这个用户对Linux系统不熟，就很可能会又资源误用的问题产生。为了避免DAC容易发生的问题，SELinux引入了强制访问控制(MAC)的方法。

强制访问控制(MAC)，它可以针对特定的进程与特定的文件资源来管理权限。也就是说，即使你是root，那么在使用不同的进程时，你所能获取的权限也并不一定是root，而要根据当时该进程的设置而定。如此一来，我们针对控制的【主体】变成了【进程】而不是用户。此外，这个主体进程也不能任意使用系统文件资源，因为每个文件资源也针对该主体进程设置了可使用的权限。但是整个系统进程那么多、文件那么多，一项一项的控制可就没完没了。所以SELinux也提供了一些默认策略(Policy)，并在该策略内提供多个规则(rule)，让你可以选择是否启用该控制规则。

在强制访问的设置下，我们的进程能够活动的空间就变小了。举例来说，WWW服务器软件的进程为httpd整个程序，而默认情况下，httpd仅能在/var/www/这个目录下面读写文件。如果httpd这个进程想要到其他目录取读写数据，处理规则设置要开放外，目标目录也要设置成httpd可读取的类型(type)才行，限制非常多。所以不小心httpd被黑客获取了控制权，它也无权浏览/etc/shadow等重要配置文件。

针对apache这个WWW网络服务使用DAC或MAC的结果，两者间的关系可以使用下图

左图是没有SELinux的DAC读写结果，apache这个root所主导的进程，可以在这三个目录内作任何文件的新建与修改，相当麻烦。右边则是加上SELinux的MAC管理的结果，SELinux仅会针对aoache这个【进程】开放部分目录的使用权，其他非正规目录就不会让apache使用。因此不管你是谁都不能穿透MAC的框。

SELinux的运行模式

SELinux是通过MAC的方式来管理进程的，它控制的主体是进程，而目标则是该进程能否读取的【文件资源】

主体

SELinux主要管理的就是进程
目标

主体进程能否读写的【目标资源】一般是文件系统
策略

由于进程与文件数量庞大，因此SELinux会依据某些服务来制订基本的读写安全性策略，这些策略内还会有详细的规则来指定不同的服务是否开放某些资源的读写。目前centos7.x里面仅提供三个主要的策略，分别是：
- targeted：针对网络服务限制较多，针对本机限制较少，是默认的策略
- minimum：由target自定义而来，仅针对选择的进程来保护
- mls：完整的SELinux限制，限制方面较为严格
  
  建议使用默认的策略即可(targeted)
- 安全上下文(security context)
  
  上面写了主体、目标、策略，除了策略指定之外，主体与目标的安全上下文必须一致才能够顺利的读写。这个安全上下文(security context)有点类似文件系统的rwx。安全上下文的内容与设置非常重要，如果设置错误，你的某些服务(主体进程)就无法读写文件系统(目标资源)，当然就会一直出现【权限不符】的错误信息。

上图的重点在【主体】如何获取【目标】的资源访问权限。由上图可知

(1)主体进程必须要通过SELinux策略内的规则放行后，才可以与目标资源进行安全上下文比对

(2)若比对失败无法读写目标，若比对成功则可以开始读写目标。最终能否读写目标还是与文件系统rwx权限有关。

安全上下文

那么安全上下文到底是什么样的存在呢？我们可以使用ls -Z(注意：你必须已经启动了SELinux才行)

# 先来看看root家目录下面的【文件的SELinux相关信息】
[root@localhost ~]# ls -aZ
dr-xr-x---. root root system_u:object_r:admin_home_t:s0 .
dr-xr-xr-x. root root system_u:object_r:root_t:s0      ..
-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 .bash_logout
-rw-r--r--. root root system_u:object_r:admin_home_t:s0 .bash_profile
-rw-r--r--. root root system_u:object_r:admin_home_t:s0 .bashrc
-rw-r--r--. root root system_u:object_r:admin_home_t:s0 .cshrc
-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 csq.txt
-rw-r--r--. root root system_u:object_r:admin_home_t:s0 .tcshrc
# 上述特殊字体的部分，就是安全上下文的内容。

如上所示，安全上下文用冒号分为三个字段

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

三个字段的意义：

身份识别

相当于账号方面的身份识别，主要的身份识别由下面几种常见的类型
- unconfined_u：不受限的用户，也就是说，该文件来自不受限的进程。一般来说，我们使用可登录账号获取bash后默认的bash环境是不受SELinux管制的，因为bash不是说明特别的网络服务
- system_u：系统用户，大部分是系统自己产生的文件。
  
  基本上，如果是系统或软件本身所提供的文件，大多就是system_u这个身份名称；而如果是我们用户通过bash自己建立的文件，大多则是不受限的unconfined_u身份；如果是网络服务所产生的文件，或是系统服务运行过程产生的文件，则大部分的识别就会是system_u。
  
  上述内容中，操作系统安装自动产生的【anaconda-ks.cfs】就会是【system_u】，而我们自己创建的【csq.txt】就会是【unconfined_u】这个标识。
角色

通过角色字段，我们可以字段这个数据属于进程、文件资源还是代表用户，一般的角色有：
- object_r：代表的是文件或目录等资源，这应该是最常见的
- system_r：代表的就是进程，不过，一般用户也会被指定成为system_r
角色最后面使用【_r】来结尾，因为是role的意思
类型

基本上，一个主体进程能不能读取到这个文件资源与类型字段有关，而类型字段在文件与进程方面的定义又不太相同，分别是：
- type：在文件资源上面称为类型
- domain：在主体进程则称为域
domain需要与type搭配，则该进程才能够顺利读取文件资源

进程与文件SELinux类型字段的相关性

查看系统中的进程SELinux下面的安全上下文是什么？

# 再来查看一下系统【进程的SELinux相关信息】
system_u:system_r:init_t:s0          1 ?        00:00:02 systemd
system_u:system_r:kernel_t:s0        2 ?        00:00:00 kthreadd
system_u:system_r:kernel_t:s0        6 ?        00:00:00 ksoftirqd/0
.......
......
......
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1971 ? 00:00:00 sshd
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1972 pts/1 00:00:00 bash
# 基本上进程主要就分为两大类，一种是系统有受限的system_u:system_r，另一种可能是用户自己的，
# 比较不受限进程(通常是本机用户自己执行的进程)，就是unconfined_u:unconfined_r这两种

身份识别	角色	该对应在targeted的意义
unconfined_u	unconfined_r	一般可登录用户的进程，比较没有受限的进程的意思。大多数都是用户已经顺利登录系统后，所用来操作系统的进程。例bash、X window相关软件
system_u	system_r	由于为系统账号，因此是非交互式的系统运行进程，大多数的系统进程均是这种类型

如上所述，在默认的target策略下，其实最重要的字段就是类型字段（type），主体与目标之间是否具有可读写的权限，与进程的domain及文件的type有关。两者的关系可以使用crond以及它的配置文件来说明，就是通过/usr/sbin/crond、/etc/crontab、/etc/cron.d等文件来说明。首先，来看看这几个安全上下文的内容

1.先看看crond这个【进程】的安全上下文
[root@localhost ~]# ps -eZ | grep cron
system_u:system_r:crond_t:s0-s0:c0.c1023 816 ?  00:00:00 crond
# 这个安全上下文的类型名称为 crond_t

2.再来看看执行文件、配置文件等的安全上下文内容是什么
[root@localhost ~]# 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_exec_t，而这个crond_exec_t能够读取的配置文件则为system_cron_spool_t这种的类型。因此不论/etc/crontab、/etc/cron.d 还是/var/spool/cron都会是相关的SELinux类型(/var/spool/cron为user_cron_spool_t)

上图意义可以这样理解：

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

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

那么如果，你的crond配置文件的SELinux并不是system_cron_spool_t该配置文件真的可以顺利的读取运行吗

1.假设你因为不熟的缘故，因此是在【root家目录】建立一个如下的cron设置
[root@localhost ~]# vim checktime
10 * * * * root sleep 60s
2.检查后才发现文件放错了目录，又不想要保留副本，因此使用mv移动到了正确的目录
[root@localhost ~]# mv checktime /etc/cron.d/
[root@localhost ~]# ll /etc/cron.d/checktime 
-rw-r--r--. 1 root root 26 5月   9 09:36 /etc/cron.d/checktime
# 权限是644，确定没问题，任何进程都能够读取
3.强制重新启动crond，然后看一下日志文件，看看有没有问题发生
[root@localhost ~]# systemctl restart crond
[root@localhost ~]# tail /var/log/cron 
May  9 09:38:53 localhost crond[60387]: ((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)
May  9 09:38:53 localhost crond[60387]: (root) FAILED (loading cron table)
# 上面的意思是，有错误，因为原本的安全上下文与文件的实际安全上下文无法匹配的缘故。

从上面的案例来看，为我们配置的文件确实没有办法被crond这个服务所读取。而原因在日志文件内就有说明，主要就是来自SELinux安全上下文类型的不同所致。

SELinux 3种模式的启动、关闭与查看

目前SELinux依据启动与否，共有三种模式，分别如下：

Enforcing：强制模式，代表SELinux运行中，且已经正确开始限制domain/type
Permissive：宽容模式，代表SELinux运行中，不过仅会有警告信息并不会实际限制domain/type的读写
Disabled：关闭模式，SELinux并没有实际运行。

那么这3种模式与上面谈到的策略规则、安全上下文是什么关系呢？如下图

如上图，并不是所有的进程都会被SELinux所管制，因此最左边会出现一个所谓的【有受限的进程主体】。那如何查看有没有受限？可以通过【ps -eZ】去查看。

举例来说，我们找找crond与bash这两个进程是否被限制

[root@localhost ~]# ps -eZ | grep -E 'cron|bash'
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 8353 tty1 00:00:00 bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 8761 pts/0 00:00:00 bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 8775 pts/1 00:00:00 bash
system_u:system_r:crond_t:s0-s0:c0.c1023 60387 ? 00:00:00 crond

如上案例所示，我们可以看到crond确实是受限的主体进程，而bash因为是本机进程，就是不受限(unconfined_t)的类型。也就是说bash是不用通过上面那个图的流程，直接去判断rwx了。

三种模式的运行状态

如果是disabled模式，那么SELinux将不会运行，当然受限的进程也不会经过SELinux，也是直接判断rwx。

如果是permissive(宽容模式)？这种模式也是不会阻止主体进程(所以我们在什么SELinux标题的最后的一张图中的MAC里面的箭头是可以被穿透的)，如果没有通过策略规则或安全上下文比对时，那么该读写操作将会被记录起来(log)，可作为未来检查问题的判断依据。

Enforcing模式，就是实际将受限主体进入规则比对、安全上下文比对的流程，若失败，就直接阻止主题进程的读写操作，并且将他记录下来。如果通通没问题，才会进入到rwx权限判断。

那你如何知道目前的SELinux模式呢？可以使用getenforce来查看

[root@localhost ~]# getenforce 
Enforcing  # 就显示出目前的模式为Enforcing

另外又如何知道SELinux的策略(Policy)是什么呢？这时可以使用sestatus来查看

sestatus  [-vb]
选项：
-v：检查列于/etc/sestatus.conf内的文件与进程的安全上下文内容
-b：将目前策略的规则布尔值列出，就是某些规则(rule)是否要启动(0/1)的意思

使用案例

列出目前SELinux使用哪个策略(Policy)?

[root@localhost ~]# 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:      31

如上所示，目前是启动的而且是Enforcing模式，而由配置文件查询得知为Enforcing模式。此外，目前默认策略为targeted。SELinux的配置文件是哪个？其实就是/etc/selinux/config这个文件。

[root@localhost ~]# vim /etc/selinux/config
SELINUX=enforcing          <==调整enforcing、permissive、disabled
SELINUXTYPE=targeted       <==目前仅有 targeted、mls、minimum三种策略

若需要修改默认策略的话，直接修改SELinux=enforcing那一行即可。

SELinux的启动与关闭

你需要注意的是，如果你修改了策略则需要重新启动；如果由Enforcing或Permissive改成Disabled，或由Disabled改成其他两个，那也必须要重新启动。这是因为SELinux是整合到内核中的，你可以在SELinux运行下切换成强制(Ebfircing)或宽容(Permissive)模式，不能够直接关闭SELinux。

不过你需要注意的是，如果从Disable 转到启动SELinux的模式时，由于系统必须要针对文件写入安全上下文的信息，因此启动过程会花费不少的时间在等待重新写入SELinux安全上下文(有时也成为SELinux Label)，而且在写完之后还要再重新启动一次，你必须要等待很长一段时间。等到下次成功后，再使用getenforce或sestatus来查看是否成功启动到Enforcing模式。

如果你已经再Enforcing模式，但是可能由于一些设置的问题导致SELinux让某些服务无法正常地运行。你可以将Enforcing的模式改为宽容(Permissive)的模式，让SELinux只会警告无法顺利连接的信息，而不是直接阻止主体进程的读取权限。让SELinux模式在Enforcing与Permissive之间切换的方法为：

setenforce [ 0 | 1 ]
选项：
0：转成Permissive宽容模式
1：转成Enforcing强制模式

使用案例

将SELinux在Enforcing与Permissive之间切换与查看

[root@localhost ~]# setenforce 0
[root@localhost ~]# getenforce 
Permissive
[root@localhost ~]# setenforce 1
[root@localhost ~]# getenforce 
Enforcing

setenforce 无法在Disabled模式下切换模式

SELinux策略内的规则管理

SELinux的三种模式会影响到主体进程的放行与否。如果是进入Enforcing模式，那么接下来下来会影响到主体进程的，当然就是策略【target 策略内的各项规则(rules)】。那么们怎么查看这个策略到底影响了多少主体进程的规则呢？使用getsebool

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

[root@localhost ~]# getsebool  -a
abrt_anon_write --> off
abrt_handle_event --> off
......
.....
...
cron_can_relabel --> off
cron_userdomain_transition --> on
.....
....
httpd_enable_homedirs --> off
......
...
# 这么多SELinux规则，每个规则后面都列出现在是允许放行还是不许放行的布尔值

SELinux类型查询seinfo、sesearch

SELinux有这么规则，但是每个规则到底在限制什么东西？如果想知道就要使用seinfo等工具。这些工具并没有默认安装我们需要手动安装一下

[root@localhost ~]# yum install -y /opt/centos/Packages/setools-console-*
# 找到自己yum仓库然后安装

seinfo(查询目前所有的身份识别与角色)

seinfo [-Atrub]
选项：
-A：列出SELinux的状态、规则布尔值、身份识别、角色、类型等所有信息。
-u：列出SELinux的所有身份识别(user)种类
-r：列出SELinux的所有角色(role)种类
-t：列出SELinux的所有类型(type)种类
-b：列出所有规则的种类(布尔值)

使用案例

列出SELinux在此策略下的统计状态

[root@localhost ~]# seinfo 

Statistics for policy file: /sys/fs/selinux/policy
Policy Version & Type: v.31 (binary, mls)

   Classes:           130    Permissions:       272
   Sensitivities:       1    Categories:       1024
   Types:            4794    Attributes:        258
   Users:               8    Roles:              14
   Booleans:          316    Cond. Expr.:       362
   Allow:          107901    Neverallow:          0
   Auditallow:        158    Dontaudit:       10082
   Type_trans:      18154    Type_change:        74
   Type_member:        35    Role allow:         37
   Role_trans:        414    Range_trans:      5899
   Constraints:       143    Validatetrans:       0
   Initial SIDs:       27    Fs_use:             32
   Genfscon:          103    Portcon:           614
   Netifcon:            0    Nodecon:             0
   Permissives:         0    Polcap:              5

# 上面我们可以看到整个策略是targeted，此策略的安全上下文类型有4794个
# 而各种SELinux的规则(Booleans)共制订了316条

sesearch(查看SELinux的类型)

上面的seinfo没有谈到规则相关的东西，在之前我们创建过一个checktime的文件并移动到了/etc/cron.d/下面，但是他的SELinux类型不对，crond整个进程类型是crond_t，那么crond_t能够读取的文件SELinux类型有哪些？

sesearch [-A] [-s 主体类型] [-t 目标类型] [-b 布尔值]
选项：
-A：列出后面数据中，允许【读取或放行】的相关信息
-t：后面接类型,例如-t httpd_t
-b：后面接SELinux的规则，例如 -b httpd_enable_ftp_server

使用案例

找出crond_t这个主体进程能够读取的文件SELinux类型

[root@localhost ~]# sesearch -A -s crond_t | grep spool
   allow crond_t system_cron_spool_t : dir { ioctl read getattr lock search open } ; 
   allow crond_t var_spool_t : file { ioctl read getattr lock open } ; 
   allow crond_t cron_spool_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow crond_t cron_spool_t : dir { ioctl read write getattr lock add_name remove_name search open } ; 
   allow crond_t user_cron_spool_t : dir { ioctl read write getattr lock add_name remove_name search open } ; 
   allow daemon user_cron_spool_t : file { ioctl read write getattr lock append } ; 
   allow crond_t var_spool_t : dir { ioctl read getattr lock search open } ; 
   allow crond_t system_cron_spool_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow crond_t user_cron_spool_t : lnk_file { read getattr } ; 
   allow crond_t user_cron_spool_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow crond_t system_cron_spool_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow crond_t user_cron_spool_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
# allow后面接主体进程以及文件的SELinux类型，上面的数据是选取出来的
# 意思是说，crond_t可以读取system_cron_spool_t的文件/目录类型等

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

[root@localhost ~]# ll -Z /etc/cron.d/checktime 
-rw-r--r--. root root unconfined_u:object_r:admin_home_t:s0 /etc/cron.d/checktime
# 一个SELinux类型为amdin_home_t，一个是文件(file)
[root@localhost ~]# sesearch -A -s crond_t | grep admin_home_t
   allow crond_t admin_home_t : lnk_file { read getattr } ; 
   allow domain admin_home_t : dir { getattr search open } ; 
   allow userdom_filetrans_type admin_home_t : lnk_file { read getattr } ; 
   allow domain admin_home_t : lnk_file { read getattr } ; 
   allow crond_t admin_home_t : dir { ioctl read getattr lock search open } ; 
   allow userdom_filetrans_type admin_home_t : dir { ioctl read write getattr lock add_name remove_name search open } ; 
# 虽然有crond_t admin_home_t 存在，但是这是总体的信息，并没有针对某些规则的寻找
# 所以还是确定checktime能否被读取。但是，基本上就是SELinux的类型出问题，因此才会无法读取

所以说，/etc/cron.d/checktime这个我们自己复制过去的文件会没有办法读取的原因，就是因为SELinux类型错误，根本就无法读取。

使用getsebool -a 里面看到的 httpd_enable_homeedirs到底是上面？又是规范了哪些主体进程能够读取SELinux类型呢？

[root@localhost ~]# sesearch -A -b httpd_enable_homedirs
Found 77 semantic av rules:
   allow httpd_t user_home_dir_t : lnk_file { read getattr } ; 
   allow httpd_suexec_t user_home_dir_t : dir { getattr search open } ; 
   allow httpd_t nfs_t : lnk_file { read getattr } ; 
   allow httpd_sys_script_t nfs_t : file { ioctl read getattr lock open } ; 
   allow httpd_sys_script_t cifs_t : lnk_file { read getattr } ; 
   allow httpd_suexec_t user_home_dir_t : lnk_file { read getattr } ; 
   allow httpd_t cifs_t : file { ioctl read getattr lock open } ; 
   allow httpd_sys_script_t nfs_t : dir { getattr search open } ; 
   allow httpd_sys_script_t nfs_t : dir { ioctl read getattr lock search open } ; 
   allow httpd_sys_script_t nfs_t : dir { getattr search open } ; 
   allow httpd_sys_script_t nfs_t : dir { ioctl read getattr lock search open } ; 
   allow httpd_suexec_t user_home_type : lnk_file { read getattr } ; 
   allow httpd_sys_script_t cifs_t : file { ioctl read getattr lock open } ; 
   allow httpd_user_script_t user_home_type : lnk_file { read getattr } ; 
   allow httpd_t cifs_t : lnk_file { read getattr } ; 
......
.....
# 从上面的数据可以理解，在这个规则中，主要是放行httpd_t能否读取使用者家目录的文件
# 所以，如果这个规则没有启动，基本上，httpd_t这种进程就无法读取使用者家目录下的文件

修改SELinux规则的布尔值setsebool

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

setsebool [-P] 【规则名称】 [ 0 | 1 ]
选项：
-P：之间将设置写入配置文件，该设置信息未来会生效

使用案例

查询httpd_enable_homedirs这个规则的状态，并且修改这个规则成为不通的布尔值

[root@localhost ~]# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> off  # 查看是关闭的我们开启他
[root@localhost ~]# setsebool -P httpd_enable_homedirs 1
[root@localhost ~]# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> on   # 开启成功

SELinux安全上下文修改

SELinux对受限的主体进程有没有影响，第一关考虑SELinux的三种类型，第二个考虑SELinux的策略规则是否放行，第三关则是开始比对SELinux类型。由上面的策略规则我们可以知道，sesearch来找到主体进程与SELinux类型关系。那么怎么修改文件的SELinux，让主体进程能够读到正确的文件呢？

chcon手动修改文件的SELinux类型

chcon [-R] [-t type] [-u user] [-r role] 文件
chcon [-R] --reference=范例文件 文件
选项：
-R：连同该目录下的子目录也同时修改
-t：后面接安全上下文的类型栏位，例如httpd_sys_content_t
-u：后面接身份识别，例如system_u
-r：后面接角色，例如 system_r
-v：若有变化成功，请将变动的结果列出来
--reference=范例文件：拿某个文件当范例来修改后续接的文件类型

使用案例

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

[root@localhost ~]# ll -Z /etc/hosts
-rw-r--r--. root root system_u:object_r:net_conf_t:s0  /etc/hosts
[root@localhost ~]# chcon -v -t net_conf_t /etc/cron.d/checktime 
正在更改"/etc/cron.d/checktime" 的安全环境
[root@localhost ~]# 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类型套用到/etc/cron.d/checktime上

[root@localhost ~]# chcon -v --reference=/etc/shadow /etc/cron.d/checktime 
正在更改"/etc/cron.d/checktime" 的安全环境
[root@localhost ~]# ll -Z /etc/cron.d/checktime
-rw-r--r--. root root system_u:object_r:shadow_t:s0    /etc/cron.d/checktime

上面的练习【都没有正确的解答】，因为正确的SELinux类型应该是要以 /etc/cron.d/ 下面的文件为标准来处理才对。那么能不能让SELinux自己解决默认目录下的SELinux类型？使用restorecon

restorecon让文件恢复正确的SELinux类型

restorecon [-Rv] 文件目录
选项：
-R：连同子目录一起修改
-v：将过程显示到屏幕

使用案例

将/etc/cron.d/下面的文件通通恢复成默认的SELinux类型

[root@localhost ~]# 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@localhost ~]# systemctl restart crond
[root@localhost ~]# tail /var/log/cron
.....
....
May 10 09:52:49 localhost crond[80826]: (CRON) INFO (running with inotify support)
May 10 09:52:49 localhost crond[80826]: (CRON) INFO (@reboot jobs will be run at computer's startup.)

semanage默认目录的安全上下文查询与修改

你可能会觉得奇怪，为什么restorecon可以【恢复】原本的SELinux类型呢？那肯定是有个地方在记录每个文件/目录的SELinux默认类型，那么如何查询SELinux类型以及如何【增加/修改/删除】默认的SELinux类型呢？使用semanage即可

Linux默认没有安装semanage这个命令需要手动安装一下

[root@localhost ~]# yum -y install policycoreutils-python semanage

semanage {login|user|port|interfase|fcontext|translation} -l
semanage fcontext -{a|d|m} [-frst] file_spec
选项：
fcontext：主要用在安全上下文方面的用途，-l为查询的意思
-a：增加的意思，你可以增加一些目录的默认安全上下文类型设置。
-m：修改
-d：删除

使用案例

查询一下/etc/ /etc/cron.d默认的SELinux类型是什么

[root@localhost ~]# semanage fcontext -l | grep -E '^/etc |^/etc/cron'
......
......
/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类型就是正确的。同时，我们也会知道使用restorecon恢复正确的SELinux类型时，系统会去判断默认的类型为依据。

如果我们要建立一个/srv/mycron目录，这个目录默认也需要变成 system_cron_spool_t时，应该如何处理？

1. 先建立/srv/mycron 同时在内部放入配置文件，同时查看SELinux类型
[root@localhost ~]# mkdir /srv/mycron
[root@localhost ~]# cp -rf /etc/cron.d/checktime  /srv/mycron/
[root@localhost ~]# 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类型
[root@localhost ~]# semanage fcontext -l | grep '^/srv'
/srv/.*                                            all files          system_u:object_r:var_t:s0 
......
..
怪不得mycron会是var_t
3. 将mycron默认值改为system_cron_spool_t
[root@localhost ~]# semanage fcontext -a -t system_cron_spool_t "/srv/mycron(/.*)?"
[root@localhost ~]# restorecon -Rv /srv/mycron/
restorecon reset /srv/mycron context unconfined_u:object_r:var_t:s0->unconfined_u:object_r:system_cron_spool_t:s0
restorecon reset /srv/mycron/checktime context unconfined_u:object_r:var_t:s0->unconfined_u:object_r:system_cron_spool_t:s0
[root@localhost ~]# 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
# 有了默认值到，未来就不会不小心被乱改了