成都网站建设优惠活动,网站模板 代码免费,t购物网站开发前景,页面效果华丽的网站文章目录 SELinux详解什么是SELinux当初设计的目标#xff1a;避免资源的误用传统的文件权限与账号主要的关系#xff1a;自主访问控制(DAC)以策略规则制定特定进程读取特定文件#xff1a;强制访问控制(MAC) SELinux的运行模式安全上下文进程与文件SELinux类型字段的相关性… 文章目录 SELinux详解什么是SELinux当初设计的目标避免资源的误用传统的文件权限与账号主要的关系自主访问控制(DAC)以策略规则制定特定进程读取特定文件强制访问控制(MAC) SELinux的运行模式安全上下文进程与文件SELinux类型字段的相关性 SELinux 3种模式的启动、关闭与查看三种模式的运行状态SELinux的启动与关闭 SELinux策略内的规则管理SELinux各个规则的布尔值查询getseboolSELinux类型查询seinfo、sesearchseinfo(查询目前所有的身份识别与角色)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是在进行进程、文件等详细权限配置时依据的一个内核模块。由于启动网络服务的也是进程因此刚好也是能够控制网络服务能否读写系统资源的第一道关卡。
传统的文件权限与账号主要的关系自主访问控制(DAC)
我们知道系统的账号主要分为系统管理员(root)与一般用户而这两种身份能否使用系统上面的文件资源则于rwx的权限设置有关。不过你需要注意的是各种权限设置对root是无效的。因此当某个进程想要对文件进行读写时系统就会根据该进程的拥有者和用户组比对文件的权限只有通过权限检查才可以读写该文件。
这种读写文件系统的方式被称为【自主访问控制(DAC)】。基本上就是依据进程的拥有者于文件资源的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仅会针对apache这个【进程】开放部分目录的使用权其他非正规目录就不会让apache使用。因此不管你是谁都不能穿透MAC的框。
SELinux的运行模式
SELinux是通过MAC的方式来管理进程的它控制的主体是进程而目标则是该进程能否读取的【文件资源】 主体 SELinux主要管理的就是进程 目标 主体进程能否读写的【目标资源】一般是文件系统 策略 由于进程与文件数量庞大因此SELinux会依据某些服务来制订基本的读写安全性策略这些策略内还会有详细的规则来指定不同的服务是否开放某些资源的读写。三个主要的策略分别是 targeted针对网络服务限制较多针对本机限制较少是默认的策略 minimum由target自定义而来仅针对选择的进程来保护 mls完整的SELinux限制限制方面较为严格 建议使用默认的策略即可(targeted) 安全上下文(security context) 上面写了主体、目标、策略除了策略指定之外主体与目标的安全上下文必须一致才能够顺利的读写。这个安全上下文(security context)有点类似文件系统的rwx。安全上下文的内容与设置非常重要如果设置错误你的某些服务(主体进程)就无法读写文件系统(目标资源)当然就会一直出现【权限不符】的错误信息。
上图的重点在【主体】如何获取【目标】的资源访问权限。由上图可知
(1)主体进程必须要通过SELinux策略内的规则放行后才可以与目标资源进行安全上下文比对
(2)若比对失败无法读写目标若比对成功则可以开始读写目标。最终能否读写目标还是与文件系统rwx权限有关。
安全上下文
那么安全上下文到底是什么样的存在呢我们可以使用ls -Z(注意你必须已经启动了SELinux才行)
# 先来看看root家目录下面的【文件的SELinux相关信息】
[rootchenshiren ~]# ls -Z
system_u:object_r:admin_home_t:s0 anaconda-ks.cfg
unconfined_u:object_r:mail_home_t:s0 dead.letter unconfined_u:object_r:admin_home_t:s0 mailfile.txt
unconfined_u:object_r:admin_home_t:s0 csqbashrc unconfined_u:object_r:admin_home_t:s0 givecsqmail.txt system_u:object_r:admin_home_t:s0 nohup.out
unconfined_u:object_r:admin_home_t:s0 csq.txt
system_u:object_r:admin_home_t:s0 givecsq.txt
system_u:object_r:admin_home_t:s0 sleep500s.sh
# 上述特殊字体的部分就是安全上下文的内容。如上所示安全上下文用冒号分为三个字段
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相关信息】
[rootchenshiren ~]# ps -eZ
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_uunconfined_r一般可登录用户的进程比较没有受限的进程的意思。大多数都是用户已经顺利登录系统后所用来操作系统的进程。例bash、X window相关软件system_usystem_r由于为系统账号因此是非交互式的系统运行进程大多数的系统进程均是这种类型
如上所述在默认的target策略下其实最重要的字段就是类型字段type主体与目标之间是否具有可读写的权限与进程的domain及文件的type有关。两者的关系可以使用crond以及它的配置文件来说明就是通过/usr/sbin/crond、/etc/crontab、/etc/cron.d等文件来说明。首先来看看这几个安全上下文的内容
1.先看看crond这个【进程】的安全上下文
[rootlocalhost ~]# ps -eZ | grep cron
system_u:system_r:crond_t:s0-s0:c0.c1023 816 ? 00:00:00 crond
# 这个安全上下文的类型名称为 crond_t2.再来看看执行文件、配置文件等的安全上下文内容是什么
[rootlocalhost ~]# 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设置
[rootchenshiren ~]# vim checktime
10 * * * * root sleep 60s
2.检查后才发现文件放错了目录又不想要保留副本因此使用mv移动到了正确的目录
[rootchenshiren ~]# mv checktime /etc/cron.d/
[rootchenshiren ~]# ll /etc/cron.d/checktime
-rw-r--r--. 1 root root 26 3月 24 22:19 /etc/cron.d/checktime
# 权限是644确定没问题任何进程都能够读取
3.强制重新启动crond然后看一下日志文件看看有没有问题发生
[rootlocalhost ~]# systemctl restart crond
[rootlocalhost ~]# tail /var/log/cron
Mar 25 00:41:17 chenshiren crond[2296]: ((null)) Unauthorized SELinux contextsystem_u:system_r:system_cronjob_t:s0-s0:c0.c1023 file_contextunconfined_u:object_r:admin_home_t:s0 (/etc/cron.d/checktime)
Mar 25 00:41:17 chenshiren crond[2296]: (root) FAILED (loading cron table)
Mar 25 00:41:17 chenshiren crond[2296]: (CRON) INFO (reboot jobs will be run at computers startup.)
# 上面的意思是有错误因为原本的安全上下文与文件的实际安全上下文无法匹配的缘故。
[rootchenshiren ~]# ls -Z /etc/cron.d/checktime
unconfined_u:object_r:admin_home_t:s0 /etc/cron.d/checktime从上面的案例来看为我们配置的文件确实没有办法被crond这个服务所读取。而原因在日志文件内就有说明主要就是来自SELinux安全上下文类型的不同所致
SELinux 3种模式的启动、关闭与查看
目前SELinux依据启动与否共有三种模式分别如下
Enforcing强制模式代表SELinux运行中且已经正确开始限制domain/typePermissive宽容模式代表SELinux运行中不过仅会有警告信息并不会实际限制domain/type的读写Disabled关闭模式SELinux并没有实际运行。
那么这3种模式与上面谈到的策略规则、安全上下文是什么关系呢如下图 如上图并不是所有的进程都会被SELinux所管制因此最左边会出现一个所谓的【有受限的进程主体】。那如何查看有没有受限可以通过【ps -eZ】去查看。
举例来说我们找找crond与bash这两个进程是否被限制
[rootlocalhost ~]# 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来查看
[rootlocalhost ~]# getenforce
Enforcing # 就显示出目前的模式为Enforcing另外又如何知道SELinux的策略(Policy)是什么呢这时可以使用sestatus来查看
sestatus [-vb]
选项
-v检查列于/etc/sestatus.conf内的文件与进程的安全上下文内容
-b将目前策略的规则布尔值列出就是某些规则(rule)是否要启动(0/1)的意思使用案例
列出目前SELinux使用哪个策略(Policy)?
[rootlocalhost ~]# 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这个文件。
[rootlocalhost ~]# vim /etc/selinux/config
SELINUXenforcing 调整enforcing、permissive、disabled
SELINUXTYPEtargeted 目前仅有 targeted、mls、minimum三种策略若需要修改默认策略的话直接修改SELinuxenforcing那一行即可。
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 ] # setenforce 无法在Disabled模式下切换模式
选项
0转成Permissive宽容模式
1转成Enforcing强制模式# 将SELinux在Enforcing与Permissive之间切换与查看
[rootlocalhost ~]# setenforce 0
[rootlocalhost ~]# getenforce
Permissive
[rootlocalhost ~]# setenforce 1
[rootlocalhost ~]# getenforce
Enforcing# 完全关闭SELinux
grubby --update-kernel ALL --args selinux0 ; reboot
# 如果要再次开启
grubby --update-kernel ALL --args selinux1SELinux策略内的规则管理
SELinux的三种模式会影响到主体进程的放行与否。如果是进入Enforcing模式那么接下来下来会影响到主体进程的当然就是策略【target 策略内的各项规则(rules)】。那么们怎么查看这个策略到底影响了多少主体进程的规则呢使用getsebool
SELinux各个规则的布尔值查询getsebool
# 查看当前策略影响了多少主体进程的规则
[rootlocalhost ~]# 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等工具。这些工具并没有默认安装我们需要手动安装一下
[rootlocalhost ~]# yum install -y /opt/centos/Packages/setools-console-*
# 找到自己yum仓库然后安装seinfo(查询目前所有的身份识别与角色)
seinfo [-Atrub]
选项
-A列出SELinux的状态、规则布尔值、身份识别、角色、类型等所有信息。
-u列出SELinux的所有身份识别(user)种类
-r列出SELinux的所有角色(role)种类
-t列出SELinux的所有类型(type)种类
-b列出所有规则的种类(布尔值)
# 示例1 列出SELinux在此策略下的统计状态
[rootlocalhost ~]# seinfo Statistics for policy file: /sys/fs/selinux/policy
Policy Version Type: v.31 (binary, mls)Classes: 130 Permissions: 272Sensitivities: 1 Categories: 1024Types: 4794 Attributes: 258Users: 8 Roles: 14Booleans: 316 Cond. Expr.: 362Allow: 107901 Neverallow: 0Auditallow: 158 Dontaudit: 10082Type_trans: 18154 Type_change: 74Type_member: 35 Role allow: 37Role_trans: 414 Range_trans: 5899Constraints: 143 Validatetrans: 0Initial SIDs: 27 Fs_use: 32Genfscon: 103 Portcon: 614Netifcon: 0 Nodecon: 0Permissives: 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# 示例1 找出crond_t这个主体进程能够读取的文件SELinux类型
[rootlocalhost ~]# sesearch -A -s crond_t | grep spoolallow 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的文件/目录类型等# 示例2 找出crond_t是否能够读取/etc/cron.d/checktime这个我们自定义的配置文件
[rootlocalhost ~]# 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)
[rootlocalhost ~]# sesearch -A -s crond_t | grep admin_home_tallow 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类型呢
[rootlocalhost ~]# 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这个规则的状态并且修改这个规则成为不通的布尔值
[rootlocalhost ~]# getsebool httpd_enable_homedirs
httpd_enable_homedirs -- off # 查看是关闭的我们开启他
[rootlocalhost ~]# setsebool -P httpd_enable_homedirs 1
[rootlocalhost ~]# 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范例文件拿某个文件当范例来修改后续接的文件类型# 示例1 查询一下/etc/hosts的SELinux类型并将该类型套用到/etc/cron.d/checktime上
[rootchenshiren ~]# ll -Z /etc/hosts
-rw-r--r--. 1 root root system_u:object_r:net_conf_t:s0 158 6月 23 2020 /etc/hosts
[rootchenshiren ~]# chcon -v -t net_conf_t /etc/cron.d/checktime
正在更改 /etc/cron.d/checktime 的安全上下文
[rootchenshiren ~]# ll -Z /etc/cron.d/checktime
-rw-r--r--. 1 root root unconfined_u:object_r:net_conf_t:s0 26 3月 24 22:19 /etc/cron.d/checktime
-rw-r--r--. root root unconfined_u:object_r:net_conf_t:s0 /etc/cron.d/checktime# 示例2 直接以/etc/shadow的SELinux类型套用到/etc/cron.d/checktime上
[rootchenshiren ~]# chcon -v --reference/etc/shadow /etc/cron.d/checktime
正在更改 /etc/cron.d/checktime 的安全上下文
[rootchenshiren ~]# ll -Z /etc/cron.d/checktime
-rw-r--r--. 1 root root system_u:object_r:shadow_t:s0 26 3月 24 22:19 /etc/cron.d/checktime上面的练习【都没有正确的解答】因为正确的SELinux类型应该是要以 /etc/cron.d/ 下面的文件为标准来处理才对。那么能不能让SELinux自己解决默认目录下的SELinux类型使用restorecon
restorecon让文件恢复正确的SELinux类型
restorecon [-Rv] 文件目录
选项
-R连同子目录一起修改
-v将过程显示到屏幕
# 示例1 将/etc/cron.d/下面的文件通通恢复成默认的SELinux类型
[rootchenshiren ~]# restorecon -Rv /etc/cron.d/
Relabeled /etc/cron.d/checktime from system_u:object_r:shadow_t:s0 to system_u:object_r:system_cron_spool_t:s0
# 上面这两行其实是同一行标识将checktime由shadow_t改成system_cron_spool_t
# 重新启动crond看看有没有正确启动checktime
[rootlocalhost ~]# systemctl restart crond
[rootlocalhost ~]# tail /var/log/cron
.....
....
Mar 25 01:08:15 chenshiren crond[3635]: (CRON) INFO (running with inotify support)
Mar 25 01:08:15 chenshiren crond[3635]: (CRON) INFO (reboot jobs will be run at computers startup.)semanage默认目录的安全上下文查询与修改
你可能会觉得奇怪为什么restorecon可以【恢复】原本的SELinux类型呢那肯定是有个地方在记录每个文件/目录的SELinux默认类型那么如何查询SELinux类型以及如何【增加/修改/删除】默认的SELinux类型呢使用semanage即可
Linux默认没有安装semanage这个命令需要手动安装一下
[rootlocalhost ~]# yum -y install policycoreutils-python semanagesemanage {login|user|port|interfase|fcontext|translation} -l
semanage fcontext -{a|d|m} [-frst] file_spec
选项
fcontext主要用在安全上下文方面的用途-l为查询的意思
-a增加的意思你可以增加一些目录的默认安全上下文类型设置。
-m修改
-d删除
# 示例1 查询一下/etc/ /etc/cron.d默认的SELinux类型是什么
[rootchenshiren ~]# 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类型
[rootchenshiren ~]# mkdir /srv/mycron
[rootchenshiren ~]# cp -rf /etc/cron.d/checktime /srv/mycron/
[rootchenshiren ~]# ll -dZ /srv/mycron/ /srv/mycron/checktime
drwxr-xr-x. 2 root root unconfined_u:object_r:var_t:s0 23 3月 25 01:16 /srv/mycron/
-rw-r--r--. 1 root root unconfined_u:object_r:var_t:s0 26 3月 25 01:16 /srv/mycron/checktime
2. 查看一下上层/srv 的SELinux类型
[rootlocalhost ~]# semanage fcontext -l | grep ^/srv
/srv/.* all files system_u:object_r:var_t:s0
......
..
怪不得mycron会是var_t
3. 将mycron默认值改为system_cron_spool_t
[rootchenshiren ~]# semanage fcontext -a -t system_cron_spool_t /srv/mycron(/.*)?
[rootchenshiren ~]# restorecon -Rv /srv/mycron/
Relabeled /srv/mycron from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:system_cron_spool_t:s0
Relabeled /srv/mycron/checktime from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:system_cron_spool_t:s0
[rootchenshiren ~]# ll -dZ /srv/mycron/ /srv/mycron/*
drwxr-xr-x. 2 root root unconfined_u:object_r:system_cron_spool_t:s0 23 3月 25 01:16 /srv/mycron/
-rw-r--r--. 1 root root unconfined_u:object_r:system_cron_spool_t:s0 26 3月 25 01:16 /srv/mycron/checktime
# 有了默认值到未来就不会不小心被乱改了
