linux权限依赖uid而非用户名，攻击者可通过伪造uid=0绕过校验；防范需从内核凭证验证、/etc/passwd只读保护、审计监控及容器用户命名空间隔离三方面协同加固。
Linux 系统不靠用户名识别权限，而是靠 UID（用户 ID）数字。攻击者若能伪造或劫持 UID，就可能绕过身份校验，获得非授权访问——这不是理论风险，而是真实存在的攻击路径。防范的关键，不是堵住某个命令，而是理解 UID 在内核、PAM、文件系统三层如何被验证和使用。
UID 是内核权限的唯一依据
内核在处理 kill、open、ptrace 等系统调用时，只检查进程凭证（cred）中的 euid（有效 UID）、uid（实际 UID）和 suid（保存 UID），不解析 /etc/passwd 中的用户名。只要 euid == 0，内核就授予 root 权限——无论这个 UID 来自合法 root 账户，还是被篡改的伪造条目。
- UID 0 不等于“root 用户”，而是“具备初始命名空间中全局 root 权限的凭证”
- 内核判断逻辑位于 security/commoncap.c：先查用户命名空间归属，再判 uid_eq(cred->euid, GLOBAL_ROOT_UID)
- 这意味着，在容器或用户命名空间隔离不严的环境中，UID 0 可能被跨命名空间误用
/etc/passwd 不是可信源头，只是映射表
/etc/passwd 文件本身可读，且不参与权限判定。它只在用户登录、ls -l 显示、getpwuid() 查询时起“翻译”作用。攻击者可通过直接编辑该文件，将普通账户 UID 改为 0，或添加隐藏账号（如用户名前加空格），让系统仍认其为 root 权限持有者。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 典型伪造操作：
[space]backdoor:$1$abc$xyz:0:0::/root:/bin/bash—— 名字不可见，但 UID/GID 均为 0 - 删除用户后未清理其旧文件，ls -l 显示数字 UID（如
1001），说明对应用户名已不存在，但权限残留 - 防范重点：定期比对
awk -F: '$3==0 {print}' /etc/passwd，确认仅存在一行 UID=0 的合法 root 条目
防止 UID 伪造的三道防线
单一机制无法阻断 UID 篡改，需叠加控制：
-
启动时只读挂载 /etc/passwd：在 /etc/fstab 中添加
ro,bind或使用 systemd 的ProtectSystem=full限制服务写入 -
启用审计日志监控 UID 变更：配置 auditd 规则
-w /etc/passwd -p wa -k passwd_change，配合 ausearch 实时告警 -
禁用交互式 root 登录 + 强制 sudo 日志：设置
PermitRootLogin no和Defaults logfile=/var/log/sudo.log，确保所有提权行为可追溯
别忽略用户命名空间与容器场景
在 Docker 或 Podman 环境中，若未启用 --userns-remap 或配置不当，宿主机 UID 0 可映射到容器内 UID 0，导致容器逃逸风险。此时伪造 UID 的代价更低，且传统 /etc/passwd 检查失效。
- 检查运行中容器是否以 root 运行：
ps -eo pid,user,args | grep 'docker\|podman' | awk '{print $2,$4}' - 强制非 root 用户运行容器：
--user 1001:1001，并设USER 1001在 Dockerfile 中 - 启用 user namespace 隔离：
echo 'user.max_user_namespaces=15000' > /etc/sysctl.d/99-userns.conf
