审计特定系统调用依赖内核通过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]），注意可能被篡改