auditd 不自动监控自身配置文件和二进制文件的修改，必须手动添加 -w 规则并指定 -p wa 和 -k 标签，写入 /etc/audit/rules.d/ 并 augenrules --load 才能永久生效；查询需用 ausearch -k -i，未提前监控则无法确证操作者。

auditd 本身不记录“谁修改了 auditd 配置或二进制文件”

auditd 守护进程的配置文件（/etc/audit/auditd.conf）、规则文件（/etc/audit/rules.d/*.rules）和可执行文件（/sbin/auditd）本身，**不会被 auditd 自动监控**——它不审计自己。你查不到“谁改了 /etc/audit/auditd.conf”，除非你**提前手动加了规则监控这些路径**。

常见错误是以为 auditctl -l 显示一堆规则，就默认 auditd 在管自己；其实没有。内核审计子系统不递归审计自身加载过程，这是设计使然，避免死锁和日志污染。

• auditd 启动时读取 /etc/audit/auditd.conf 和 /etc/audit/rules.d/ 下的规则，但读取行为（openat、read）默认不记录
• 修改 /etc/audit/rules.d/my.rules 文件本身，和修改 /etc/passwd 没本质区别——都只是普通文件写入，必须显式用 -w 监控
• 重载规则（augenrules --load 或 systemctl reload auditd）会触发 execve 调用，但 auditd 不自动记录该调用的上下文，除非你额外加了系统调用规则

想查谁改了 auditd 的配置文件，得先监控这些路径

必须用 root 手动添加针对 auditd 自身关键路径的 -w 规则，且要覆盖写入（-p w）和属性变更（-p a），因为 chmod/chown 也会影响生效：

• sudo auditctl -w /etc/audit/auditd.conf -p wa -k auditd_conf_mod
• sudo auditctl -w /etc/audit/rules.d/ -p wa -k auditd_rules_mod（注意：目录需加 -r 才递归，但旧内核可能不支持；稳妥起见单独监控每个 .rules 文件）
• sudo auditctl -w /sbin/auditd -p a -k auditd_bin_attr（二进制文件通常只关心权限/属主变更，内容改写极罕见）

永久生效必须写进 /etc/audit/rules.d/ 下的新文件（如 10-auditd-self.rules），再运行 sudo augenrules --load。否则重启后规则消失，历史就断了。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

查日志时，-k 比 -f 更可靠，-i 必须加

用 ausearch 查的时候，别用 -f /etc/audit/auditd.conf —— 如果该文件被软链接指向、或规则里监控的是 /etc/audit/rules.d/ 目录下某个具体文件，-f 可能漏掉事件。统一用 -k 标签过滤：

• sudo ausearch -k auditd_conf_mod -i | head -15
• sudo ausearch -k auditd_rules_mod -i --start yesterday

不加 -i，输出里全是 uid=0、pid=1234、comm="bash" 这种原始值，看不出是谁登录后执行的。加了 -i 才能反解出用户名、命令名、完整路径。如果看到 comm="(unknown)"，说明进程已退出，此时要看 exe 字段（如 exe="/usr/bin/python3"）和 auid（原始登录用户 ID）来定位操作源头。

没提前监控？只能靠间接线索缩小范围

auditd 没开规则前的修改，无法回溯真实操作者。这时候只能拼凑时间窗口内的旁证：

• 查认证日志中是否有可疑 sudo 行为：grep "sudo.*audit\|sudo.*augenrules\|sudo.*auditctl" /var/log/auth.log 2>/dev/null | tail -10
• 确认修改时间是否与 stat /etc/audit/auditd.conf 的 Modify: 时间吻合（注意：这个时间会被任何写入刷新，不等于“人工编辑时间”）
• 检查 systemctl status auditd 的最近启动/重载时间，和 journalctl -u auditd --since "2 hours ago" 是否有异常日志
• 若系统启用了 pam_faildelay 或其他 PAM 审计模块，可查 /var/log/secure 中对应时段的登录链路

真正能锁定“哪个账户”干的，只有提前部署的 -w + -k + -i 组合。事后补救永远是推测，不是证据。