预期目标:

通过开启selinux增强服务安全性,但不会影响到正常的服务运行

组件简介:

系统资源都是通过进程来读取更改的,为了保证系统资源的安全,传统的Linux使用用户、文件权限的概念来限制资源的访问,通过对比进程的发起用户和文件权限以此来保证系统资源的安全,这是一种自由访问控制方式(DAC);但是随着系统资源安全性要求提高,出现了在Linux下的一种安全强化机制(SELinux),该机制为进程和文件加入了除权限之外更多的限制来增强访问条件,这种方式为强制访问控制(MAC)。这两种方式最直观的对比就是,采用传统DAC,root可以访问任何文件,而在MAC下,就算是root,也只能访问设定允许的文件。

使用详解:

selinux工作模式

(1)enforcing(强制模式)==> SELinux已经启动, 这是默认策略,此模式会阻止违反规则的行为并以AVC(access vector control)的方式记录到日志于/var/log/audit/audit.log中
(2)permissive(许可模式)==> SELinux已经启动,只把违反规则的行为记录到日志,并不阻止违反规则的行为
(3)disabled(关闭模式)==> 关闭SELinux

selinux工作类型

(1)strict==>每个进程都受限制(仅在CentOS5)
(2)targeted==>默认类型为targeted,主要限制网络服务
(3)minimum==>简化版的targetd,限制部分网络服务(centos7)
(4)mls==>多级安全限制,较为严格

查看selinux状态

getenforce

setstatus

selinux工作模式切换

(1)临时切换(重启会恢复原有状态)

setenforce 0|1  0、1分别代表permissive、enforcing

(2)永久切换(更改配置文件后,需要重启主机生效)

vim /etc/selinux/config

SELINUX=工作模式【enforcing/permissive/disabled】

reboot

selinux工作类型切换

查看工作类型各规则状态

getsebool -a

左边为selinux规则,右边为该规则的状态

切换工作类型

setsebool -P 规则名称 on|off<布尔值1|0>

selinux上下文

安全上下文 (context) 存在于进程与文件中,context随进程一起存入内存中,文件的context存放在其对应的inode中,因此进程在访问文件时,要先读取inode,再判断是否能够访问该文件。 selinux对于文件或者进程等资源的分类依赖于安全上下文,安全上下文决定了程序可以访问哪些资源。

ls -Z    # 显示文件的安全上下文

ps -Z   # 显示进程的安全上下文

context可以有四个字段:user(身份),role(角色),type(数据类型),sensitivity(安全级别)
第一个字段:user有两种类型:unconfined_u(不受限制进程或文件)和system_u( 受限制进程或文件 )
第二个字段:role有两种类型:object_r(文件)和system_r(进程)
第三个字段:type,决定访问权限的字段,在文件上为类型,在程序上为域

例如nginx服务,其本身是httpd程序,那么他的域是httpd_t

程序受域限制只能访问属于这个域的类型的文件,yum安装的nginx默认访问目录为/usr/share/nginx/html,查看下目录下的上下文则知道他只能访问字段类型为httpd_sys_content_t的文件

第四个字段:sensitivity,s0为最低级别,mls工作类型下才有用

修改selinux上下文字段

chcon -u[trl] 文件 #更改上下文字段
chcon -h 文件 #针对软链接文件
chcon –reference=模板文件 文件 #以某个文件为模板复制其上下文(建议采用)
restorecon 文件 #递归恢复默认类型字段(建议采用)

selinux日志问题追踪

selinux的日志记录在/var/log/audot/audit.log中,未配置管理的日志文件阅读体验差,很难查找到问题根源,如下图所示:

安装 setroubleshoot+auditd进行日志审核分析

yum install setroubleshoot-server setroubleshoot -y
service auditd restart

selinux查看下/var/log/message可看到selinux的阻止日志(nginx403错误)

可查看出selinux阻止nginx对文件/usr/share/nginx/html/index.html进行getattr权限的操作,接着下面也给出了事件的ID(可以查看详情)和解决办法,下图为事件ID查询的详情(可信度越高改动文件越小)

后续可通过提取/var/log/message的关键字SELinux来达到对selinux的监控,及时进一步查询引起selinux阻止的原因,然后根据情况进行处理

恢复操作(一边实时监测日志[tail -f /var/log/message]一边操作)

(1)99.5%的可信度的解决方法为恢复文件默认字段,一次就可以解决

/sbin/restorecon -v /usr/share/nginx/html/index.html

(2)1.49%的可信度的解决方法为编译规则模块,恢复nginx的访问需要进行getattr,open,read三次权限的授权编译

mkdir -p /wakamizu/selinux
cd /wakamizu/selinux
ausearch -c ‘nginx’ –raw | audit2allow -M my-nginx
semodule -i my-nginx.pp

这里把编译的文件放在一个文件夹,方便日后迁移主机的时候直接将.te文件复制进行编译,就可以恢复原主机的selinux规则:

yum install selinux-policy-devel -y
cd /wakamizu/selinux
make -f /usr/share/selinux/devel/Makefile 规则名.pp

最终结果nginx都可正常读取文件