Docker root访问主机系统

Sja*_*ens 17 docker

当我以普通用户身份运行容器时,我可以在主机文件系统上映射和修改 root拥有的目录.这似乎是一个很大的安全漏洞.例如,我可以执行以下操作:

$ docker run -it --rm -v /bin:/tmp/a debian
root@14da9657acc7:/# cd /tmp/a
root@f2547c755c14:/tmp/a# mv df df.orig
root@f2547c755c14:/tmp/a# cp ls df
root@f2547c755c14:/tmp/a# exit
Run Code Online (Sandbox Code Playgroud)

现在我的主机文件系统将ls在df键入时执行命令(主要是无害的示例).我无法相信这是理想的行为,但它发生在我的系统中(debian stretch).该docker命令具有正常权限(755,不是setuid).

我错过了什么?

也许澄清一点是好的.我目前不是对容器本身做什么或能做什么感兴趣,也不关心容器内的root访问权限.

相反,我注意到我的系统上任何可以运行docker容器的人都可以使用它来获得对我的主机系统的root访问权限,并以root身份读取/写入他们想要的内容:有效地为所有用户提供root访问权限.这显然不是我想要的.怎么预防这个?

Mat*_*ard 12

有许多Docker安全功能可用于帮助解决Docker安全问题.可以帮助您的具体方法是用户名空间.

基本上,您需要在主机上启用用户命名空间,并预先停止Docker守护程序:

dockerd --userns-remap=default &
Run Code Online (Sandbox Code Playgroud)

请注意,这将禁止容器以特权模式运行(从安全角度来看是件好事)并重新启动Docker守护程序(应在执行此命令之前将其停止).进入Docker容器时,可以将其限制为当前的非特权用户:

docker run -it --rm -v /bin:/tmp/a --user UID:GID debian
Run Code Online (Sandbox Code Playgroud)

无论如何,尝试使用默认命令后输入Docker容器

docker run -it --rm -v /bin:/tmp/a debian
Run Code Online (Sandbox Code Playgroud)

如果您尝试操作映射到Docker卷(在本例中/bin)的文件和目录由root拥有的主机文件系统,那么您将收到Permission denied错误.这证明了用户名空间提供了您正在寻找的安全功能.

我建议通过https://github.com/docker/labs/tree/master/security/userns访问此安全功能的Docker实验室.我已经完成了所有的实验室,并在那里开设了问题和PR,以确保实验室的完整性,并可以为它们担保.

  • 但是,在我的主机系统上,作为普通用户,我可以运行(例如)标准的debian映像,并且可以给我root访问主机的权限。实验室说:“但是,它也存在潜在的安全风险。” 这相当轻描淡写。它不应该说:永远不要以这种方式运行docker,因为它为所有用户提供了对主机系统的根访问权限。 (3认同)
  • 谢谢。现在很明显,我不应该允许任何普通用户运行docker,而应该为他们这样做。实验室指针也很有用。 (2认同)

BMi*_*tch 6

访问在主机上运行docker命令的权限就是访问该主机上的root用户。这是该工具的设计,因为挂载文件系统和隔离应用程序的功能需要在Linux上具有根功能。此处的安全漏洞是任何授予用户访问权限的系统管理员,用户可以运行他们不信任该主机上的root访问权限的docker命令。因此,应谨慎地将用户添加到docker组。

我仍然认为正确使用Docker可以提高安全性,因为在容器内运行的应用程序只能对主机执行限制。导致损坏的能力由运行容器的显式选项提供,例如将根文件系统作为rw挂载,直接访问设备或向root添加允许转义名称空间的功能。除非明确创建这些安全漏洞,否则在容器内运行的应用程序的访问权限要比在容器外运行的应用程序少。

如果您仍想尝试锁定有权访问docker的用户,则还有一些其他安全功能。用户命名空间是一种阻止容器内部的root用户访问主机的root用户空间。还有一个互锁,可以限制每个用户可用的命令。

  • 这显然是我对这个概念的误解。谢谢。 (2认同)