直接用setuid做进程隔离不安全，因其仅改有效UID而不隔离内核资源视图，无法防止/proc遍历、fd访问、mount泄露、group恢复、资源耗尽等问题；必须配合unshare创建user等命名空间并正确排序，且需补足cgroup、seccomp、capability三方面限制。

为什么直接用 setuid 做进程隔离不安全

因为 setuid 只改变有效用户 ID，不隔离内核视角下的资源视图。一旦进程被利用（比如通过 ptrace 或内存泄漏），攻击者仍能遍历 /proc、访问同主机其他进程的文件描述符、甚至挂载新文件系统——它根本没切断命名空间关联。

常见错误现象：sudo -u nobody /usr/bin/python3 -c "import os; print(os.listdir('/proc'))" 依然能看到所有进程 PID 目录；ls /proc/1/fd 在未隔离时可能成功读取 init 进程的打开文件。

• 仅靠 setuid + chroot 无法防止 mount namespace 泄露（例如攻击者执行 mount --bind /etc /tmp/etc 后逃逸）
• glibc 的 initgroups() 调用可能意外恢复 supplementary groups，导致权限扩大
• 没有 cgroup 限制时，恶意进程可耗尽内存或 fork 炸弹拖垮整机

unshare + chroot 组合的关键参数顺序

必须先用 unshare 创建新命名空间，再 chroot 切换根目录。反过来会失败：子进程在旧 mount namespace 中无法真正隐藏宿主文件系统。

典型安全组合命令：

unshare --user --pid --ipc --uts --net --mount --fork \
  --root=/var/chroot/myapp \
  --set-groups=deny \
  --map-root-user \
  /bin/sh -c 'chroot /var/chroot/myapp /bin/sh'

注意点：

• --map-root-user 是必须的，否则新 user namespace 中 UID 0 不映射到宿主任何 UID，导致 chroot 后连 ls 都因权限拒绝失败
• --set-groups=deny 阻止子进程调用 setgroups(2)，否则可能重新获得额外 group 权限
• --mount 必须配合 --fork，否则后续 chroot 会因共享 mount namespace 而暴露原根目录

为什么 clone() 的 CLONE_NEWUSER 必须第一个启用

Linux 内核强制要求：如果要创建 user namespace，它必须是第一个被启用的 namespace。否则 clone() 或 unshare() 会返回 EINVAL 错误。

错误示例（shell 中不可见，但 C 程序中常见）：

unshare --pid --user  # 失败：EINVAL

正确顺序：

unshare --user --pid --mount --net  # 成功

原因在于：user namespace 是权限降级的锚点，其他 namespace（如 pid、net）的隔离能力依赖于它提供的 UID 映射上下文。没有它，内核无法判断“这个新 PID 1 进程该以谁的身份运行”。

• 容器运行时（如 runc）内部一定按 CLONE_NEWUSER → CLONE_NEWPID → CLONE_NEWNET 顺序调用 clone()
• 即使只想要网络隔离，也得带上 --user 并做 UID 映射，否则非 root 用户无法安全启用 --net
• systemd-run 默认不启用 user namespace，所以 systemd-run --scope --property=Delegate=yes ... 不能替代 unshare

真实生产中绕不开的三个补丁点

纯 unshare 方案在生产环境几乎不可用，必须补足三处缺失能力：

• cgroup v2 接口绑定：用 mkdir /sys/fs/cgroup/myapp && echo $$ > /sys/fs/cgroup/myapp/cgroup.procs 限制 CPU/memory，否则进程仍可抢占全部资源
• seccomp-bpf 过滤：默认允许全部系统调用，需用 scmp_bpf_compile() 或 crun run --seccomp ... 屏蔽 ptrace、mount、keyctl 等高危调用
• capability drop：即使在 user namespace 中，进程默认仍有 CAP_SYS_ADMIN（若未显式丢弃），而该 cap 允许突破 mount/pid namespace 边界

最容易被忽略的是 capability 和 seccomp 的协同：只 drop capability 不过滤 syscalls，攻击者仍可通过 openat(AT_EMPTY_PATH) + ioctl(TIOCGDEV) 探测宿主设备；只上 seccomp 不 drop cap，则某些被允许的 syscall（如 clone(CLONE_NEWNS)）仍可新建嵌套 namespace。