Docker 安全非事件

本页列出了 Docker 缓解的安全漏洞，因此在 Docker 容器中运行的进程永远不会受到该错误的影响——即使在修复之前也是如此。这假设容器在不添加额外功能的情况下运行，或者不作为--privileged.

下面的列表还远远不够完整。相反，它是我们实际注意到的少数几个已引起安全审查和公开披露的漏洞的示例。很可能，未报告的错误数量远远超过已报告的错误数量。幸运的是，由于 Docker 默认情况下通过 apparmor、seccomp 和 drop 功能来确保安全，因此它可能会像缓解已知错误一样缓解未知错误。

错误减少：

• CVE - 2013-1956、1957、1958、1959、1979 、 CVE - 2014-4014、5206、5207、7970、7975 、 CVE - 2015-2925、8543 、 CVE - 2016-3134、313 5等 ：介绍 ​ ​ ​​​ ​​ ​​非特权用户命名空间通过为非特权用户提供对以前仅限 root 的系统调用（如.所有这些 CVE 都是由于引入用户命名空间而导致的安全漏洞的示例。 Docker 可以使用用户命名空间来设置容器，但随后不允许容器内的进程通过默认的 seccomp 配置文件创建自己的嵌套命名空间，从而使这些漏洞无法利用。mount()
• CVE-2014-0181、 CVE-2015-3339：这些错误需要存在 setuid 二进制文件。 Docker 通过NO_NEW_PRIVS进程标志和其他机制禁用容器内的 setuid 二进制文件。
• CVE-2014-4699：其中的错误ptrace()可能允许权限升级。 Dockerptrace() 使用 apparmor、seccomp 和 drop 来禁用容器内部CAP_PTRACE。那里的保护层数是三倍！
• CVE-2014-9529：一系列精心设计的keyctl()调用可能会导致内核 DoS/内存损坏。 Dockerkeyctl()使用 seccomp 禁用容器内部。
• CVE-2015-3214、4036： 这些是常见虚拟化驱动程序中的错误，可能允许来宾操作系统用户在主机操作系统上执行代码。利用它们需要访问来宾中的虚拟化设备。 Docker 在没有--privileged.有趣的是，在这些情况下，容器似乎比虚拟机“更安全”，这与虚拟机比容器“更安全”的常识相悖。
• CVE-2016-0728：精心设计的调用导致的释放后使用keyctl()可能会导致权限提升。 Dockerkeyctl()使用默认的 seccomp 配置文件禁用容器内部。
• CVE-2016-2383：eBPF 中的一个错误（用于表达 seccomp 过滤器等内容的特殊内核 DSL）允许任意读取内核内存。bpf()使用（讽刺的是）seccomp 在 Docker 容器内阻止系统调用。
• CVE-2016-3134、4997、4998： setsockopt中的 错误，导致 内存损坏/本地权限提升。这些参数被 阻止，默认情况下 Docker 不允许这样做。IPT_SO_SET_REPLACEARPT_SO_SET_REPLACEARPT_SO_SET_REPLACECAP_NET_ADMIN

未缓解的错误：

• CVE-2015-3290、5157： 内核不可屏蔽中断处理中的错误允许权限升级。可以在 Docker 容器中利用，因为modify_ldt()当前未使用 seccomp 阻止系统调用。
• CVE-2016-5195：Linux 内核的内存子系统处理私有只读内存映射的写时复制 (COW) 损坏的方式中发现竞争条件，这允许非特权本地用户获得对只读内存的写入访问权限。只有记忆。也被称为“脏牛”。 部分缓解措施：在某些操作系统上，通过结合 seccomp 过滤和只读ptrace事实可以缓解此漏洞。/proc/self/mem