Docker 安全非事件
本页列出了 Docker 已缓解的安全漏洞，因此即使在漏洞修复之前，在 Docker 容器中运行的进程也从未受该漏洞的影响。前提是容器在运行时没有添加额外的功能，或者没有以 --privileged 模式运行。
下面的列表远非完整。相反，它只是我们实际注意到已引起安全审查并公开披露漏洞的少数几个错误的样本。很可能，未报告的错误远多于已报告的错误。幸运的是，由于 Docker 通过 apparmor、seccomp 和放弃功能来实现默认安全的方法，它很可能像缓解已知错误一样有效地缓解未知错误。
已缓解的漏洞
- CVE-2013-1956, 1957, 1958, 1959, 1979, CVE-2014-4014, 5206, 5207, 7970, 7975, CVE-2015-2925, 8543, CVE-2016-3134, 3135 等：引入非特权用户命名空间导致非特权用户的攻击面大幅增加，因为这些用户可以合法地访问以前只有 root 用户才能访问的系统调用，例如
mount()。所有这些 CVE 都是由于引入用户命名空间而导致的安全漏洞的例子。Docker 可以使用用户命名空间来设置容器，但随后通过默认的 seccomp 配置文件禁止容器内的进程创建自己的嵌套命名空间，从而使这些漏洞无法被利用。 - CVE-2014-0181, CVE-2015-3339：这些是需要存在 setuid 二进制文件的漏洞。Docker 通过
NO_NEW_PRIVS进程标志和其他机制禁用了容器内的 setuid 二进制文件。 - CVE-2014-4699：
ptrace()中的一个漏洞可能允许权限提升。Docker 使用 apparmor、seccomp 和放弃CAP_PTRACE的方式在容器内禁用ptrace()。这里有三层保护！ - CVE-2014-9529：一系列精心构造的
keyctl()调用可能导致内核 DoS / 内存损坏。Docker 使用 seccomp 在容器内禁用keyctl()。 - CVE-2015-3214, 4036：这些是常见虚拟化驱动程序中的漏洞，可能允许客户机操作系统用户在主机操作系统上执行代码。利用它们需要访问客户机中的虚拟化设备。在没有
--privileged的情况下运行时，Docker 隐藏了对这些设备的直接访问。有趣的是，这些情况似乎表明容器比虚拟机“更安全”，这与虚拟机比容器“更安全”的普遍看法相悖。 - CVE-2016-0728：由精心构造的
keyctl()调用引起的释放后使用（use-after-free）可能导致权限提升。Docker 使用默认的 seccomp 配置文件在容器内禁用keyctl()。 - CVE-2016-2383：eBPF（用于表示 seccomp 过滤器等内容的特殊内核 DSL）中的一个漏洞允许任意读取内核内存。在 Docker 容器内部，
bpf()系统调用被（讽刺地）使用 seccomp 阻止了。 - CVE-2016-3134, 4997, 4998：setsockopt 与
IPT_SO_SET_REPLACE、ARPT_SO_SET_REPLACE和ARPT_SO_SET_REPLACE存在漏洞，导致内存损坏/本地权限提升。这些参数被CAP_NET_ADMIN阻止，而 Docker 默认不允许此功能。
未缓解的漏洞
- CVE-2015-3290, 5157：内核的非屏蔽中断处理中的漏洞允许权限提升。可以在 Docker 容器中利用，因为
modify_ldt()系统调用目前没有被 seccomp 阻止。 - CVE-2016-5195：在 Linux 内核内存子系统处理私有只读内存映射的写时复制（COW）中断时发现了一个竞争条件，该条件允许非特权本地用户获得对只读内存的写访问权限。也称为“脏牛”（dirty COW）。部分缓解措施：在某些操作系统上，通过 seccomp 过滤
ptrace以及/proc/self/mem是只读的这一事实组合，可以缓解此漏洞。