近日，一篇在Docker博客上发表的文章显示，Docker的容器已经被突破，并且能够遍历宿主机的文件了。由于Docker的轻量，快速等等优 点，让Docker在PaaS领域愈发火热，自然也就吸引了安全人员对其进行研究。这篇文章无疑将Docker推进了一个新纪元：放开应用，想想安全。 不要给用户root权限 该文章的作者强调：只有在容器内以 root 权限运行不受信任的应用程序，才有可能触发这个漏洞。而这是我们不推荐的运行 Docker Engine 的方式。 这句话可以分两个层次来解读，首先就是root权限的使用，其次是何为不受信任的应用程序。 Docker并不是虚拟机，Docker本来的用法也不是虚拟机。举个简单的例子，普通的虚拟机租户root和宿主root是分开的，而 Docker的租户root和宿主root是同一个root。一旦容器内的用户从普通用户权限提升为root权限，他就直接具备了宿主机的root权限， 进而进行几乎无限制的操作。这是为什么呢?因为Docker原本的用法是将进程之间进行隔离，为进程或进程组创建隔离开的运行空间，目的就是为了隔离有问 题的应用，而进程之间的限制就是通过namespace和cgroup来进行隔离与配额限制。每一个隔离出来的进程组，对外就表现为一个 container（容器）。在宿主机上可以看到全部的进程，每个容器内的进程实际上对宿主机来说是一个进程树。也就是说，Docker是让用户以为他们 占据了全部的资源，从而给用户一个“虚拟机”的感觉。 第二，何为不受信任的应用程序?来源不明的应用程序，或者二进制代码等等，以及有漏洞的应用程序， 都可以称为不受信任的应用程序。举个例子，在Docker容器中只运行基础的Apache 服务器和 MySQL 数据库，可能大家认为这样的环境用root也没问题，但是如果Apache或者MySQL有不为人所知的漏洞被利用，那么这两个应用也就成为了不受信任的 应用。因此在以root运行应用程序，或是在考虑安全环境的时候，需要以一切皆不可信的态度来对Docker环境进行安全加固。 Docker安全要依靠辅助机制 该作者还强调，如果坚持要root权限使用 Docker Engine ，系统的安全性可能会受到一系列众所周知的内核安全漏洞的影响。因此特别建议：
在上述三条建议之上，还应该有一种机制，就是保障机制。要不停的轮序去检测，要能够发现可疑的行为，并且对任何可疑的行为进行反应。比如进程A并未 给root权限，但是后来通过检测机制发现它变成了root权限，我们就可以怀疑它是进行了非法提权的操作。也就是说，我们允许你逃逸，但是我们也能够在 最短的时间内发现你的逃逸行为，并且制止你。 此外，Docker在安全方面还存在亟待加固的点：login过程使用明文传输用户名和密码，Image分发认证、Docker对Host的逃逸 （已公布的那个漏洞）、Docker内给租户的root账号能否提供、Docker的配额限制（磁盘、网络）、Docker内万一提权后的限制 （SELinux/AppArmor/GRSecurity）、出入Docker流量的监控和审计、AUFS存在的攻击点。 由于Docker需要把若干个container组一个虚拟的私有内网，解决租户之间的网络隔离。目前缺乏完整方案。从网络性能来分析，现状一般通 过Docker Bridge或OVS实现NAT、用IPtable做隔离，性能堪忧，需要测试和验证。也有同仁表示性能衰减在50%以上。因此性能衰减严重也就可能成为 一个新的攻击平面。在网络方面的攻击点存在container之间的嗅探、 ARP攻击，IPtable的漏洞利用、对IPtable饱和攻击等等。 当然，绝大多数的Docker安全问题都是建立在被用在公有云环境下的，如果Docker被使用在私有云环境中，那么它所带来的好处要远远多于他带来的问题。 |
