SELinux AVC denied日志刷屏但服务正常，说明策略仅记录未阻断；应先切permissive模式验证，再用ausearch+audit2allow分析并加载最小化策略模块，最后切回enforcing。
SELinux AVC denied 日志大量刷屏但服务功能正常，说明策略限制未实际阻断服务运行，只是记录了被拒绝的访问尝试。此时切勿直接禁用 SELinux，应先切换为 permissive 模式快速验证是否为 SELinux 策略问题，并定位具体拒绝项。
确认当前 SELinux 模式并临时切为 permissive
执行命令查看当前状态：
sestatus -v
若输出中 Current mode: 为 enforcing，则执行以下命令临时切换（重启后失效）：
- sudo setenforce 0（0 表示 permissive，1 表示 enforcing）
- 再运行 sestatus 确认已变为 permissive
- 观察 /var/log/audit/audit.log 或 journalctl -t setroubleshoot 是否停止产生 AVC denied 日志
如果日志立即停止，基本可判定是 SELinux 策略导致的“伪告警”——即访问被拒绝但未影响服务逻辑（例如某些诊断、监控、日志轮转或非关键路径的文件读取）。
快速提取高频 AVC 拒绝事件
在 permissive 模式下仍会记录 AVC，便于分析。使用以下命令聚焦高频问题：
- sudo ausearch -m avc -ts recent | audit2why（显示拒绝原因和建议）
- sudo ausearch -m avc -ts recent | audit2allow -w -a（以易读方式展示缺失权限）
- sudo ausearch -m avc -ts recent | audit2allow -a | grep -v "^#" | sort | uniq -c | sort -nr（统计最频繁的拒绝类型）
重点关注 comm=（进程名）、name=（目标文件/路径）、scontext=（源上下文）、tcontext=（目标上下文）和 tclass=（对象类别，如 file、dir、socket）。
针对性生成并加载本地策略模块
对确认需放行的访问行为，生成最小化策略模块：
- 收集最近 10 分钟的 AVC： sudo ausearch -m avc -ts `date --date='10 minutes ago' '+%m/%d/%H:%M:%S'` | audit2allow -M myapp-fix
- 检查生成的 .te 文件内容，确保无过度授权（如避免 grant * 或 unconfined_domain）
- 加载模块：sudo semodule -i myapp-fix.pp
- 切回 enforcing：sudo setenforce 1，观察日志是否收敛
若仍有零星 AVC，可重复上述流程，或使用 sealert -a /var/log/audit/audit.log 获取更友好的分析建议。
避免常见误操作
- 不要直接运行 audit2allow -a -M xxx 而不审查 .te 内容——可能引入不安全规则
- 不要长期停留在 permissive 模式——它失去强制访问控制能力，仅用于诊断
- 不要修改 /etc/selinux/config 中的 SELINUX=disabled——这会彻底关闭 SELinux，不可逆且不合规
- 若服务使用非标准端口或路径，需同步更新其 SELinux 上下文，例如：sudo semanage port -a -t http_port_t -p tcp 8080
排查本质是缩小策略缺口，而非绕过机制。一次精准的 permissive 验证 + audit2allow + 模块加载，通常能解决 90% 的“狂刷日志但服务照常”问题。
