从Permissive到Enforcing：SELinux工作模式实战切换与策略调试指南

1. SELinux工作模式深度解析

第一次接触SELinux时，我被它复杂的策略规则搞得一头雾水。直到有次服务器莫名其妙拒绝了一个明明有权限的操作，才真正意识到这个安全机制的重要性。SELinux就像个严格的安检员，而它的三种工作模式——Disabled、Permissive、Enforcing——相当于安检的三个级别。

Disabled模式相当于完全关闭安检通道，所有人和物品都能自由进出。虽然方便，但安全性最低。我见过不少运维为了省事直接禁用SELinux，结果服务器被入侵后才追悔莫及。关闭方法很简单：

sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config

但切记，这就像拆掉家里的防盗门，除非是在完全可信的内网环境，否则强烈不建议。

Permissive模式最像现实中的安检培训场景。安检员会记录所有违规行为，但不会真正阻拦。这是我调试新服务时最常用的模式，既能收集策略违规日志，又不会影响服务正常运行。切换到该模式的命令是：

setenforce 0

Enforcing模式则是全副武装的安检状态，任何不符合策略的操作都会被立即阻止。生产环境必须保持这个模式，但需要先确保所有策略都经过充分测试。切换到强制模式的命令是：

setenforce 1

2. 新服务部署的Permissive模式实战

去年部署Prometheus监控系统时，我就深刻体会到了Permissive模式的价值。刚安装完启动服务，虽然页面能访问，但/var/log/messages里不断出现SELinux拒绝日志。这时候如果直接开Enforcing模式，服务会直接挂掉。

正确的做法是：

1. 先将系统切换到Permissive模式
2. 正常操作服务，触发所有可能的访问场景
3. 使用audit2allow工具生成策略模块：

grep "avc: denied" /var/log/audit/audit.log | audit2allow -M prometheus_custom semodule -i prometheus_custom.pp

这个流程我重复了三次才覆盖所有必要的访问权限。有个容易忽略的细节：服务更新后可能需要重新生成策略，因为二进制文件路径变化会导致上下文标签失效。

3. 故障排查中的模式切换技巧

上个月有个典型案例：Nginx突然无法读取某些静态文件，但权限设置明明是正确的。这时候快速判断是否SELinux导致的方法很关键：

1. 临时切换到Permissive模式：

setenforce 0; systemctl restart nginx

2. 如果问题消失，基本确定是SELinux策略问题
3. 检查最新拒绝日志：

ausearch -m avc -ts recent | audit2why

我遇到的情况是有人误改了文件上下文标签，修复命令很简单：

restorecon -Rv /path/to/webroot

但切记排查后要立即切换回Enforcing模式，避免长时间处于低安全状态。

4. 平稳过渡到Enforcing模式的策略

从Permissive到Enforcing不是简单改个参数就行。根据我的经验，需要分阶段实施：

第一阶段：监控模式在/etc/selinux/config中设置：

SELINUX=permissive

然后重启服务器，这样系统启动时就会记录所有策略违规，但不会阻止操作。

第二阶段：策略优化使用sealert工具分析日志：

sealert -a /var/log/audit/audit.log > report.txt

对重复出现的拒绝项，要么修改策略，要么调整文件上下文。有个实用技巧是使用semanage命令永久修改上下文：

semanage fcontext -a -t httpd_sys_content_t "/webapps(/.*)?"

第三阶段：强制模式测试先在非核心业务服务器上启用Enforcing，观察1-2个业务周期：

setenforce 1

确认无异常后再全局推广。记得在变更窗口进行操作，准备好回退方案。

5. 高级调试与策略管理

当默认策略不够用时，就需要自定义策略模块。我的工作流程是：

1. 使用audit2allow生成基础模块：

ausearch -m avc -ts today | audit2allow -M mypolicy

2. 手动编辑.te文件细化规则：

vi mypolicy.te

比如添加：

allow httpd_t user_home_t:file { read getattr };

3. 编译并加载模块：

make -f /usr/share/selinux/devel/Makefile mypolicy.pp semodule -i mypolicy.pp

对于复杂场景，建议使用sepolicy generate生成完整策略框架：

sepolicy generate --init /usr/sbin/nginx

策略模块管理也很重要，我定期用以下命令查看已加载模块：

semodule -l

过时的模块要及时清理：

semodule -r old_policy

6. 生产环境最佳实践

经过多次踩坑，我总结了这些黄金法则：

1. 永远不要禁用SELinux，即使遇到问题也应保持Permissive模式收集日志
2. 修改文件权限前先检查SELinux上下文：

ls -Z /path/to/file

3. 备份重要策略模块：

semodule -B

4. 使用布尔值快速调整策略：

setsebool -P httpd_can_network_connect on

5. 定期检查拒绝日志：

sealert -a /var/log/audit/audit.log

有次我花了三小时排查一个诡异的权限问题，最后发现只是因为有人手动修改了文件而没有恢复上下文。现在我的团队有个铁律：任何文件操作后都要执行restorecon。