核心是通过auditctl -a always,exit -F arch=b64 -S execve -F path=/path/to/binary -F key=xxx捕获execve调用，结合-F path精确匹配二进制路径、-F key标记事件，并持久化至/etc/audit/rules.d/后执行augenrules --load生效。
在 Linux 中，利用 auditctl 设置针对特定二进制文件（如 /usr/bin/python3、/bin/bash）的执行轨迹监控，核心是通过 系统调用级审计规则捕获 execve 事件，并关联进程上下文（如父进程、命令行参数、UID/GID）。这不是“锚点”概念的原生术语，而是指在关键可执行路径上建立稳定、可追溯的审计入口点。
一、添加 execve 系统调用监控规则
执行轨迹的核心是程序启动瞬间的 execve 系统调用。需为具体二进制路径设置 -a always,exit 规则，并限定调用条件：
- 使用
-F path=/path/to/binary精确匹配目标文件（注意：该字段匹配的是被execve打开的文件路径，即实际执行的二进制） - 添加
-F perm=x表示“执行权限触发”，但更可靠的是直接匹配execve调用本身 - 推荐写法（以监控
/usr/bin/curl为例）：
sudo auditctl -a always,exit -F arch=b64 -S execve -F path=/usr/bin/curl -F key=exec_curl
说明：
• arch=b64 针对 x86_64 系统（如为 32 位系统改用 b32）
• -S execve 明确捕获该系统调用
• -F key=exec_curl 添加自定义标签，便于后续日志过滤和归类
二、增强上下文记录：捕获参数与进程链
仅记录路径不够，需还原完整执行现场。Audit 默认记录 execve 的 argv 和 envp（需内核支持且未被裁剪），但需确保配置启用：
- 确认
/etc/audit/rules.d/audit.rules中已包含或追加以下基础规则（避免因缓冲区限制截断参数）：
-a always,exit -F arch=b64 -S execve -F key=exec_all
说明：
• 此规则无 path= 限制，用于兜底捕获所有 execve；配合 key 可区分用途
• 实际使用中建议优先用带 path= 的精确规则，避免日志爆炸
• 参数（argc、argv[]）是否完整记录取决于 auditd 配置中的 max_log_file_action 和内核 audit 缓冲区大小，一般默认可用
三、持久化规则并验证生效
临时规则重启后失效，必须写入规则文件并重载：
- 将规则追加到
/etc/audit/rules.d/exec-curl.rules（文件名任意，但需以.rules结尾）：
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/curl -F key=exec_curl
- 重载规则：
sudo augenrules --load（推荐）或sudo systemctl restart auditd - 验证是否加载成功：
sudo auditctl -l | grep curl - 手动触发测试：
/usr/bin/curl --version，然后查日志：sudo ausearch -m execve -i -ts recent | grep curl
输出中应包含：执行时间、UID、PID、PPID、命令路径、完整 argv 数组（如 curl --version）、key 字段等。
四、排查常见盲区
执行轨迹“断连”往往源于以下原因：
-
符号链接绕过：若监控
/usr/bin/python3，但用户运行的是/usr/local/bin/python3（指向同一文件），则不会触发——需监控真实 inode 或所有可能路径 -
解释器间接执行：如
./script.sh被/bin/bash解释，此时只记录bash的execve，脚本路径在argv[1]中，需解析日志内容 -
容器或命名空间隔离：在容器内运行时，宿主机 audit 规则仍可捕获（因
execve是内核级调用），但 PID/PPID 显示的是容器内编号，需结合container_id字段（若启用了容器审计集成） -
规则顺序冲突：若有更宽泛的
execve规则（如-F uid!=0）在前，可能提前匹配并终止匹配流程——保持高精度规则靠前
