audit.rules中execve规则未生效的主因是系统时间回拨导致auditd静默跳过规则文件；需检查mtime、重载规则并修复时间戳，再用augenrules重新加载。
audit.rules 里 execve 规则没生效，先确认是否被时间篡改导致规则加载失败
系统时间被大幅回拨（比如从 2025 年跳回 2023 年）后，auditd 可能拒绝加载或重载 /etc/audit/rules.d/*.rules 中的规则——它内部会校验规则文件的 mtime 是否“合理”，若文件修改时间晚于当前系统时间，部分版本（尤其是 RHEL/CentOS 7/8 的 auditd 3.0+）会静默跳过该文件。你看到 audit.log 里没有 execve 事件，并非规则写得不对，而是压根没加载。
验证方法：
- 运行 sudo auditctl -l | grep execve，如果无输出，说明规则未生效；
- 查看 sudo ausearch -m CONFIG_CHANGE -i | grep -i "load rule"，留意是否有 “failed to load” 或 “skipped due to timestamp” 类似日志；
- 检查规则文件时间：ls -l /etc/audit/rules.d/*.rules，对比其 Modify 时间与 date 输出。
强制重载 execve 审计规则，绕过时间校验
auditd 默认不提供跳过时间校验的开关，但可通过临时清除状态 + 手动注入规则实现补救：
- 先停掉服务：
sudo systemctl stop auditd - 清空内核审计规则缓存：
sudo auditctl -e 0 && sudo auditctl -D（-e 0解锁策略，-D删除所有规则） - 手动加载关键
execve规则（推荐最小集）：sudo auditctl -a always,exit -F arch=b64 -S execve -k execvesudo auditctl -a always,exit -F arch=b32 -S execve -k execve - 重启服务并锁定：
sudo systemctl start auditd && sudo auditctl -e 1
注意：此方式加载的规则是运行时生效，不持久；需同步修复规则文件本身的时间戳（见下一条）。
修复 /etc/audit/rules.d/ 下规则文件的时间戳
仅重载不够，否则下次 auditd 重启或执行 augenrules 仍会跳过。必须让文件 mtime ≤ 当前系统时间：
- 用
touch向前修正（不推荐用未来时间）：sudo touch -d "1 second ago" /etc/audit/rules.d/*.rules - 更稳妥的是统一设为当前时间：
sudo touch /etc/audit/rules.d/*.rules - 确认生效：
sudo augenrules --load（它会重新扫描、合并、加载全部.rules文件） - 检查结果：
sudo auditctl -l | grep execve应有两条输出（b32/b64 各一）
如果你的规则是通过 augenrules 管理的（即启用了 /etc/audit/rules.d/ 目录机制），不要直接编辑 /etc/audit/audit.rules —— 它是生成文件，会被覆盖。
execve 审计日志缺失的其他常见干扰项
即使时间修复了，execve 日志仍可能不出现，需排查以下几点：
-
auditd是否真正运行：systemctl is-active auditd，不是inactive或failed - 内核是否启用 audit 支持：
zcat /proc/config.gz | grep CONFIG_AUDIT（或查/boot/config-$(uname -r)），必须为y或m - 是否被 SELinux 或 systemd-coredump 干扰：临时设
sudo setenforce 0测试，排除 SELinux 策略拦截审计事件上报 - 日志空间是否耗尽：
sudo ausearch -m avc -i若大量 AVC 拒绝且audit.log停更，可能是磁盘满或space_left阈值触发了 discard 模式
时间篡改只是触发点，真正卡住的是 auditd 对文件时间的隐式信任；一旦规则加载失败，后续所有依赖它的子规则（比如基于 -F exe= 的细化过滤）都会失效——这点很容易被忽略。
