Linux audit内核审计原理与生产级规则实战-开发者社区

1. 审计这件事，远不是“记个日志”那么简单

很多人第一次接触 audit，是在某次安全检查后被要求“补上系统审计策略”，或者在排查一个权限异常问题时，发现/var/log/audit/audit.log里密密麻麻全是看不懂的type=SYSCALL记录。于是下意识觉得：哦，这是个高级版 syslog，专门记安全相关的事——这种理解，错得挺彻底，也踩过坑的开发者和运维同学都知道，audit 和 syslog 根本不是同一维度的东西，更不是“谁替代谁”的关系。它不走 rsyslog 的管道，不依赖用户态日志服务，甚至不经过内核的 printk 机制；它是 Linux 内核原生内置的一套事件捕获与规则驱动框架，直接运行在内核空间，对系统调用、文件访问、权限变更等底层行为进行毫秒级拦截与结构化记录。你改了/etc/passwd，audit 能精确到哪个进程、哪个 UID、调用了哪个系统调用（openat还是write）、操作了哪个 inode、是否成功；而 syslog 只能告诉你“sshd[1234]：pam_unix(sshd:session): session opened for user admin”，连具体执行了什么命令都看不到。真正用起来你会发现，audit 是唯一能回答“谁、在什么时间、以什么身份、通过什么程序、对什么文件/资源、执行了什么敏感操作”这五个 W 问题的工具。它不是给管理员看的“友好日志”，而是给安全分析平台喂的“原始数据燃料”。所以本文不讲“怎么装 auditd”，而是带你一层层剥开 audit 的设计逻辑、规则语法、真实场景下的配置陷阱，以及它和 syslog、secure 日志之间那些常被混淆却至关重要的分工边界。无论你是刚接手合规整改的安全工程师，还是需要定位 root 权限滥用的 SRE，或是正在写 SOC 检测规则的蓝队分析师，这篇内容都会帮你把 audit 从“配过但不敢动”的黑盒，变成手边可精准控制的审计探针。

2. audit 的底层逻辑与架构设计：为什么它必须绕开 syslog？

2.1 audit 不是日志服务，而是一套内核事件总线

audit 的核心设计哲学，是“最小信任、最大保真、零依赖用户态”。这句话拆开来看：

最小信任：audit 规则由内核直接解析并加载，所有匹配动作（如记录、拒绝、发送信号）都在内核态完成。这意味着即使 rsyslogd 进程被 kill、systemd-journald 崩溃、甚至整个用户空间被恶意冻结，audit 依然能持续捕获关键事件并缓存到内核环形缓冲区（audit backlog）。我曾在某次模拟勒索软件攻击测试中验证过：当所有用户态服务被终止后，ausearch -m avc -ts recent仍能查出 SELinux 拒绝记录，而/var/log/messages已完全停更。
最大保真：audit 记录的是原始系统调用上下文，而非事后拼凑的日志字符串。每条 audit 记录包含auid（登录会话初始 UID，不可伪造）、uid（当前进程 UID）、euid（有效 UID）、ses（会话 ID）、comm（进程名）、exe（可执行文件路径）、key（规则标记）、cwd（当前工作目录）、path（被访问文件路径）、inode（文件 inode 号）等数十个字段。这些字段全部来自内核数据结构，未经任何格式化或截断。相比之下，/var/log/secure里一条sudo: admin : TTY=pts/0 ; PWD=/home/admin ; USER=root ; COMMAND=/bin/bash是由 sudo 程序自己拼出来的字符串，字段缺失、长度截断、格式不统一是常态。
零依赖用户态：auditd 进程只是 audit 子系统的“搬运工”和“落盘器”，它从内核读取事件、做简单过滤、写入磁盘文件、触发告警。真正起作用的是内核里的audit_tree、audit_filter、audit_netlink等模块。你可以systemctl stop auditd，audit 规则依然生效，事件依然被捕获，只是暂时堆积在内核缓冲区（受auditctl -b设置的缓冲区大小限制）。而 syslog 的一切功能，都建立在 rsyslogd 或 journald 正常运行的基础上。

提示：auditctl -s输出中的enabled字段为1表示内核 audit 功能已启用，failure字段为1表示失败事件（如规则加载失败）也会被记录，pid字段显示当前 auditd 进程 ID。这三个值才是 audit 是否真正工作的黄金指标，而不是看/var/log/audit/audit.log是否有新内容。

2.2 audit、syslog、secure 三者的职责边界图谱

很多人纠结“audit 和 syslog 到底该用哪个”，本质是没理清它们在系统日志体系中的定位。下面这张对比表，是我根据上百个生产环境审计策略梳理出的真实分工：

维度	audit	syslog（rsyslog）	/var/log/secure
数据来源	内核系统调用、文件访问、能力变更、SELinux AVC	用户态程序主动调用`syslog()`或`journal_printk()`	rsyslog 的一个特定规则输出（通常匹配`authpriv.*`）
记录粒度	进程级、文件 inode 级、系统调用级（如`openat`,`execve`,`setuid`）	应用级、服务级（如 “sshd connection closed”, “cron job started”）	服务级（仅 authpriv 设施，聚焦认证、授权、密码修改）
关键字段	`auid`,`uid`,`euid`,`ses`,`comm`,`exe`,`path`,`inode`,`key`	`HOSTNAME`,`PROGRAMNAME`,`MSG`（纯文本，无结构）	同 syslog，但字段更窄，仅限 PAM、sudo、sshd 等 auth 相关服务
不可篡改性	高（需 root+cap_sys_admin 才能清空或禁用，且`auid`在登录时即固化）	低（普通用户可伪造日志，root 可任意删除）	低（同 syslog，且易被覆盖）
典型用途	合规审计（等保2.0、GDPR）、特权操作追溯、入侵取证、行为基线建模	系统健康监控、服务状态跟踪、调试辅助	快速查看登录失败、sudo 使用、密码修改等高频安全事件

举个具体例子：当某用户通过sudo su -切换到 root 并执行rm -rf /tmp/data时：

audit 记录：
type=SYSCALL msg=audit(1712345678.123:456789): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=7fffe8765432 a2=941 a3=1f items=2 ppid=1234 pid=5678 auid=1001 uid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="bash" exe="/usr/bin/bash" key="delete_files"
→ 它告诉你：PID 5678 的 bash 进程（auid=1001，即原始登录用户），以 uid=0（root）身份，调用了openat系统调用（syscall=257），打开了/tmp/data（由后续type=CWD和type=PATH记录关联），且标记为key="delete_files"。
/var/log/secure 记录：
Apr 5 10:23:45 hostname sudo: admin : TTY=pts/0 ; PWD=/home/admin ; USER=root ; COMMAND=/bin/bash
Apr 5 10:23:46 hostname su: pam_unix(su-l:session): session opened for user root by admin(uid=1001)
→ 它只告诉你“admin 切到了 root”，但没说 root 接下来干了什么。
syslog 其他记录：
Apr 5 10:23:47 hostname kernel: audit: type=1300 audit(1712345678.123:456789): arch=c000003e syscall=257 ...（这是 audit 事件被转发到 syslog 的副本，非原始）
→ 这是 auditd 主动发给 rsyslog 的“镜像”，字段被压缩，auid等关键字段可能丢失。

注意：audit 事件可以被 auditd 配置为同时写入/var/log/audit/audit.log和转发给 rsyslog（通过/etc/audit/rules.d/audit.rules中的-w /etc/shadow -p wa -k identity规则 +/etc/audisp/plugins.d/syslog.conf启用）。但这只是“分发”，不是“替代”。真正的审计源头永远在内核。

2.3 audit 的三层规则体系：如何让内核听懂你的指令

audit 规则不是简单的“关键词匹配”，而是一个分层、可组合、带优先级的事件过滤引擎。理解这三层，是写出高效、不误报、不漏报规则的前提。

第一层：控制规则（Control Rules）
以-e开头，用于开关 audit 功能本身。例如：
-e 2→ 启用 audit（2表示启用并锁定，此后无法用auditctl -e 0关闭，需重启）
-b 8192→ 设置内核环形缓冲区大小为 8192 条记录（默认 8192，但高负载系统建议调大）
-f 1→ 设置 audit 失败时的行为：1表示SYSLOG（写入 syslog），2表示SINGLE（切换到单用户模式），3表示HALT（立即 halt）。生产环境强烈建议-f 1，避免因 audit 故障导致业务中断。

第二层：文件系统规则（File System Rules）
以-w开头，监控文件或目录的访问。这是最常用、也最容易出错的一层。语法为：
-w <path> -p <permissions> -k <key>
其中-p的四个权限位含义必须死记：

r：读取（read,readv,pread,mmapwithPROT_READ）
w：写入（write,writev,pwrite,mmapwithPROT_WRITE）
x：执行（execve,openwithO_EXEC）
a：属性变更（chmod,chown,setxattr,removexattr）

常见误区：

误以为-w /etc/passwd -p rw就能监控所有修改。错！/etc/passwd是文本文件，但usermod等命令实际操作的是/etc/passwd-临时文件，再rename替换。正确做法是监控整个/etc目录的a权限：-w /etc -p a -k identity。
误用-w /proc。/proc是虚拟文件系统，audit 对其支持有限，且会产生海量无效记录。应避免。

第三层：系统调用规则（System Call Rules）
以-a开头，最强大也最复杂。语法为：
-a <list>,<action> -S <syscall> -F <field>=<value> -k <key>
其中<list>是规则插入点，决定匹配时机：

task：进程创建时（极少用）
exit：系统调用返回后（最常用，如-a exit,always -S execve）
user：用户态消息（auditd 发送）
exclude：排除特定事件（如-a exclude,always -F msgtype=CONFIG_CHANGE）

<action>是匹配后的动作：

never：永不记录（用于排除）
always：总是记录
possible：可能记录（需结合其他条件）

-S execve是核心，它捕获所有程序执行事件。但光有-S execve不够，必须加-F auid!=4294967295过滤掉auid=4294967295（即未登录用户的匿名会话），否则 cron、systemd-timers 等后台任务会刷屏。完整规则：
-a exit,always -F arch=b64 -S execve -F auid!=4294967295 -k exec
（arch=b64指定 64 位系统调用，避免 32 位兼容层干扰）

实操心得：规则顺序很重要！audit 按从上到下顺序匹配，一旦匹配到never规则就终止。所以“排除规则”必须放在“捕获规则”之前。例如，先写-a exclude,always -F msgtype=CONFIG_CHANGE，再写-a exit,always -S execve。

3. 常见审计规则详解与生产环境实战组合

3.1 权限与身份管理类：守住“谁在什么时候获得了什么权限”

这类规则是等保2.0“安全审计”章节的硬性要求，也是入侵检测的第一道防线。核心思路是：监控所有能改变用户身份、组身份、能力集（capabilities）的系统调用。

规则1：监控所有 sudo、su、login 等提权行为

# 监控 execve 调用，但只记录明确的提权程序 -a exit,always -F arch=b64 -S execve -F auid!=4294967295 -F path=/usr/bin/sudo -k privilege_escalation -a exit,always -F arch=b64 -S execve -F auid!=4294967295 -F path=/bin/su -k privilege_escalation -a exit,always -F arch=b64 -S execve -F auid!=4294967295 -F path=/usr/bin/login -k login_session

为什么不用-F comm=sudo？因为comm是进程名，可被prctl(PR_SET_NAME)伪造；而path是可执行文件的绝对路径，由内核mm_struct中的arg_start解析，更可靠。-F auid!=4294967295过滤掉 cron 等无 auid 的进程，避免噪音。

规则2：监控 /etc/passwd、/etc/shadow、/etc/group 等关键身份文件的任何变更

# 监控整个 /etc 目录的属性变更（chown/chmod）和写入 -w /etc -p wa -k identity_files # 单独强化监控 shadow 文件的读取（防止密码导出） -w /etc/shadow -p r -k password_dump

这里-p wa是关键：w捕获write（如useradd写入新用户），a捕获chown/chmod（如chmod 600 /etc/shadow）。而-w /etc/shadow -p r是防御性设计——正常运维几乎不会读取 shadow，一旦出现，极可能是攻击者在尝试离线破解。

规则3：监控 capabilities 的授予与剥夺

# 监控 setcap/setpcap 系统调用 -a exit,always -F arch=b64 -S setcap -F auid!=4294967295 -k cap_change -a exit,always -F arch=b64 -S setpcap -F auid!=4294967295 -k cap_change

Capabilities 是 Linux 的细粒度权限模型，setcap /usr/bin/ping cap_net_raw+ep可让 ping 绕过 root 限制。攻击者常利用此提升权限。这条规则能第一时间发现异常 capability 授予。

注意事项：setcap调用本身不修改文件内容，所以-w /usr/bin/ping -p w不会触发。必须用-S setcap捕获系统调用。

3.2 文件与数据访问类：追踪“敏感数据流向何方”

这类规则直指数据防泄漏（DLP）和合规审计的核心。难点在于：如何定义“敏感文件”？如何避免海量日志淹没关键事件？

规则4：监控所有对 /home/*/、/root/ 下文件的写入和执行

# 监控所有用户主目录的写入（防止 webshell 上传） -w /home -p wa -k user_home_write # 监控 root 目录的执行（防止恶意脚本运行） -w /root -p x -k root_exec

/home是递归监控的，audit 会自动为每个子目录建立 inotify watch。但要注意：如果/home下有大量小文件（如邮件 spool），-w /home -p wa会耗尽 inotify 句柄。此时应细化到/home/*/public_html或/home/*/www等 Web 目录。

规则5：监控 /tmp、/var/tmp 等临时目录的执行行为

-w /tmp -p x -k tmp_exec -w /var/tmp -p x -k tmp_exec

99% 的内存马、无文件攻击（fileless attack）都依赖在/tmp下释放并执行二进制或脚本。这条规则是检测此类攻击的黄金标准。-p x比-p rw更精准，因为攻击者只需执行，无需读写。

规则6：监控数据库、中间件配置文件的读取

# MySQL 配置 -w /etc/my.cnf -p r -k db_config_read # Redis 配置 -w /etc/redis/redis.conf -p r -k db_config_read # Tomcat 配置 -w /opt/tomcat/conf -p r -k app_config_read

配置文件里常含数据库密码、API Key。攻击者拿下 Web 服务器后，第一件事就是读取这些文件。-p r触发成本低，且auid能准确定位是哪个会话发起的读取。

实操心得：不要试图监控“所有 .conf 文件”。-w /etc -p r会产生数万条日志（systemd、dbus 等频繁读取）。必须按业务重要性，逐个添加关键配置路径。我的经验是：先列出现网所有中间件、数据库、自研服务的配置文件绝对路径，再逐条加-w规则。

3.3 网络与进程行为类：识别“异常连接与可疑进程”

这类规则用于威胁狩猎（Threat Hunting），目标是发现 C2 通信、横向移动、持久化等高级攻击行为。

规则7：监控所有出站网络连接（connect 系统调用）

-a exit,always -F arch=b64 -S connect -F auid!=4294967295 -k network_connect

connect是 TCP/UDP 建立连接的核心调用。这条规则能捕获所有进程的出站连接，包括curl、wget、nc、python -c "import socket;..."等。配合ausearch -k network_connect -i | grep "dest="可快速提取目标 IP。但注意：它会产生大量日志，建议在高流量服务器上，用-F dest=10.0.0.0/8等过滤内网地址，只关注外联。

规则8：监控非常规端口上的监听（bind 系统调用）

-a exit,always -F arch=b64 -S bind -F auid!=4294967295 -F port>1024 -k unusual_bind

bind用于进程监听端口。-F port>1024过滤掉常规服务（http/80, https/443, ssh/22），只关注 1024 以上端口的监听，这正是 webshell、反弹 shell、代理工具（如 frp）的典型特征。

规则9：监控 ptrace 系统调用（进程注入与调试）

-a exit,always -F arch=b64 -S ptrace -F auid!=4294967295 -k process_injection

ptrace是 Linux 下进程调试和注入的核心接口。gdb、strace、ltrace会用它，但恶意软件如 Mimikatz、Cobalt Strike 的 injector 也依赖它。这条规则能发现隐蔽的进程内存操作。

常见问题：ptrace规则会记录大量strace -p <pid>的运维操作。解决方案是加-F auid=1001（指定某个运维账号的 auid）或-F comm!=strace（排除 strace 进程），但后者有绕过风险。更稳妥的做法是：将strace加入白名单路径，用-F path=/usr/bin/strace单独放行，并打上key=strace_admin标签，便于区分。

4. audit 规则的部署、验证与性能调优全流程

4.1 从规则编写到永久生效：四步落地法

audit 规则不能只靠auditctl -a临时加载，必须固化为开机自启。以下是我在多个金融、政务客户现场验证过的标准流程：

第一步：规则编写与语法校验
所有规则写入/etc/audit/rules.d/下的.rules文件，如10-critical.rules。文件名前缀数字决定加载顺序（越小越先）。编写后，用augenrules --check校验语法：

# 检查所有 rules.d 下的文件语法 augenrules --check # 输出：No errors found in rules

若报错，如Error - Invalid field name 'auid'，说明内核版本过低（需 2.6.35+）或 audit-tools 版本太旧。

第二步：生成并加载规则集

# 生成最终规则文件 /etc/audit/audit.rules augenrules --load # 立即生效（等价于 auditctl -R /etc/audit/audit.rules） # 验证是否加载成功 auditctl -l | head -10

auditctl -l显示当前所有加载的规则。注意：augenrules --load会清空之前所有临时规则，只加载/etc/audit/rules.d/下的内容。

第三步：重启 auditd 并确认状态

systemctl restart auditd # 检查 auditd 是否正常运行 systemctl status auditd | grep "active" # 检查内核 audit 是否启用 auditctl -s | grep "enabled"

关键指标：enabled=1,failure=1,pid有数值。若pid=0，说明 auditd 没起来，需查/var/log/audit/audit.log或journalctl -u auditd。

第四步：日志轮转与磁盘空间保护
audit 日志增长极快，必须配置 logrotate。编辑/etc/logrotate.d/auditd：

/var/log/audit/*.log { weekly rotate 12 compress delaycompress missingok notifempty create 0600 root root # 关键：当日志达到 50MB 时强制轮转，防止单个文件过大 size 50M }

并确保auditd配置/etc/audit/auditd.conf中：
max_log_file = 50（单位 MB）
num_logs = 12（保留 12 个轮转文件）
space_left = 75（剩余磁盘空间低于 75MB 时告警）
admin_space_left = 50（低于 50MB 时执行admin_action，如exec脚本清理）

提示：max_log_file和 logrotate 的size必须一致，否则 auditd 自身轮转和 logrotate 冲突，导致日志丢失。

4.2 规则效果验证：三招确认“它真的在工作”

写了规则，不代表它在生效。必须用真实操作触发并验证。我总结了三个必做验证步骤：

验证1：用ausearch查找最近 1 分钟的规则事件

# 查找最近 1 分钟内所有标记为 "exec" 的事件 ausearch -k exec -ts recent | head -5 # 查找最近 1 分钟内所有对 /etc/shadow 的读取 ausearch -k password_dump -ts recent

-ts recent是最实用的时间参数，比-ts 04/05/2024 10:00:00方便得多。若无输出，说明规则未命中，需检查-F条件是否过严。

验证2：用aureport生成统计报表，看事件量是否合理

# 生成按 key 分组的事件统计（过去 24 小时） aureport -k --summary -ts yesterday # 输出示例： # key count # --------------------------------- # exec 1245 # identity_files 3 # password_dump 0 # tmp_exec 2

如果exec计数为 0，说明-S execve规则失效；如果identity_files计数过高（如每小时数百），说明-w /etc -p wa太宽泛，需细化。

验证3：手动触发并抓包，双重确认

# 在一个干净终端，执行触发操作 echo "test" | sudo tee /tmp/audit_test.txt > /dev/null # 立即在另一个终端查 audit 记录 ausearch -m SYSCALL -ts recent -i | grep "tmp/audit_test" # 同时用 strace 看系统调用 strace -e trace=openat,write,close -p $(pgrep -f "tee /tmp/audit_test") 2>&1 | grep openat

ausearch输出应包含path="/tmp/audit_test.txt"和key="user_home_write"（如果规则匹配）。strace输出应显示openat(AT_FDCWD, "/tmp/audit_test.txt", O_WRONLY|O_CREAT|O_TRUNC, 0644)。两者一致，证明 audit 准确捕获了底层行为。

注意事项：ausearch默认只查/var/log/audit/audit.log，若 auditd 配置了远程 syslog，需加-f /var/log/audit/audit.log指定文件。-i参数是关键，它把数字 UID、syscall 编号等转换为可读名称（如uid=0→uid=root，syscall=257→syscall=openat）。

4.3 性能调优：如何让 audit 在千并发服务器上稳定运行

audit 最大的争议是“性能损耗”。实测表明，在合理配置下，audit 对 CPU 的额外占用通常 < 2%，但配置不当会导致内核缓冲区溢出、auditd 进程 CPU 100%、甚至系统卡顿。以下是经过压测验证的调优方案：

调优点1：缓冲区大小（backlog）
内核环形缓冲区默认 8192 条，高并发系统（如 API 网关）可能瞬间打满。溢出时，audit 会丢弃新事件或触发failure行为。调整方法：

# 临时调整（重启失效） auditctl -b 16384 # 永久调整：在 /etc/audit/rules.d/audit.rules 第一行加 -b 16384

计算公式：backlog = (峰值 QPS × 事件平均数/请求) × 5 秒。例如，QPS=1000，每个请求触发 3 条 audit 事件，则backlog = 1000×3×5 = 15000，向上取整为 16384。

调优点2：减少冗余事件
-a exit,always -S execve会记录所有程序执行，包括/usr/lib/systemd/systemd-journald、/usr/bin/dbus-daemon等系统进程，产生海量噪音。优化为：

# 只记录非 systemd、非 dbus 的 execve -a exit,always -F arch=b64 -S execve -F auid!=4294967295 -F comm!=systemd-journald -F comm!=dbus-daemon -k exec

-F comm!=xxx是轻量级过滤，比-F path!=/usr/lib/systemd/systemd-journald更高效，因为comm是进程名字符串比较，path需要解析全路径。

调优点3：禁用不必要的消息类型
audit 默认记录CONFIG_CHANGE（规则变更）、ANOM_ABEND（进程异常退出）等消息，对安全审计价值低，却占日志量 30%+。在/etc/audit/rules.d/audit.rules中加入：

# 排除 CONFIG_CHANGE 和 ANOM_ABEND -a exclude,always -F msgtype=CONFIG_CHANGE -a exclude,always -F msgtype=ANOM_ABEND

实测数据：某 32 核 128G 的 Kafka Broker 服务器，开启全量execve规则后，auditd CPU 从 1% 升至 8%；加入comm!=过滤后降至 3%；再加入exclude规则后稳定在 1.5%。磁盘 IO 降低 40%。

5. audit 日志分析实战：从原始记录到可行动情报

5.1 audit 日志结构深度解析：读懂每一行的含义

audit 日志不是纯文本，而是结构化的 key=value 对。理解其字段，是分析的基础。以下是一条典型的execve事件（已用ausearch -i格式化）：

type=SYSCALL msg=audit(04/05/2024 10:23:45.123:456789): arch=x86_64 syscall=execve success=yes exit=0 a0=7fffe8765432 a1=7fffe8765440 a2=7fffe8765450 a3=0 items=2 ppid=1234 pid=5678 auid=1001 uid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="bash" exe="/usr/bin/bash" key="exec" cwd="/home/admin" type=CWD msg=audit(04/05/2024 10:23:45.123:456789): cwd="/home/admin" type=PATH msg=audit(04/05/2024 10:23:45.123:456789): item=0 name="/usr/bin/ls" inode=123456 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 type=PATH msg=audit(04/05/2024 10:23:45.123:456789): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=789012 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0

关键字段解读：

msg=audit(04/05/2024 10:23:45.123:456789)：事件时间戳（年/月/日时:分:秒.毫秒:序列号），序列号全局唯一，可用于关联多条type=记录。
arch=x86_64：CPU 架构，b64是x86_64的内部代号。
syscall=execve：系统调用名称，execve表示执行新程序。
success=yes：系统调用是否成功，no表示被 SELinux 或 DAC 拒绝。
auid=1001：登录会话初始 UID，由login、sshd等设置，不可被子进程修改，是溯源“谁登录进来”的唯一可靠字段。
uid=0：当前进程 UID，