当我以普通用户身份运行容器时，我可以映射 和修改 主机文件系统上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
现在，我的 主机 文件系统将ls在df键入时执行命令（大多数情况下无害）。我不敢相信这是理想的行为，但是它正在我的系统中发生（debian延伸）。该docker命令具有普通权限（755，不是setuid）。
ls
df
docker
我想念什么？
可能需要澄清更多。目前，我对容器本身的作用或可以做的事情不感兴趣，也不关心容器内部的根访问权限。
而是我注意到，系统上可以运行docker容器的任何人都可以使用它来获得对我的 主机 系统的根访问权限，并以root用户身份对其进行读写操作：有效地为所有用户提供根访问权限。那显然不是我想要的。如何预防呢？
有许多Docker安全功能可用于解决Docker安全问题。可以帮助您的特定名称是User Namespaces。
基本上，您需要在预先停止Docker守护程序的情况下在主机上启用用户命名空间：
dockerd --userns-remap=default &
请注意，这将禁止容器在特权模式下运行（从安全角度考虑，这是一件好事），并重新启动Docker守护进程（应在执行此命令之前将其停止）。当您输入Docker容器时，可以将其限制为当前非特权用户：
docker run -it --rm -v /bin:/tmp/a --user UID:GID debian
无论如何，请稍后尝试使用默认命令输入Docker容器
docker run -it --rm -v /bin:/tmp/a debian
如果您尝试操纵映射到Docker卷的主机文件系统（在本例中为/bin），其中文件和目录由root拥有，那么您将收到一个Permission denied错误。这证明用户命名空间提供了您要寻找的安全功能。
/bin
Permission denied
我建议通过https://github.com/docker/labs/tree/master/security/userns上的此安全功能进行Docker实验。我已经完成了所有实验室的工作，并在那里开设了Issues和PR，以确保那里实验室的完整性并可以为其提供担保。
