此页面列出了Docker缓解的安全漏洞，这样在Docker容器中运行的进程就不会受到错误的攻击--甚至在修复之前也是如此。这假设容器在不添加额外功能的情况下运行，或者不以--privileged...

下面的列表甚至还没有远程完成。相反，它是我们实际上注意到的几个bug的样本，这些bug吸引了安全审查和公开披露的漏洞。很有可能，没有报告的bug数量远远超过了那些有报告的错误。幸运的是，由于Docker的方法默认情况下通过设备、seccomp和下降功能进行安全保护，因此它可能会像对已知错误一样减轻未知的错误。

bug减轻：

• CVE-2013至1956年，1957年，1958年，1959年，1979年，CVE-2014-4014，5206，5207，7970，7975，CVE-2015至2925年，8543，CVE-2016-3134，3135，等：引进非特权用户命名空间导致非特权用户可用的攻击面大幅度增加，因为这些用户可以合法访问以前只有根系统的调用，如mount()。所有这些CVE都是由于引入用户命名空间而导致的安全漏洞的示例。Docker可以使用用户命名空间来设置容器，但是不允许容器内的进程通过默认的seccomp配置文件创建它自己的嵌套命名空间，这使得这些漏洞无法被利用。

• CVE-2014-0181，CVE-2015-3339：这些是需要存在setuid二进制文件的错误。Docker通过NO_NEW_PRIVS进程标志和其他机制禁用容器内的setuid二进制文件。

• CVE-2014-4699*一个窃听器ptrace()可能允许权限提升。码头工人ptrace()在容器内使用仪器，Seccomp和通过下降CAP_PTRACE.三倍的保护层%21

• CVE-2014-9529：一系列手工制作keyctl()调用可能导致内核DoS/内存损坏。码头工人keyctl()容器内部使用Seccomp。

• CVE-2015-3214，4036：这些都是常见的虚拟化驱动程序中存在错误，可能允许来宾操作系统用户在主机操作系统上执行代码。利用它们需要访问guest虚拟机中的虚拟设备。运行时，Docker隐藏了对这些设备的直接访问--privileged。有趣的是，这些似乎是容器比虚拟机“更安全”的情况，违背了虚拟机比容器“更安全”的普遍看法。

• CVE-2016-0728：使用巧尽心思构建的免费后使用。keyctl()呼叫可能导致权限升级。码头工人keyctl()在容器中使用默认的Seccomp配置文件。

• CVE-2016-2383eBPF中的一个bug--这是一种特殊的内核内DSL，用于表示诸如seccomp过滤器之类的东西--允许任意读取内核内存。大bpf()具有讽刺意味的是，系统调用在Docker容器中使用%28%29 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）破坏方式中发现竞争情况，这种方式允许非特权本地用户获得对只读内存的写入访问权限，只有记忆。也称为“脏COW”。部分缓解措施：在某些操作系统上，此漏洞通过seccomp过滤ptrace和/proc/self/mem只读操作的组合进行缓解。