预期目标：

通过开启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都可正常读取文件