Docker 安全非事件

本页面列出了Docker已缓解的安全漏洞，使得在Docker容器中运行的进程从未受到该漏洞的影响——即使在漏洞修复之前也是如此。这假设容器在运行时没有添加额外的能力或未以--privileged模式运行。

下面的列表远非完整。相反，它是我们实际注意到的一些吸引了安全审查并公开披露的漏洞的样本。很可能，未被报告的漏洞数量远远超过已被报告的。幸运的是，由于Docker通过apparmor、seccomp和降低权限的默认安全方法，它可能同样有效地缓解未知漏洞，就像它对已知漏洞所做的那样。

已缓解的错误：

• CVE-2013-1956, 1957, 1958, 1959, 1979, CVE-2014-4014, 5206, 5207, 7970
• 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: 这些是 常见的虚拟化驱动程序中的漏洞，可能允许客户操作系统用户在主机操作系统上执行代码。利用这些漏洞需要访问客户中的虚拟化设备。Docker 在没有 --privileged 的情况下运行时隐藏了对这些设备的直接访问。有趣的是，这些似乎是容器比虚拟机“更安全”的情况，这与通常认为虚拟机比容器“更安全”的常识相反。
• CVE-2016-0728: 由于精心设计的keyctl()调用导致的释放后使用问题可能导致权限提升。Docker使用默认的seccomp配置文件在容器内禁用了keyctl()。
• CVE-2016-2383: eBPF中的一个漏洞——用于表达诸如seccomp过滤器之类的特殊内核DSL——允许任意读取内核内存。使用（讽刺的是）seccomp在Docker容器内阻止了bpf()系统调用。
• CVE-2016-3134, 4997, 4998: IPT_SO_SET_REPLACE, ARPT_SO_SET_REPLACE, 和 ARPT_SO_SET_REPLACE 中的一个错误导致内存损坏 / 本地权限提升。 这些参数被 CAP_NET_ADMIN 阻止，Docker 默认不允许。

未缓解的错误：

• CVE-2015-3290, 5157: 内核中的不可屏蔽中断处理漏洞允许权限提升。 由于modify_ldt()系统调用目前未使用seccomp进行阻止，因此可以在Docker容器中被利用。
• CVE-2016-5195: 在Linux内核的内存子系统中处理私有只读内存映射的写时复制（COW）破坏时发现了一个竞争条件，这允许无特权的本地用户获得对只读内存的写访问权限。也被称为“脏COW”。 部分缓解措施：在某些操作系统上，通过结合ptrace的seccomp过滤和/proc/self/mem是只读的事实，这个漏洞得到了缓解。