Namespace 通过限制进程可见的系统视图从源头压缩逃逸攻击面，但其本身不直接防范逃逸；逃逸成功与否取决于其完整性是否被绕过，常见削弱方式包括特权模式、共享宿主机 Namespace、危险 Capabilities 授权及挂载传播配置不当。
Namespace 是容器隔离的基石，它本身不直接“防范”逃逸，而是通过严格限制进程可见的系统视图，从源头压缩逃逸可利用的攻击面。逃逸能否成功，很大程度上取决于 Namespace 的完整性是否被绕过。
Namespace 构建进程的“虚拟牢笼”
Linux Namespace 为每个容器进程提供独立的全局资源视图，包括 PID、mount、network、UTS、IPC、user 等。一个在容器内运行的进程，看到的是自己 Namespace 内的 PID 1、自己的网络接口、自己的挂载点——它默认看不到宿主机的进程树、真实网卡或根文件系统。
这种隔离不是靠权限控制，而是靠内核在系统调用路径中动态裁剪返回结果。例如 getpid() 返回的是当前 PID Namespace 中的局部 PID，mount() 操作仅影响当前 mount Namespace 的视图。
逃逸常始于 Namespace 隔离的松动或滥用
真正导致逃逸的，往往是配置或使用方式削弱了 Namespace 的边界效力：
- 特权模式（--privileged）启动容器：自动加入所有 Namespace 并解除多数限制，等同于开放逃逸通道
- 共享宿主机 Namespace（如 --pid=host、--network=host）：进程直接看到宿主机 PID 树或网络栈，失去关键隔离层
- 危险的 Capabilities 授权（如 CAP_SYS_ADMIN）：允许进程执行 unshare() 或 setns() 系统调用，从而创建/加入其他 Namespace，实现跨域跳转
- 挂载传播（mount propagation）配置不当：例如在共享挂载（shared）下，容器内挂载可能意外影响宿主机或其他容器
强化 Namespace 防御的关键实践
防范逃逸不能只依赖 Namespace 默认行为，需主动加固其生效条件：
- 禁用特权容器：除非绝对必要，不使用 --privileged；改用精细化 Capabilities（如仅加 CAP_NET_BIND_SERVICE）
- 避免 host Namespace 共享：用 network 插件替代 --network=host；用 PID namespace 保持进程视图隔离
- 启用 user Namespace 映射（UserNS Remap）：让容器内 root（UID 0）映射到宿主机非 root 用户，即使逃逸进宿主机，也无权操作关键资源
- 限制 mount 操作能力：通过 seccomp 过滤 unshare、mount、pivot_root 等系统调用，或设置 read-only rootfs + tmpfs /dev
Namespace 不是银弹，必须协同其他机制
单独的 Namespace 无法阻止所有逃逸路径。例如，内核漏洞（如 Dirty COW、overlay2 race condition）可绕过 Namespace 检查；cgroup v1 的资源限制缺失可能助长横向移动；seccomp 和 AppArmor 能拦截危险系统调用，弥补 Namespace 的静态视图局限。
真正有效的防御，是把 Namespace 当作第一道“视觉屏障”，再叠加 capability 控制、syscall 过滤、用户 ID 映射和最小化镜像等多层约束，形成纵深防御结构。
