审计特定系统调用依赖内核通过syscall编号匹配规则，-S参数由auditctl自动转换为对应架构编号；规则使用always,exit（记录返回值）或always,entry（捕获非法尝试）触发，需内核启用CONFIG_AUDIT和CONFIG_AUDITSYSCALL且auditd服务正常运行。
审计特定系统调用，核心在于让内核在目标 syscall 执行时主动记录事件。这不是应用层日志，而是由内核审计子系统（audit subsystem）在 syscall 入口或出口处捕获并上报的底层行为日志。
审计规则如何匹配系统调用
Linux 审计系统通过 系统调用号（syscall number） 匹配规则，而非函数名。例如 settimeofday 对应的是 syscall 号 169（x86_64），不是字符串 "settimeofday" 本身。内核根据 /usr/include/asm/unistd_64.h 或 uapi/asm/unistd.h 中定义的编号做比对。
- 规则中写的
-S settimeofday实际会被 auditctl 工具自动转为对应架构下的 syscall 编号 - 同一 syscall 在不同架构（如 arm64 vs x86_64）编号可能不同，规则生效依赖当前运行平台
- 支持多 syscall 同时监控，例如
-S open -S openat -S creat可覆盖文件打开类操作
触发时机：always,exit 和 always,entry 的区别
审计规则中的 “always,exit” 表示在 syscall 执行完成、返回用户态前记录；“always,entry” 则是在刚进入内核、参数校验后但尚未执行实际逻辑时记录。两者用途不同：
-
always,exit更常用：能拿到返回值（success=yes/no）、实际影响（如exit=0表示成功），适合判断操作是否生效 -
always,entry适合监控非法尝试：即使参数校验失败（如权限不足）也会记录，可用于检测暴力试探行为 - 不建议混用同一 syscall 的 entry 和 exit 规则，易造成重复日志且难以关联
规则生效依赖两个前提
缺一不可：内核必须启用审计功能，用户空间必须有 auditd 正常接收日志。
- 内核编译需开启
CONFIG_AUDIT=y和CONFIG_AUDITSYSCALL=y，多数发行版默认已启用 - 用户态需安装
audit包，并确保auditd.service处于 active 状态；若只运行auditctl但未启服务，日志会丢失 - 临时规则用
auditctl -a添加，永久规则写入/etc/audit/rules.d/xxx.rules并通过augenrules或重启 auditd 加载
日志字段怎么看关键信息
一条典型 syscall 审计日志包含多个字段，重点关注：
-
type=SYSCALL：标识这是系统调用事件 -
arch=c000003e：x86_64 架构标识（可查arch值对照表） -
syscall=227：实际触发的 syscall 编号（对照头文件可查是clock_settime） -
success=yes：表示内核完成该调用，不等于业务成功（如 write 写 0 字节也 success） -
uid=0 euid=0：真实用户 ID 和有效用户 ID，用于判断提权行为 -
comm="date"：触发进程的命令名（来自argv[0]），注意可能被篡改
