Docker安全性探讨与实践:探讨篇

Daniel Walsh是计算机安全领域的专家,有30余年的从业经验,非常熟悉容器技术。他2001年加入红帽公司,自2013年8月期任RHEL Docker增强开发团队主管。著名的SELinux项目就出自他手,该项目关注应用的运行空间和部署策略。Dan还组织开发了安全虚拟化软件sVirt,并创造了SELinux沙盒、Xguest用户以及Secure Kiosk。Dan在今年七月参加Docker大会的时候做了一个主题演讲,解释了SELinux的工作原理,Docker如何在SELinux下运行以及强制访问控制是如何增强Docker安全性的。之后,基于这次演讲的视频,他又在开源网站上发表了两篇文章,一篇讨论Docker的安全性,另一篇则着重介绍了RHEL如何对Docker的安全性进行了大量的增强。本文即是Dan这两篇文章的梳理与讨论。

一、 容器的隔离能力不是万能的,应对才是王道

相信很多开发者都默认Docker这样的容器是一种沙盒(sandbox)应用,也就是说他们可以用root权限在Docker中运行随便什么应用,而Docker有安全机制能保护宿主系统。比如,有些人觉得Docker容器里面的进程跟虚拟机里面的进程一样安全;还有的人随便找个源就下载没有验证过的Docker镜像,看都不看内容就在宿主机器上尝试、学习和研究;还有一些提供PaaS服务的公司竟然允许用户向多租户系统中提交自己定制的Docker镜像。请读者注意,上述行为均是不安全的。

难怪有人说:“Docker其实就是从网上不知什么地方下载一堆随机的代码,然后用root权限运行。”现在Docker镜像遇到的情景,跟1999年Linux兴起的时候类似:一个管理员觉得一个Linux命令挺酷,就随便从网上什么地方找到这个命令的rpm包,看都不看就安装运行。这显然是自取灭亡的典范。没过几天这个命令就爆出有bug,直接导致整个系统的瘫痪。

这种自取其辱的事情数不胜数,Dan的团队乃至整个红帽公司,就在致力减少类似事件发生的概率。比如一定要从可信源下载软件,定期进行安全更新,长期维护一个安全应急小组以及验证系统安全性的一整套规程。

二、 我们需要在乎容器的安全性么?出乎意料但是显然需要

Dan的团队近期不断提醒开发者,容器内外的权限基本没什么差别。如果开发者不是在多租户系统上运行Docker,并且对Docker里面运行的服务都采取了很好的安全措施,那他们可能的确不用担心Docker爆出什么安全性问题,因为他们把Docker镜像内部和宿主环境同等对待了,这两者之间的安全性确实没什么差别。

但是难免有挺多开发者从直觉出发,觉得Docker容器的安全性就高,这些人往往会把Docker容器机制当作一种更快速部署虚拟机的方法。这时候就需要提醒他们安全性的问题了。从安全角度来看,容器的安全性非常弱。正常来讲,Docker容器机制应该被当作一种服务来看待,就是说跑在Docker镜像上的Apache的安全措施,应该跟跑在自己服务器上的安全措施没什么区别才可以。比如,应该尽可能少的赋予软件各种权限,还应该总是用非root模式运行软件,以及万一在Docker内部用到了root权限,需要谨慎一如在宿主机上一样。

三、 是什么导致了安全漏洞?NameSpace

那么究竟是什么地方导致了Docker容器机制的安全问题呢?简单一句话,Linux系统中不是所有东西都有命名空间(Namespace)。最新版本的Docker有五个命名空间:进程、网络、挂载、宿主和共享内存。如此简单的命名空间显然无法给开发者提供复杂的安全保护。比如在类似KVM的环境里,虚拟机根本无法直接和宿主的内核交互,它没有任何方式可以访问内核文件系统中如/sys和/sys/fs这样的地方。在这种情况下,想要脱离虚拟机来攻击宿主,比如要找到HyperVisor的弱点,攻克SELinux控制(这是个挺难的事情),然后才能够染指宿主的文件系统。而在Docker这样的容器里,原生就可以访问宿主的内核,安全性从何而来?

Dan在文章中列举了主流的没有命名空间的内核,有:

  • SELinux
  • Cgroups
  • file systems under /sys
  • /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus

没有命名空间的设备有:

  • /dev/mem
  • /dev/sd* file system devices
  • Kernel Modules

如果开发者能访问或者攻击任何一个,就可以获得整个系统的控制权。

感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至[email protected]。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

你可能感兴趣的:(Docker安全性探讨与实践:探讨篇)