auditd是唯一能精准溯源“谁改了权限”的机制，它通过内核级监控chmod/chown等系统调用，记录uid、命令路径、目标文件及时间戳，不可绕过且支持规则持久化与aureport解析。
auditd 是唯一能查到“谁改了权限”的机制
Linux 文件系统本身不记录权限修改的原始操作者、命令或时间，stat 显示的 Change 时间（ctime）只说明“元数据变了”，但无法区分是 chmod、chown、setfacl 还是内核自动行为（如 restorecon）。真正能回答“谁、在哪儿、用什么命令改了权限”，只有 auditd ——它工作在内核系统调用层，不可绕过，连 root 直接执行也会留下完整记录。
怎么配置 auditd 监控 chmod/chown 类操作
必须用 root 权限添加规则，且需明确指定架构（b64 或 b32）和系统调用名。常见错误是漏掉 -F arch=b64 导致 64 位系统不触发日志。
- 临时启用（重启失效）：
sudo auditctl -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,chown,fchown,fchownat,setxattr -k perm_change - 永久生效：写入
/etc/audit/rules.d/perm.rules，然后运行sudo augenrules --load - 若只关心某个文件（如
/etc/passwd），加-F path=/etc/passwd；监控目录需额外加-w /path/to/dir -p wa，注意-p wa表示 write + attribute change - 规则加载后验证：
sudo auditctl -l | grep perm_change，无输出说明未生效
怎么检索和解读权限变更日志
ausearch 和 aureport 是配套工具，单独用 cat /var/log/audit/audit.log 几乎无法人工解析——日志是二进制编码的原始事件流。
- 查最近 24 小时所有权限变更：
sudo ausearch -k perm_change --start yesterday | aureport -f -i - 关键字段含义：
comm="chmod"是命令名，exe="/usr/bin/chmod"是绝对路径，uid=1001是操作用户 ID，cwd="/home/user"是当前工作目录，name="/target/file"是目标路径 - 如果看到
uid=0但comm="bash"，大概率是脚本调用；若exe="/usr/bin/python3"，说明是 Python 程序触发的权限修改 - 注意：
aureport -f -i会反解 UID/GID 为用户名，但前提是系统有对应账户且未被删除，否则仍显示数字
没开 auditd 时能做什么补救
auditd 未启用时，没有真实操作证据，只能靠间接线索缩小范围，不能确认“谁改的”。别浪费时间在 find -cmin -60 上——它只告诉你“变了”，不是“谁变的”。
- 查认证日志中是否有 sudo 记录：
grep "sudo.*chmod\|sudo.*chown" /var/log/auth.log 2>/dev/null || grep "sudo.*chmod\|sudo.*chown" /var/log/secure 2>/dev/null | tail -10 - 用
stat确认 ctime 是否在可疑窗口内，再结合last -n 30看哪些用户当时在线；w或who -u可查活跃会话登录时间是否与 ctime 接近 - 检查 cron、systemd timer、logrotate 或应用启动脚本里是否含
chmod命令——很多权限变更其实是自动化任务导致的，不是人为操作 - SELinux 的
restorecon也会重置权限，查ausearch -m avc -ts recent看是否有相关拒绝或恢复日志
auditd 规则一旦漏配路径或系统调用名，就彻底丢失证据；日志体积增长很快，/var/log/audit/audit.log 占满会导致审计停止，必须配合 logrotate 或调 max_log_file。真正的权限溯源，从来不是事后翻日志，而是事前把规则覆盖到关键路径上。
