ausearch 查到大量 denied 是 SELinux 正常拦截而非日志错报，需先判断是否影响业务及拒绝是否合理，再通过 grep、audit2why、semanage 等工具精准分析和处置，避免盲目关闭 SELinux 或直接导入 audit2allow 生成的策略。
ausearch 查到大量 denied 是 SELinux 在拦截，不是日志错报
看到 ausearch -m avc -i --start today 输出一堆 denied，第一反应常是“服务出问题了”，其实更大概率是 SELinux 正常工作——它在阻止不符合策略的访问。这些 AVC 拒绝日志本身不表示系统故障，而是策略生效的证据。
关键看两点：是否真影响业务（比如服务起不来、文件写入失败）、拒绝行为是否合理（比如 nginx 尝试读取用户家目录下的配置）。盲目关闭 SELinux 或打补丁前，先确认是不是误报或配置偏差。
快速定位具体哪个进程/路径被拦住
ausearch 默认输出较简略，容易漏掉关键上下文。加 -i 是为了翻译类型和上下文，但还需配合字段筛选：
- 用
ausearch -m avc -i --start today | grep -E "(comm=|path=|name=)"提取调用进程名和目标路径 - 加
--raw | audit2why可直接解释拒绝原因：ausearch -m avc -i --start today --raw | audit2why - 若想看某进程所有 AVC 记录：
ausearch -m avc -i -svx httpd --start today（把httpd换成实际comm值）
audit.log 体积暴增时，别只清日志，先控源头
大量 denied 导致 audit.log 快速膨胀，直接 truncate -s 0 /var/log/audit/audit.log 只是掩耳盗铃。真正要做的：
- 检查是否开启了冗余监控：确认
/etc/audit/rules.d/*.rules里没有重复或过宽的规则（比如-a always,exit -F arch=b64 -S all） - 临时降低 AVC 日志级别（仅调试用）：
echo 0 > /sys/fs/selinux/mls不推荐；更稳妥的是用semanage permissive -a httpd_t把特定域设为宽容模式，观察是否还刷日志 - 确认 auditd 是否启用了压缩/轮转：
systemctl cat auditd看ExecStart=后是否有-f 2（启用日志压缩），/etc/audit/auditd.conf中max_log_file_action = rotate和num_logs = 5是否生效
audit2allow 生成的 .te 不该直接 semodule -i
很多人跑完 ausearch -m avc --start today | audit2allow -M mypolicy 就立刻 semodule -i mypolicy.pp，这是高危操作：
-
audit2allow是基于单次拒绝推导策略，没考虑上下文完整性（比如只放行了 open，没放行 getattr 或 read） - 生成的
.te文件默认用allow，而非mlsconstrain或classmap，可能绕过 MLS/MCS 限制 - 建议先人工审阅：
cat mypolicy.te，确认source_type和target_type是否合理（比如httpd_t→user_home_t多半不该放行） - 测试阶段用
semodule -i mypolicy.pp后，务必用sesearch -A -s httpd_t -t user_home_t验证策略是否精确匹配预期
真正难的不是生成策略，是判断这个 denied 是该被允许，还是本就不该发生——比如 cron 脚本试图连接外部数据库，得先查清楚是不是脚本路径放错了，而不是急着给它开网络权限。
