auditctl -w规则需配对-p权限位和-k标签，否则加载成功却查不到日志；必须确保路径真实存在、auditd运行中且enabled=1、规则持久化须经/etc/audit/rules.d/写入并执行augenrules --load。
直接用 auditctl -w 加路径就行，但必须配对 -p 权限位和 -k 标签，否则规则加载成功却查不到日志——这是 80% 的“没记录”问题根源。
auditctl -w 规则为什么加了却没日志？
常见现象：执行 sudo auditctl -w /etc/passwd -p wa -k passwd_mod 后，改文件也没进 /var/log/audit/audit.log。
- 路径不存在或挂载在
/proc、/sys等虚拟文件系统上 ——auditd会静默跳过，不报错也不加载 -
-p漏写或写错：-p w只捕获写入，chmod属于属性变更，得加a（即-p wa） - 没确认
auditd真正在跑：systemctl status auditd必须是active (running)，不是inactive (dead) -
-k标签没用对：后续查日志必须用ausearch -k passwd_mod -i，不能只tail /var/log/audit/audit.log
永久生效必须走 /etc/audit/rules.d/ + augenrules
临时规则重启就丢，生产环境必须固化。但规则文件名和写法有硬性要求：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 文件必须放在
/etc/audit/rules.d/下，且后缀为.rules（如10-passwd.rules），audit.conf或myrule这类名字会被augenrules完全忽略 - 内容只写规则行，不要带
auditctl命令前缀：-w /etc/passwd -p wa -k passwd_mod✔️，auditctl -w /etc/passwd ...❌ - 写完必须手动触发重载：
sudo augenrules --load—— 它会合并所有.rules文件生成/etc/audit/audit.rules，再调用auditctl -R加载 - 验证是否真进内核：
sudo auditctl -l | grep passwd_mod能看到才算生效
监控目录时 -p rwxa 不等于“全抓”，要小心性能陷阱
比如想监看 /home 下所有操作，写成 -w /home -p rwxa -k home_access 看似合理，实际极易出问题：
-
-p r是高频操作：一个ls就触发几十次openat+read，日志秒变洪水，auditd可能丢事件甚至卡住 - 子目录递归不自动：-w 只监控该目录本身，
/home/alice/.bashrc这类路径不会被捕获，除非显式写-w /home/alice -p wa - 更稳妥的做法是缩小范围：
-w /home -p wa -k home_write（只盯写和属性变更），或改用系统调用规则-a always,exit -F dir=/home -F perm=wa - 如果真要全量读写，务必同步调大
/etc/audit/audit.conf中的queue_size和max_log_file，否则日志直接被截断
查不到 execve 日志？缺 -F arch=b64 是最常见原因
想审计“谁运行了什么命令”，只写 -w /usr/bin/rm -p x -k rm_exec 会漏掉大量情况，因为现代 Linux 上 execve 系统调用分架构：
- 64 位程序走
arch=b64，32 位程序走arch=b32；不指定-F arch，auditd默认只匹配当前架构，很可能漏报 - 正确写法（推荐双架构覆盖）：
-a always,exit -F arch=b64 -S execve -F auid>=1000 -k user_cmd+ 一行-F arch=b32规则 -
-w路径监控无法捕获动态加载的二进制（如./payload），必须用-S execve系统调用级规则才可靠 - 查这类日志别只用
ausearch -k user_cmd，加上-m SYSCALL过滤类型，避免混入其他事件
真正麻烦的从来不是加一条规则，而是确认它在内核里活得好好的——auditctl -l 看得到、ausearch -k xxx 查得出、tail -f /var/log/audit/audit.log 实时刷出新行，三者缺一不可。
