Docker安全性非事件 | Docker security non-events (Engine)
此页面列出了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
只读操作的组合进行缓解。
本文档系腾讯云开发者社区成员共同维护,如有问题请联系 cloudcommunity@tencent.com