SELinux拦截动作需用ausearch精准抓取AVC拒绝事件，而非grep日志；每条记录含scontext、tcontext、tclass、perm四要素；audit2why可翻译拒绝原因，sealert提供结构化修复建议。
直接用 ausearch 抓 AVC 拒绝事件
SELinux 的拦截动作不会出现在 /var/log/messages 或 journalctl 默认输出里，原始记录只在 /var/log/audit/audit.log 中，且必须用专用工具过滤。直接 grep "denied" 容易漏掉关键字段（比如没带 avc 标签的记录），也分不清是 SELinux 还是其他审计事件。
正确做法是用 ausearch 精准定位 AVC 类型的拒绝：
-
sudo ausearch -m avc -ts recent：查最近 10 分钟的全部 AVC 拒绝 -
sudo ausearch -m avc -c httpd：只看httpd进程触发的拒绝 -
sudo ausearch -m avc -f /var/www/html/index.html：聚焦某个具体路径
每条输出里都含 scontext（进程上下文）、tcontext（目标上下文）、tclass（对象类型，如 file）、perm（被拒操作，如 read）——这四要素就是问题的最小可复现单元。
用 audit2why 翻译成人类语言
ausearch 输出的是原始审计日志，对人不友好。比如你看到 avc: denied { open } for ... scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file，光看字段很难立刻判断该修文件标签还是开布尔值。
audit2why 就是干这个翻译活的：
-
sudo ausearch -m avc -ts recent | audit2why：把最近所有拒绝逐条解释成“缺哪条规则”“类型是否不匹配” - 典型输出：
Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module...或更实用的提示：tcontext type user_home_t does not match expected type httpd_sys_content_t
它不生成策略，只告诉你“为什么拦”，避免你一上来就用 audit2allow 盲目放行。
用 sealert 获取结构化诊断建议
如果你装了 setroubleshoot（多数 CentOS/RHEL 默认有，Ubuntu 需手动 apt install setroubleshoot），sealert 能把零散的日志聚合成带编号的问题报告，并给出可执行建议：
-
sudo sealert -a /var/log/audit/audit.log：分析整个日志，按问题聚类 - 每条 alert 包含唯一 ID、时间戳、影响服务、推荐修复命令（如
restorecon -Rv /path或setsebool -P httpd_read_user_content 1） - 比
audit2why更进一步：它会区分“文件标签错配”“端口未授权”“布尔值关闭”三类高频原因，并优先推荐最安全的修复路径
注意：sealert 不实时监听，必须等日志写满或手动触发分析；它的建议通常比 audit2allow 更保守，适合生产环境快速决策。
别跳过 ls -Z 和 getenforce 验证环节
很多人查了半天日志，最后发现根本不是 SELinux 在拦——要么 getenforce 返回 Disabled，要么 sestatus 显示策略没加载。或者日志里明明是 httpd_t 访问 user_home_t，但你 ls -Z /home/user/public_html 发现标签其实是 httpd_sys_content_t，说明日志时间戳和当前状态已不同步。
- 每次分析前先跑：
getenforce和ls -Z /path/involved - 临时切宽容模式验证：
sudo setenforce 0→ 复现问题 → 若正常，再sudo setenforce 1回来继续查 -
ls -Z结果要和日志里的tcontext对得上，否则说明上下文已被改过，得结合restorecon -v看是否回滚成功
日志是快照，系统状态是动态的。忽略这两步，再准的 audit2why 输出也可能指向一个已不存在的问题现场。
