在Linux怎么利用Auditctl配置针对特定用户ID的文件访问及操作全审计

auditctl监控UID 1000用户所有文件访问需用-a always,exit -F arch=b64 -S open,openat,creat,unlink,unlinkat -F auid=1000 -k user_1000_file_ops，因-w不支持auid字段；auid记录初始登录UID，比uid/euid更可靠溯源。

auditctl 怎么监控 UID 1000 用户的所有文件访问

直接用 -F auid=1000 过滤，但必须搭配系统调用规则（-a），不能用 -w 路径监控——因为 -w 不支持 auid 字段。常见错误是写成 auditctl -w /home/test -p rwxa -F auid=1000，这会静默失败，规则不生效。

正确做法是监听 open、openat、creat、unlink 等关键系统调用，并限定架构和 UID：

sudo auditctl -a always,exit -F arch=b64 -S open,openat,creat,unlink,unlinkat -F auid=1000 -k user_1000_file_ops

• -F arch=b64 必须显式指定，否则 64 位系统上可能漏掉部分调用
• 如果机器同时跑 32 位程序，得额外加一条 -F arch=b32 规则
• auid 是登录时确定的审计 UID，不会随 su 或 sudo 改变，比 uid 更可靠

为什么用 auid 而不是 uid 或 euid

auid 记录的是用户首次登录会话的 UID，哪怕后续用 sudo -u nobody cat /etc/shadow，日志里 auid 仍是原始登录用户的 ID；而 uid 是当前进程有效 UID，euid 是有效用户 ID，两者在提权后都会变，无法追溯真实操作者。

典型误判场景：

• 运维用普通账号登录，再 sudo su - 切 root 后修改配置文件 → uid 和 euid 都是 0，但 auid 仍是 1000
• 脚本中调用 setuid 程序 → uid 变了，auid 不变

所以审计“谁干的”，必须盯 auid，不是 uid。

如何验证规则是否捕获到目标用户行为

别只等真实操作，用 ausearch 主动触发并查日志：

sudo -u testuser touch /tmp/audit_test && sudo ausearch -k user_1000_file_ops -i | grep "auid=1000"

关键检查点：

• 输出中必须有 auid=1000，且 comm 字段为 touch，name 为 /tmp/audit_test
• 如果没结果，先确认 testuser 的 UID 确实是 1000：id -u testuser
• 再检查规则是否加载：sudo auditctl -l | grep user_1000
• 注意：ausearch -k 默认只查最近 24 小时，加 -ts today 更稳妥

持久化规则时要注意 augenrules 的编译顺序

把规则写进 /etc/audit/rules.d/ 下的 .rules 文件后，必须用 augenrules --load，不能直接 systemctl restart auditd——后者只会重载 /etc/audit/audit.rules，而忽略 rules.d/ 目录下分散的文件。

更隐蔽的坑：

• 文件名必须以数字开头（如 10-user-audit.rules），否则 augenrules 会跳过
• 多条规则若涉及同一系统调用（比如都含 open），augenrules 会合并成一行，但字段顺序错乱可能导致过滤失效
• 建议每条规则单独一行，用 # 注释说明用途，避免后期维护时搞混 auid 和 uid 的使用意图

真正难的不是加规则，而是确保 auid 在所有登录路径（SSH、console、cron job）下都被正确继承，以及日志量暴增时能快速过滤出有效事件——这两点没压测过就上线，容易在出事时找不到线索。