在漏洞利用测试方面，Docker 和 LXC 技术本身仍处于非常早期的阶段。drawbenn 强调了以非 root 用户身份运行 Docker 容器的困难是正确的——为了启动 LXC 容器，本质上需要发生一些非常低级的事情。

不过，需要考虑的一些有趣的事情是您试图在容器中隔离的任何恶意软件的预期目标。

假设恶意软件试图利用本地软件中的一个漏洞来进行权限提升。它可能会在容器内实现这一点，但它也必须是专门编写的，以尝试突破 docker 容器来做一些恶意的事情。

所以问题是——编写这个不受信任的代码的人会知道你将在容器中运行它吗？如果他们这样做（或者如果他们怀疑你会这样做），那么直接利用 dockerised 环境的漏洞出现的可能性要高得多。

以非 root 用户身份在标准 Docker 容器中运行的应用程序本质上只是在主机上运行的非特权进程，并对其施加了额外的限制。

首先，应用程序将驻留在它自己的一组命名空间（例如 mount、net）中，限制它对主机资源的查看。

然后假设一个标准的 Docker 配置，在 debian 衍生产品上，将会有一个 AppArmor 配置文件应用于应用程序，限制一些访问。

此外（假设它不在 Kubernetes 下运行），seccomp 配置文件将应用于应用程序进程，限制其对特定系统调用的访问。

在突破机会方面，假设容器是非 root 并且没有使用--privileged来自底层主机的标志或挂载文件运行，攻击者的主机突破机会主要与攻击底层 Linux 内核有关。如果正在运行的内核中存在未修补的 privesc 问题，攻击者可能能够利用这些问题，尽管系统调用过滤器或 AppArmor 配置文件可能会阻止它们。