Docker 安全非事件
本页列出了 Docker 缓解的安全漏洞，例如
在 Docker 容器中运行的进程从未容易受到该错误的影响 - 甚至在此之前
它被修复了。这假定容器在不添加额外功能的情况下运行
或不作为--privileged.
下面的列表甚至还不完整。相反，它是少数几个例子中的一个 我们实际上注意到的 bug 已经引起了安全审查并公开 披露的漏洞。很有可能，没有 报告的数量远远超过那些已经报告的人。幸运的是，由于 Docker 的 默认情况下，通过 AppArmor、secComp 和 Drop 功能进行安全保护，IT 可能缓解未知错误和缓解已知错误一样。
缓解的 Bug：
- 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 可以使用用户命名空间来设置容器，但随后不允许 进程，通过 default seccomp 配置文件，使这些漏洞无法利用。 - CVE-2014-0181、CVE-2015-3339 漏洞：
这些 bug 需要存在 setuid Binaries。Docker 禁用
setuid Binaries通过
NO_NEW_PRIVSprocess 标志和 其他机制。 - CVE-2014-4699 漏洞：
一个
ptrace()可能允许权限提升。Docker 禁用ptrace()在容器内使用 AppArmor、secComp 和丢弃CAP_PTRACE. 那里的保护层是三倍！ - CVE-2014-9529 漏洞：
一系列精心制作
keyctl()调用可能会导致内核 DoS/内存损坏。 Docker 禁用keyctl()在 Containers 中使用 secComp。 - CVE-2015-3214、4036：这些是
常见虚拟化驱动程序中的错误，可能允许来宾作系统用户
在主机作系统上执行代码。利用它们需要访问虚拟化
设备。Docker 在运行时隐藏对这些设备的直接访问
没有
--privileged.有趣的是，这些似乎是容器 比 VM “更安全”，这与 VM 的普遍看法背道而驰 比容器“更安全”。 - CVE-2016-0728 漏洞：
制作后释放导致
keyctl()调用可能会导致特权 升级。Docker 禁用keyctl()在容器内使用默认的 seccomp 配置文件。 - CVE-2016-2383 漏洞：
eBPF 中的一个 bug —— 用于表示 seccomp 等内容的特殊内核内 DSL
filters —— 允许任意读取内核内存。这
bpf()系统调用 在 Docker 容器中使用（具有讽刺意味的）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：Bug
内核的不可屏蔽中断处理允许权限提升。
可以在 Docker 容器中利用，因为
modify_ldt()system 调用是 当前未使用 seccomp 阻止。 - CVE-2016-5195 漏洞：
在 Linux 内核的内存子系统中发现争用条件
处理了私有只读内存映射的写入时复制 （COW） 中断，
这允许非特权本地用户获得对只读内存的写入访问权限。
也称为“dirty COW”。部分缓解措施：在某些作系统上，此漏洞已得到缓解
通过 seccomp 过滤的组合
ptrace以及/proc/self/mem是只读的。