Posts

容器并非沙箱：为什么 Docker 组权限即是 Root？

在多用户 Linux 环境中，常听到一种说法：将开发者加入 docker 组只是为了方便运行容器，不必输入 sudo。然而，从安全审计的角度来看，将用户加入 docker 组本质上等同于赋予其宿主机的 Root 权限。

为什么 Docker 组 = Root？

Docker 守护进程（dockerd）默认以 root 用户身份运行。由于 docker.sock 套接字文件通常被设置为 root:docker 用户组权限（660），任何属于该组的用户都可以直接通过该套接字与 daemon 通信。

这不仅仅是“方便”的问题。一旦拥有了 docker.sock 的读写权限，你就可以操纵守护进程执行以下操作来实现“容器逃逸”：

  1. 挂载宿主机根目录：你可以启动一个挂载了宿主机 / 的容器，在容器内执行 chroot。此时，宿主机的完整文件系统就在你的掌握之中。
    docker run -v /:/host -it alpine chroot /host
  2. 启动特权容器：通过 --privileged 参数，容器可以直接访问宿主机的硬件设备（如 /dev/sda），轻易地绕过 Namespace 隔离。

容器不是天然的安全边界

容器技术的本质是 Linux 内核特性的“协同工作”：Namespace 负责隔离进程视图，Cgroup 负责限制资源消耗。但它们并非严密的安防屏障：

  • 共享内核：所有容器与宿主机共享同一个内核。一旦发生提权逃逸，攻击者可以直接与内核交互，完全无视 Namespace 的限制。
  • Daemon 权限滥用：Docker 的设计哲学是将 daemon 作为系统的“全权委托者”。能够指示 daemon 工作，也就意味着获得了系统的最高控制权。

总结与防御

为了防止因 Docker 权限配置不当引发的系统级风险，建议采取以下防范措施：

  1. 最小权限原则：严格审计 docker 组，移除不必要的用户。
  2. Rootless Docker：在支持的发行版上使用无根模式，这样即使 daemon 被劫持，它也仅拥有当前用户的权限，无法直接侵害系统核心。
  3. 拥抱 daemon-less：如使用 Podman，它默认无需守护进程，从架构上彻底消除了 docker.sock 带来的 root 等效问题。

作为开发者，我们不仅要利用好工具的便利性，更要看透其背后的权限契约。在 AI 环境部署和 presales 工具链的设计中，始终将“权限最小化”作为第一原则。

read more