SELinux详解

文章目录

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

SSEO靠我ELinux详解

什么是SELinux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SELinuxSEO靠我的运行模式

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

主体

SELinux主要管理的就是进程

目标

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

策SEO靠我略

由于进程与文件数量庞大，因此SELinux会依据某些服务来制订基本的读写安全性策略，这些策略内还会有详细的规则来指定不同的服务是否开放某些资源的读写。目前centos7.x里面仅提供三个主要的策略，SEO靠我分别是：

targeted：针对网络服务限制较多，针对本机限制较少，是默认的策略

minimum：由target自定义而来，仅针对选择的进程来保护

mls：完整的SELinux限制，限制方面较为严格

建议使用SEO靠我默认的策略即可(targeted)

安全上下文(security context)

上面写了主体、目标、策略，除了策略指定之外，主体与目标的安全上下文必须一致才能够顺利的读写。这个安全上下文(securiSEO靠我ty context)有点类似文件系统的rwx。安全上下文的内容与设置非常重要，如果设置错误，你的某些服务(主体进程)就无法读写文件系统(目标资源)，当然就会一直出现【权限不符】的错误信息。

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

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

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

安全上下文

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

# 先来看看root家目录下面的【文件SEO靠我的SELinux相关信息】 [root@localhost ~]# ls -aZ dr-xr-x---. root root system_u:object_r:admSEO靠我in_home_t:s0 . dr-xr-xr-x. root root system_u:object_r:root_t:s0 .. -rw-------. rootSEO靠我 root system_u:object_r:admin_home_t:s0 anaconda-ks.cfg -rw-r--r--. root root system_u:objecSEO靠我t_r:admin_home_t:s0 .bash_logout -rw-r--r--. root root system_u:object_r:admin_home_t:s0 .baSEO靠我sh_profile -rw-r--r--. root root system_u:object_r:admin_home_t:s0 .bashrc -rw-r--r-SEO靠我-. root root system_u:object_r:admin_home_t:s0 .cshrc -rw-r--r--. root root unconfined_u:objSEO靠我ect_r:admin_home_t:s0 csq.txt -rw-r--r--. root root system_u:object_r:admin_home_t:s0 .tcshrSEO靠我c # 上述特殊字体的部分，就是安全上下文的内容。

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

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

三个字段的意义：

身份识SEO靠我别

相当于账号方面的身份识别，主要的身份识别由下面几种常见的类型

unconfined_u：不受限的用户，也就是说，该文件来自不受限的进程。一般来说，我们使用可登录账号获取bash后默认的bash环境是不SEO靠我受SELinux管制的，因为bash不是说明特别的网络服务

system_u：系统用户，大部分是系统自己产生的文件。

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

上述内容中，操作系SEO靠我统安装自动产生的【anaconda-ks.cfs】就会是【system_u】，而我们自己创建的【csq.txt】就会是【unconfined_u】这个标识。

角色

通过角色字段，我们可以字段这个数据属于进SEO靠我程、文件资源还是代表用户，一般的角色有：

object_r：代表的是文件或目录等资源，这应该是最常见的system_r：代表的就是进程，不过，一般用户也会被指定成为system_r

角色最后面使用【_r】SEO靠我来结尾，因为是role的意思

类型

基本上，一个主体进程能不能读取到这个文件资源与类型字段有关，而类型字段在文件与进程方面的定义又不太相同，分别是：

type：在文件资源上面称为类型domain：在主体进程SEO靠我则称为域

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

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

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

# 再来查看一下系统【进程的SELiSEO靠我nux相关信息】 system_u:system_r:init_t:s0 1 ? 00:00:02 systemd system_u:system_r:kernel_tSEO靠我:s0 2 ? 00:00:00 kthreadd system_u:system_r:kernel_t:s0 6 ? 00:00:00 ksoftirqd/0 ...SEO靠我.... ...... ...... unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 197SEO靠我1 ? 00:00:00 sshd unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1972 pts/1 00:00:00 SEO靠我bash # 基本上进程主要就分为两大类，一种是系统有受限的system_u:system_r，另一种可能是用户自己的， # 比较不受限进程(通常是本机用户自己执行的进SEO靠我程)，就是unconfined_u:unconfined_r这两种 身份识别角色该对应在targeted的意义unconfined_uunconfined_r一般可登录用户的进程，比SEO靠我较没有受限的进程的意思。大多数都是用户已经顺利登录系统后，所用来操作系统的进程。例bash、X window相关软件system_usystem_r由于为系统账号，因此是非交互式的系统运行进程，大多数SEO靠我的系统进程均是这种类型

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

1.先看看crond这个【进程】SEO靠我的安全上下文 [root@localhost ~]# ps -eZ | grep cron system_u:system_r:crond_t:s0-s0:c0.c10SEO靠我23 816 ? 00:00:00 crond # 这个安全上下文的类型名称为 crond_t2.再来看看执行文件、配置文件等的安全上下文内容是什么 [root@locSEO靠我alhost ~]# ll -Zd /usr/sbin/crond /etc/crontab /etc/cron.d drwxr-xr-x. root root system_u:obSEO靠我ject_r:system_cron_spool_t:s0 /etc/cron.d -rw-r--r--. root root system_u:object_r:system_croSEO靠我n_spool_t:s0 /etc/crontab -rwxr-xr-x. root root system_u:object_r:crond_exec_t:s0 /usr/sbin/SEO靠我crond

当我们执行/usr/sbin/crond之后，这个程序变成的进程的 domain 类型会是crond_exec_t，而这个crond_exec_t能够读取的配置文件则为system_cronSEO靠我_spool_t这种的类型。因此不论/etc/crontab、/etc/cron.d 还是/var/spool/cron都会是相关的SELinux类型(/var/spool/cron为user_croSEO靠我n_spool_t)

上图意义可以这样理解：

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

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

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

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

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

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

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

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

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

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

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

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

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

三种模式的运行状态

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

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

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

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

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

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

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

使用案例

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

[root@localhost SEO靠我~]# sestatus SELinux status: enabled <==是否启动SELinux SELinuxfs mount: /sys/fs/selinuxSEO靠我 <==SELinux的相关文件挂载点 SELinux root directory: /etc/selinux <==SELinux的根目录所在 Loaded polSEO靠我icy name: targeted <==目前的策略是什么？ Current mode: enforcing <==目前的模式 Mode from config fiSEO靠我le: enforcing <==目前配置文件内规范的SELinux模式 Policy MLS status: enabled <==是否含有MLS的模式机制 PoliSEO靠我cy deny_unknown status: allowed <==是否默认阻止为止的主体进程 Max kernel policy version: 31

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

[rSEO靠我oot@localhost ~]# vim /etc/selinux/config SELINUX=enforcing <==调整enforcing、permissive、disablSEO靠我ed SELINUXTYPE=targeted <==目前仅有 targeted、mls、minimum三种策略

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

SELinux的启动与关闭

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

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

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

setenforce [ 0 | 1 ] 选项： 0：转成PermissiSEO靠我ve宽容模式 1：转成Enforcing强制模式

使用案例

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

[root@localhost ~]# setenforSEO靠我ce 0 [root@localhost ~]# getenforce Permissive [root@localhost ~]# setenforcSEO靠我e 1 [root@localhost ~]# getenforce Enforcing

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

SELinux策略内的SEO靠我规则管理

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

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

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

SELinux类型查询seinfo、sesearch

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

[root@localhost ~]# yum install -y /opt/centos/Packages/setools-console-* # 找到自己yuSEO靠我m仓库然后安装 seinfo(查询目前所有的身份识别与角色) seinfo [-Atrub] 选项： -A：列出SELinux的状态、SEO靠我规则布尔值、身份识别、角色、类型等所有信息。 -u：列出SELinux的所有身份识别(user)种类 -r：列出SELinux的所有角色(role)种类 SEO靠我 -t：列出SELinux的所有类型(type)种类 -b：列出所有规则的种类(布尔值)

使用案例

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

[root@localhost ~]# seinfSEO靠我o Statistics for policy file: /sys/fs/selinux/policy Policy Version & Type: v.31 (binary, mlSEO靠我s)Classes: 130 Permissions: 272Sensitivities: 1 Categories: 1024Types: 4794 Attributes: 258Users: 8 SEO靠我Roles: 14Booleans: 316 Cond. Expr.: 362Allow: 107901 Neverallow: 0Auditallow: 158 Dontaudit: 10082TySEO靠我pe_trans: 18154 Type_change: 74Type_member: 35 Role allow: 37Role_trans: 414 Range_trans: 5899ConstrSEO靠我aints: 143 Validatetrans: 0Initial SIDs: 27 Fs_use: 32Genfscon: 103 Portcon: 614Netifcon: 0 Nodecon:SEO靠我 0Permissives: 0 Polcap: 5# 上面我们可以看到整个策略是targeted，此策略的安全上下文类型有4794个 # 而各种SELinux的规则(BooleansSEO靠我)共制订了316条 sesearch(查看SELinux的类型)

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

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

使用案例

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

[root@localhost ~]# sesSEO靠我earch -A -s crond_t | grep spoolallow crond_t system_cron_spool_t : dir { ioctl read getattr lock seSEO靠我arch open } ; allow crond_t var_spool_t : file { ioctl read getattr lock open } ; allow crond_t cronSEO靠我_spool_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; alSEO靠我low crond_t cron_spool_t : dir { ioctl read write getattr lock add_name remove_name search open } ; SEO靠我allow crond_t user_cron_spool_t : dir { ioctl read write getattr lock add_name remove_name search opSEO靠我en } ; allow daemon user_cron_spool_t : file { ioctl read write getattr lock append } ; allow crond_SEO靠我t var_spool_t : dir { ioctl read getattr lock search open } ; allow crond_t system_cron_spool_t : fiSEO靠我le { ioctl read write create getattr setattr lock append unlink link rename open } ; allow crond_t uSEO靠我ser_cron_spool_t : lnk_file { read getattr } ; allow crond_t user_cron_spool_t : file { ioctl read wSEO靠我rite create getattr setattr lock append unlink link rename open } ; allow crond_t system_cron_spool_SEO靠我t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow croSEO靠我nd_t user_cron_spool_t : file { ioctl read write create getattr setattr lock append unlink link renaSEO靠我me open } ; # allow后面接主体进程以及文件的SELinux类型，上面的数据是选取出来的 # 意思是说，crond_t可以读取system_cron_sSEO靠我pool_t的文件/目录类型等

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

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

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

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

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

修改SELinux规则的布尔值setsebool

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

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

使用案SEO靠我例

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

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

SELinux安全上下文修改

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

chcon手动修改文SEO靠我件的SELinux类型

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

使用案例

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

[root@localhost ~]# ll -Z /etSEO靠我c/hosts -rw-r--r--. root root system_u:object_r:net_conf_t:s0 /etc/hosts [root@localSEO靠我host ~]# chcon -v -t net_conf_t /etc/cron.d/checktime 正在更改"/etc/cron.d/checktime" 的安全环境 SEO靠我 [root@localhost ~]# ll -Z /etc/cron.d/checktime -rw-r--r--. root root unconfined_u:objecSEO靠我t_r:net_conf_t:s0 /etc/cron.d/checktime

直接以/etc/shadow的SELinux类型套用到/etc/cron.d/checktime上

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

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

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

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

使用案例

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

[root@locaSEO靠我lhost ~]# restorecon -Rv /etc/cron.d/ restorecon reset /etc/cron.d/checktime context system_SEO靠我u:object_r:shadow_t:s0->system_u:object_r:system_cron_spool_t:s0 # 上面这两行其实是同一行，标识将checktime由SEO靠我shadow_t改成system_cron_spool_t # 重新启动crond看看有没有正确启动checktime [root@localhost ~]# systSEO靠我emctl restart crond [root@localhost ~]# tail /var/log/cron ..... .... SEO靠我 May 10 09:52:49 localhost crond[80826]: (CRON) INFO (running with inotify support) May 10 SEO靠我09:52:49 localhost crond[80826]: (CRON) INFO (@reboot jobs will be run at computers startup.)

semanagSEO靠我e默认目录的安全上下文查询与修改

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

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

[root@localhost ~]# yum -SEO靠我y install policycoreutils-python semanage semanage {login|user|port|interfase|fcontext|tranSEO靠我slation} -l semanage fcontext -{a|d|m} [-frst] file_spec 选项： fcontext：主要用在安全SEO靠我上下文方面的用途，-l为查询的意思 -a：增加的意思，你可以增加一些目录的默认安全上下文类型设置。 -m：修改 -d：删除

使用案例

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

[root@localhost ~]# semanage fcontext -l | grep -E ^/etc |^/etc/cron SEO靠我 ...... ...... /etc all files system_u:object_r:etc_t:s0 /etc/cron\.d(/.*)?SEO靠我 all files system_u:object_r:system_cron_spool_t:s0 ..... ...

看到上面输出的最后一行，那也是我们为什么直接使SEO靠我用vim去/etc/cron.d 下面建立新文件，默认的SELinux类型就是正确的。同时，我们也会知道使用restorecon恢复正确的SELinux类型时，系统会去判断默认的类型为依据。

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

1. 先建立/srv/mycron 同时在内部放入配置文件，同时查看SELinux类SEO靠我型 [root@localhost ~]# mkdir /srv/mycron [root@localhost ~]# cp -rf /etc/cron.d/checkSEO靠我time /srv/mycron/ [root@localhost ~]# ll -dZ /srv/mycron/ /srv/mycron/checktime drwxSEO靠我r-xr-x. root root unconfined_u:object_r:var_t:s0 /srv/mycron/ -rw-r--r--. root root unconfinSEO靠我ed_u:object_r:var_t:s0 /srv/mycron/checktime 2. 查看一下上层/srv 的SELinux类型 [root@localhosSEO靠我t ~]# semanage fcontext -l | grep ^/srv /srv/.* all files system_u:object_r:var_t:s0 SEO靠我 ...... .. 怪不得mycron会是var_t 3. 将mycron默认值改为system_cron_spool_t [rootSEO靠我@localhost ~]# semanage fcontext -a -t system_cron_spool_t "/srv/mycron(/.*)?" [root@localhoSEO靠我st ~]# restorecon -Rv /srv/mycron/ restorecon reset /srv/mycron context unconfined_u:object_SEO靠我r:var_t:s0->unconfined_u:object_r:system_cron_spool_t:s0 restorecon reset /srv/mycron/checktSEO靠我ime context unconfined_u:object_r:var_t:s0->unconfined_u:object_r:system_cron_spool_t:s0 [roSEO靠我ot@localhost ~]# ll -dZ /srv/mycron/ /srv/mycron/* drwxr-xr-x. root root unconfined_u:objectSEO靠我_r:system_cron_spool_t:s0 /srv/mycron/ -rw-r--r--. root root unconfined_u:object_r:system_crSEO靠我on_spool_t:s0 /srv/mycron/checktime # 有了默认值到，未来就不会不小心被乱改了