Permissive模式非关闭SELinux，而是记录越权行为而不阻止执行；它保持服务运行、全量输出AVC日志、支持即时切换（setenforce 0）与快速调试闭环（audit2allow生成策略）。
SELinux Permissive 模式不是“关掉安全”，而是让系统一边照常运行、一边如实记录所有越权行为——这才是高效调试的起点。
为什么选 Permissive 而不是直接 disable？
Disabled 模式会彻底关闭 SELinux，日志不产生、问题不暴露，等于蒙眼修车。Permissive 则保留全部策略检查逻辑，只把“拒绝”换成“记录”，关键优势有：
- 服务不中断：Nginx、Samba、Docker 等仍可正常启动和响应
- 日志全量输出：每次被拦的操作都会生成一条 AVC 记录，没有静默失败
- 一次捕获所有问题：避免 Enforcing 下“修一个、冒三个”的循环调试
快速进入并验证 Permissive 状态
无需重启，用 setenforce 即时切换：
- 查看当前模式：getenforce
- 临时切为 Permissive：setenforce 0
- 确认生效（应返回 Permissive）：getenforce
注意：该操作仅在当前运行时有效，重启后恢复 /etc/selinux/config 中的配置。生产环境排查中，优先用此方式，避免意外重启。
精准抓取拒绝日志的关键命令
Permissive 的价值全在日志里，重点盯住 audit.log 中的 AVC 条目：
- 查最近 5 分钟的拒绝事件：ausearch -m avc -ts recent
- 按服务名过滤（如 nginx）：ausearch -m avc -ts recent -c nginx
- 转成易懂说明：ausearch -m avc -ts recent | audit2why
- 存为文件供后续分析：ausearch -m avc -ts $(date -d '5 minutes ago' +%H:%M:%S) | tee /tmp/avc_debug.log
日志里重点关注 scontext（进程上下文）、tcontext（目标文件/端口上下文）、tclass（资源类型）、{read write bind}（具体动作）——这些是写策略的原始依据。
从日志到可用策略的闭环流程
拿到日志后，别手动写 .te 文件。标准做法是用 audit2allow 自动生成模块：
- 提取全部拒绝记录并生成策略模块：grep "avc: denied" /var/log/audit/audit.log | audit2allow -M myapp_fix
- 安装新策略：semodule -i myapp_fix.pp
- 切回 Enforcing 模式测试：setenforce 1，再验证服务是否正常
若仍有问题，重复上述步骤：再操作触发、再收日志、再生成模块。通常 1–2 轮即可覆盖主要访问路径。记得服务升级或目录迁移后重新采集，因为路径变更会导致上下文标签不匹配。
