SELinux的Docker安全性

这篇文章基于我今年在DockerCon一个讲座,它将讨论我们当前听到的Docker容器的安全问题.

容器并不"包容"

我听到也读到很多假定Docker容器是应用沙盒的观点--这意味着他们能够在他们的系统上使用有根权限的Docker来执行随意的程序. 他们相信Docker容器将会保护他们的主机系统.

"你要来我的客厅吗", 蜘蛛对蝴蝶说道.

停止这样的设为Docker和Linux会保护你免于恶意软件的想法吧!

假设你不在一个多租户系统里执行Docker,而且你对执行在容器里的服务使用良好的安全策略,那你基本上不须要操心.只假定执行在容器里的特权进程就像在容器外的特权进程一样.

一些人错误的觉得容器是一种比虚拟机更好更快的方式,但从安全的角度来看,容器更脆弱,这点我将在文章的后面说明.

假设你相信我说的,Docker容器应该被视作"容器服务"-这意味着你要把执行Apache的容器看作在你的Host系统上执行的Apache服务,这就是说你要:

眼下我们正在通用规范中告诉人们把容器的特权进程当在容器外的特权进程.

不要在你的系统里执行随意的Docker镜像,我从很多方面看到Docker容器革命类似于1999年的Linux革命,那时当一个管理员听到一个新的非常酷的Linux服务时,他们会:

两周后管理员听到一个zlib的脆弱性问题并不得不指出( 他们希望并祈祷不是), 软件是不安全的!

这就是Red Hat发行版和其它一些值得信赖的第三方介入并解救他们的时刻, Red Hat的企业版Linux给管理员提供了:

仅仅执行从可信赖组织获得的容器,我相信你应该继续从同样的人那边获得代码/包,就像你曾经做的一样.假设代码不从那边来, 不要相信容器技术会保护你的主机.

最大的问题就是Linux的一切都不是命名空间 (namespaced). 如今, Docker使用5个命名空间来改变系统的进程: 进程, 网络, Mount, 主机名,共享内存.

尽管有给用户一定的安全级别, 但无法像KVM实施全面的安全保护. 在KVM环境下进程不直接和主机的内核交互.它们也不訪问内核的文件系统如/sys和/sys/fs, /proc/*

设备结点是用于和VMs 内核交互的,而不是主机.因此, 想要越过VM来扩展特权级别, 进程要去攻击VM内核,找到HyperVisor的弱点,打破SELinux的控制(sVirt),终于攻击主机的内核.

当你执行在一个容器里时,你就已经直接能够和主机的内核打交道了.

没有被当成命名空间的基本的内核子系统如:

没有被当成命名空间的设备:

假设通过一个特权进程对以上的某个模块通信或攻击的话,你就拥有了整个系统.