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 Binaries的漏洞。Docker 通过
NO_NEW_PRIVS进程标志和其他机制在容器内禁用 setuid Binaries。 - 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:
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”。
部分缓解措施：在某些操作系统上，通过
ptrace的seccomp过滤以及/proc/self/mem是只读的这一事实，可以缓解此漏洞。