虚拟化容器Docker的安全性讨论

formatuu

　　一．Docker所采用的安全机制分析
评估 Docker 的安全性时，主要考虑三个方面:
由内核的名字空间和控制组机制提供的容器内在安全
Docker程序（特别是服务端）本身的抗***性
内核安全性的加强机制对容器安全性的影响
1.内核名字空间
Docker 容器和 LXC 容器很相似，所提供的安全特性也差不多。当用 docker run 启动一个容器时，在后台 Docker 为容器创建了一个独立的名字空间和控制组集合。
名字空间提供了最基础也是最直接的隔离，在容器中运行的进程不会被运行在主机上的进程和其它容器发现和作用。
每个容器都有自己独有的网络栈，意味着它们不能访问其他容器的 sockets 或接口。不过，如果主机系统上做了相应的设置，容器可以像跟主机交互一样的和其他容器交互。当指定公共端口或使用 links 来连接 2 个容器时，容器就可以相互通信了（可以根据配置来限制通信的策略）。
从网络架构的角度来看，所有的容器通过本地主机的网桥接口相互通信，就像物理机器通过物理交换机通信一样。
那么，内核中实现名字空间和私有网络的代码是否足够成熟？
内核名字空间从 2.6.15 版本（2008 年 7 月发布）之后被引入，数年间，这些机制的可靠性在诸多大型生产系统中被实践验证。
实际上，名字空间的想法和设计提出的时间要更早，最初是为了在内核中引入一种机制来实现 OpenVZ 的特性。而 OpenVZ 项目早在 2005 年就发布了，其设计和实现都已经十分成熟。
普通虚拟机将整个操作系统运行在虚拟的硬件平台上, 进而提供完整的运行环境供应用程序运行, 而Docker则直接在宿主平台上加载运行应用程序.本质上他在底层使用LXC启动一个Linux Container,通过cgroup等机制对不同的container内运行的应用程序进行隔离,权限管理和quota分配等。每个container拥有自己独立的各种命名空间(亦即资源)包括: PID 进程, MNT 文件系统, NET 网络, IPC , UTS 主机名等
2.控制组
控制组是 Linux 容器机制的另外一个关键组件，负责实现资源的审计和限制。
它提供了很多有用的特性；以及确保各个容器可以公平地分享主机的内存、CPU、磁盘 IO 等资源；当然，更重要的是，控制组确保了当容器内的资源使用产生压力时不会连累主机系统。
尽管控制组不负责隔离容器之间相互访问、处理数据和进程，它在防止拒绝服务（DDOS）***方面是必不可少的。尤其是在多用户的平台（比如公有或私有的 PaaS）上，控制组十分重要。例如，当某些应用程序表现异常的时候，可以保证一致地正常运行和性能。
控制组机制始于 2006 年，内核从 2.6.24 版本开始被引入。
3.Docker服务端的防护
运行一个容器或应用程序的核心是通过 Docker 服务端。Docker 服务的运行目前需要 root 权限，因此其安全性十分关键。
首先，确保只有可信的用户才可以访问 Docker 服务。Docker 允许用户在主机和容器间共享文件夹，同时不需要限制容器的访问权限，这就容易让容器突破资源限制。例如，恶意用户启动容器的时候将主机的根目录/映射到容器的 /host 目录中，那么容器理论上就可以对主机的文件系统进行任意修改了。这听起来很疯狂？但是事实上几乎所有虚拟化系统都允许类似的资源共享，而没法禁止用户共享主机根文件系统到虚拟机系统。
这将会造成很严重的安全后果。因此，当提供容器创建服务时（例如通过一个 web 服务器），要更加注意进行参数的安全检查，防止恶意的用户用特定参数来创建一些破坏性的容器
为了加强对服务端的保护，Docker 的 REST API（客户端用来跟服务端通信）在 0.5.2 之后使用本地的 Unix 套接字机制替代了原先绑定在 127.0.0.1 上的 TCP 套接字，因为后者容易遭受跨站脚本***。现在用户使用 Unix 权限检查来加强套接字的访问安全。
用户仍可以利用 HTTP 提供 REST API 访问。建议使用安全机制，确保只有可信的网络或 ***，或证书保护机制（例如受保护的 stunnel 和 ssl 认证）下的访问可以进行。此外，还可以使用 HTTPS 和证书来加强保护。
最近改进的 Linux 名字空间机制将可以实现使用非 root 用户来运行全功能的容器。这将从根本上解决了容器和主机之间共享文件系统而引起的安全问题。
终极目标是改进 2 个重要的安全特性：
将容器的 root 用户映射到本地主机上的非 root 用户，减轻容器和主机之间因权限提升而引起的安全问题；
允许 Docker 服务端在非 root 权限下运行，利用安全可靠的子进程来代理执行需要特权权限的操作。这些子进程将只允许在限定范围内进行操作，例如仅仅负责虚拟网络设定或文件系统管理、配置操作等。
最后，建议采用专用的服务器来运行 Docker 和相关的管理服务（例如管理服务比如 ssh 监控和进程监控、管理工具 nrpe、collectd 等）。其它的业务服务都放到容器中去运行。
4.内核能力机制
能力机制（Capability）是 Linux 内核一个强大的特性，可以提供细粒度的权限访问控制。 Linux 内核自 2.2 版本起就支持能力机制，它将权限划分为更加细粒度的操作能力，既可以作用在进程上，也可以作用在文件上。
例如，一个 Web 服务进程只需要绑定一个低于 1024 的端口的权限，并不需要 root 权限。那么它只需要被授权 net_bind_service 能力即可。此外，还有很多其他的类似能力来避免进程获取 root 权限。
默认情况下，Docker 启动的容器被严格限制只允许使用内核的一部分能力。
使用能力机制对加强 Docker 容器的安全有很多好处。通常，在服务器上会运行一堆需要特权权限的进程，包括有 ssh、cron、syslogd、硬件管理工具模块（例如负载模块）、网络配置工具等等。容器跟这些进程是不同的，因为几乎所有的特权进程都由容器以外的支持系统来进行管理。
ssh 访问被主机上ssh服务来管理；
cron 通常应该作为用户进程执行，权限交给使用它服务的应用来处理；
日志系统可由 Docker 或第三方服务管理；
硬件管理无关紧要，容器中也就无需执行 udevd 以及类似服务；
网络管理也都在主机上设置，除非特殊需求，容器不需要对网络进行配置。
从上面的例子可以看出，大部分情况下，容器并不需要“真正的” root 权限，容器只需要少数的能力即可。为了加强安全，容器可以禁用一些没必要的权限。
完全禁止任何 mount 操作；
禁止直接访问本地主机的套接字；
禁止访问一些文件系统的操作，比如创建新的设备、修改文件属性等；
禁止模块加载。
这样，就算***者在容器中取得了 root 权限，也不能获得本地主机的较高权限，能进行的破坏也有限。
默认情况下，Docker采用 白名单 机制，禁用 必需功能 之外的其它权限。当然，用户也可以根据自身需求来为 Docker 容器启用额外的权限。
5.其它安全特性
除了能力机制之外，还可以利用一些现有的安全机制来增强使用 Docker 的安全性，例如 TOMOYO, AppArmor, SELinux, GRSEC 等。
Docker 当前默认只启用了能力机制。用户可以采用多种方案来加强 Docker 主机的安全，例如：
在内核中启用 GRSEC 和 PAX，这将增加很多编译和运行时的安全检查；通过地址随机化避免恶意探测等。并且，启用该特性不需要 Docker 进行任何配置。
使用一些有增强安全特性的容器模板，比如带 AppArmor 的模板和 Redhat 带 SELinux 策略的模板。这些模板提供了额外的安全特性。
用户可以自定义访问控制机制来定制安全策略。
跟其它添加到 Docker 容器的第三方工具一样（比如网络拓扑和文件系统共享），有很多类似的机制，在不改变 Docker 内核情况下就可以加固现有的容器。
6.总结
总体来看，Docker 容器还是十分安全的，特别是在容器内不使用 root 权限来运行进程的话。
另外，用户可以使用现有工具，比如 Apparmor, SELinux, GRSEC 来增强安全性；甚至自己在内核中实现更复杂的安全机制。
二．Docker的安全隐患
1.能否彻底隔离
在超复杂的业务系统中，单OS到底能不能实现彻底隔离，一个程序的崩溃/内存溢出/高CPU占用到底会不会影响到其他容器或者整个系统?很多人对Docker能否在实际的多主机的生产环境中支持关键任务系统还有所怀疑。 注* 就像有人质疑Node.JS单线程快而不稳，无法在复杂场景中应用一样。
不过可喜的是，目前Linux内核已经针对Container做了很多改进，以支持更好的隔离。
2.GO语言还没有完全成熟
Docker由Go语言开发，但GO语言对大多数开发者来说比较陌生，而且还在不断改进，距离成熟还有一段时间。此半git、半包管理的方式让一些人产生不适。
3.被私有公司控制
Docker是一家叫Dotcloud的私有公司设计的，公司都是以营利为目的，比如你没有办法使用源代码编绎Docker项目，只能使用黑匣子编出的Docker二进制发行包，未来可能不是完全免费的。 目前Docker已经推出面向公司的企业级服务(咨询、支持和培训)。
4.Docker镜像系统安全性讨论
“本文作者深入研究了Docker镜像的下载流程，并逐步分析了Docker镜像下载过程中可能出现的安全问题。关注Docker安全以及做Docker镜像存储的同学必看。另外，作者还总结了应该采取哪些措施来改善Docker镜像的安全性。”
最近在使用Docker下载一个“官方”容器镜像时我看到这么一行提示：
ubuntu:14.04: The image you are pulling has been verified
我当时以为这和Docker极力推荐的镜像签名系统有关，所以并未深究。后来，在研究Docker镜像安全相关的加密系统时，我开始进一步探索Docker的镜像安全。而我发现所有与镜像安全相关的逻辑完全是系统性的错误。
按照Docker的说法，下载的镜像完全是基于签名的manifest的存在而做出的，并且Docker并没有从manifest中校验镜像的校验和（checksum）。***者可以伪造提供一个具有签名证明的镜像，这个问题很容易被***者利用。
镜像从HTTPS服务器上下载下来，然后通过Docker daemon的一个不安全的流处理管道：
[解压缩] -> [tarsum] -> [解包]
这个管道很高效，但毫无安全可言。在未验证签名之前，管道不应该处理不受信任的输入。然而，在验证检验和之前，Docker进行了三次镜像的处理。
尽管Docker做了声明，但它从未实际检查过镜像校验。下面是Docker中唯一一处与验证镜像校验和有关的代码，但是即便在镜像中提供不匹配的校验和，我也无法触发这个警告。
if img.Checksum != "" && img.Checksum != checksum {  log.Warnf("image layer checksum mismatch: computed %q,  expected %q", checksum, img.Checksum)  } 不安全的处理管道
解压缩
Docker支持三种压缩算法：gzip、bzip2和xz。前两者使用Go的标准库实现，这是内存安全的，所以我能想到的漏洞类型是拒绝服务***，如宕机、CPU和内存过度使用。
第三个压缩算法xz更有趣。因为没有原生的Go实现，Docker运行xz程序来解压缩。
xz程序来自XZ Utils项目，它从接近2万行C代码中构建而来。C不是一个内存安全的语言。这意味着一个C程序的恶意输入，此处为XZ Utils正在解包的Docker镜像，有执行任意的代码的可能。
如果Docker以root运行xz，那会更糟糕，这意味着如果xz存在一个漏洞，执行docker pull将严重危及你的整个系统。
Tarsum
tarsum的使用出于好意，但完全错误。为了取得一个任意编码的tar文件的确定性校验和，Docker对tar进行解码然后以确定性顺序对特定部分进行哈希，排除了其他部分。
因为这个处理过程是为了生成校验和，它正在解码的不受信任的数据可被设计成利用tarsum代码的漏洞。这里可能的漏洞是拒绝服务***以及逻辑缺陷，这将引起文件在不改变校验和的情况下被注入、跳过、使用不同方式处理、修改、添加等。
解包
解包分为tar解码和将文件到保存到硬盘中两个步骤，在编写本文的时候已经有解包阶段的三个其他漏洞被报告出来，所以这也是非常危险的。
不应该存在未被检验的数据被解包到硬盘中的情况。
libtrust
libtrust是一个提供认证和权限控制的Docker包。但是官方没有提供任何的规范，但它看起来像是实现了Javascript对象签名与加密规范的一部分，以及其他不明算法。
所以在下载一个manifest签名的以及使用libtrust验证的镜像时，会有如下不准确的提示：
ubuntu:14.04: The image you are pulling has been verified
目前只有Docker公司公布的“官方”镜像manifest使用这个系统签名，但从我参加的最近一次Docker管理咨询委员会会议的讨论看来，Docker公司计划在未来更广泛的部署它。目标应该是集中管理，由Docker公司控制一个发证机构用于镜像和/或客户证明签名。
我曾在Docker代码中查找签名密钥，但没找到。看来密钥并没有嵌入到程序中。实际上，Docker后台会在每次镜像下载时通过HTTPS从CDN获取密钥。这是一个非常糟糕的方式，因为有很多种***可以导致受信任的密钥被替换成恶意的。这种***包括但不限于：CDN供应商威胁、CDN供应密钥源威胁以及客户端下载密钥时的中间人***。
补救
在完成此项研究之前，我已经报告了我发现的tarsum系统的几个问题，但至今没有一个被修复。
我觉得必须采取一些措施来改善Docker镜像下载系统的安全性：
弃用tarsum并实际验证镜像摘要
为安全起见，不应该使用tarsum。取而代之的是在进行任何处理前，将镜像完全下载并对其加密签名进行验证。
增加权限隔离
涉及解压缩或解包的镜像处理步骤必须运行于具有最低限度的必要的权限的隔离的程序（容器？）中。不应该存在像xz这样的解压缩工具必须以root运行的情况。
更换libtrust
用The Update Framework替换libtrust，前者是明确设计用于解决软件程序签名的实际问题的。它的威胁模型非常全面，并且解决了很多libtrust没有考虑到的事情。它拥有一个完整的规范，以及一个Python的参考实现，我已经开始Go的实现并且欢迎任何人加入。
作为添加TUF到Docker的一部分，一个映射根密钥到registry URL的本地密钥库将被加入，以便用户可以使用不受Docker公司管理的自有签名密钥。
我想指出的是，一般情况下使用非Docker公司托管的registry用户体验非常差。在没有任何技术原因的情况下，Docker公司似乎乐于将第三方registry降低为二等地位。这对一般的生态系统和最终用户的安全来说都是个问题。综合而言，针对第三方registry的分散的安全模型是必要和可取的。我非常期待Docker公司在重新设计他们的安全模型和镜像验证系统时考虑这一点。
结论
Docker用户应该清楚负责下载镜像的代码是极其不安全的。用户只能下载那些来源没有问题的镜像。目前，这不包括托管于Docker公司的“可信的”的镜像，包括官方的Ubuntu和其他基础镜像。
最好的办法是在本地阻止index.docker.io，并在镜像导入到Docker之前手动使用docker load下载并检验镜像。Red Hat的安全博客有篇与此相关的好文章。
原文：《Docker Image Insecurity》https://titanous.com/posts/docker-insecurity
译文出自：http://dockerone.com/article/77
5.Docker中root权限安全隐患
Docker并不是虚拟机，Docker本来的用法也不是虚拟机。举个简单的例子，普通的虚拟机租户root和宿主root是分开的，而Docker的租户root和宿主root是同一个root。一旦容器内的用户从普通用户权限提升为root权限，他就直接具备了宿主机的root权限，进而可进行几乎无限制的操作。这是为什么呢?因为Docker原本的用法是将进程之间进行隔离，为进程或进程组创建隔离开的运行空间，目的就是为了隔离有问题的应用，而进程之间的限制就是通过namespace和cgroup来进行隔离与配额限制。每一个隔离出来的进程组，对外就表现为一个container(容器)。在宿主机上可以看到全部的进程，每个容器内的进程实际上对宿主机来说是一个进程树。也就是说，Docker是让用户自以为占据了全部的资源，从而给用户一个“虚拟机”的感觉。
而且，Docker中可能会运行不受信任的应用程序。来源不明的应用程序，或者二进制代码等等，以及有漏洞的应用程序，都可以称为不受信任的应用程序。举个例子，在Docker容器中只运行基础的Apache服务器和MySQL数据库，可能大家认为这样的环境用root也没问题，但是如果Apache或者MySQL有不为人所知的漏洞被利用，那么这两个应用也就成为了不受信任的应用。因此，在以root运行应用程序或是在考虑安全环境的时候，需要以一切皆不可信的态度来对
6.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
如果开发者能访问或者***任何一个，就可以获得整个系统的控制权。
三．Docker安全性加固

• 文件系统级防护
  文件系统只读：有些Linux系统的内核文件系统必须要mount到容器环境里，否则容器里的进程就会罢工。这给恶意进程非常大的便利，但是大部分运行在容器里的App其实并不需要向文件系统写入数据。基于这种情况，开发者可以在mount时使用只读模式。比如下面几个：
  o. /sys
  o. /proc/sys
  o. /proc/sysrq-trigger
  o. /proc/irq
  o. /proc/bus
  用只读模式的好处是，那些在容器里权限比较高的进程也无法向宿主文件系统写入。当然这里需要注意一点，必须要把这些进程remount可读写文件系统的能力给禁止。更进一步开发者甚至可以禁止容器mount任何文件系统，这需要通过使用capability完成，下面会详细解释。
  写入时复制：Copy-on-write的具体解释请读者参考前面的维基百科链接。Docker采用的就是这样的文件系统。所有运行的容器可以先共享一个基本文件系统镜像，一旦需要向文件系统写数据，就引导它写到与该容器相关的另一个特定文件系统中。这样的机制避免了一个容器看到另一个容器的数据，而且容器也无法通过修改文件系统的内容来影响其他容器。
  
• Capability机制
  Linux对Capability机制阐述的还是比较清楚的，即为了进行权限检查，传统的UNIX对进程实现了两种不同的归类，高权限进程（用户ID为0，超级用户或者root），以及低权限进程（UID不为0的）。高权限进程完全避免了各种权限检查，而低权限进程则要接受所有权限检查，会被检查如UID、GID和组清单是否有效。从2.2内核开始，Linux把原来和超级用户相关的高级权限划分成为不同的单元，称为Capability，这样就可以独立对特定的Capability进行使能或禁止。
  通常来讲，不合理的禁止Capability，会导致应用崩溃，因此对于Docker这样的容器，既要安全，又要保证其可用性。开发者需要从功能性、可用性以及安全性多方面综合权衡Capability的设置。Dan在文中给出了Docker现有的Capability清单：chown、 dac_override、 fowner、 kill、 setgid、 setuid、 setpcap、 net_bind_service、 net_raw、 sys_chroot、 mknod、 setfcap 以及 audit_write。目前Docker安装时默认开启的Capability列表一直是开发社区争议的焦点，作为普通开发者，可以通过命令行来改变其默认设置。熟悉Linux内核的读者会发现，Docker提供的Capability是相对较少的。Dan在文中给出了Docker移除的Capability列表，并以CAP_NET_ADMIN为例，强调容器的设计应该是启动时配置好网络，而非从其内部修改，解释了容器安全性和Capability的 权衡，感兴趣的读者可以深入阅读。
  
• NameSpace机制
  Docker提供的一些命名空间也从某种程度上提供了安全保护，比如PID命名空间，它会将全部未运行在开发者当前容器里的进程隐藏。如果恶意程序看都看不见这些进程，***起来应该也会麻烦一些。另外，如果开发者终止pid是1的进程命名空间，容器里面所有的进程就会被全部自动终止，这意味着管理员可以非常容易地关掉容器。此外还有网络命名空间，方便管理员通过路由规则和iptable来构建容器的网络环境，这样容器内部的进程就只能使用管理员许可的特定网络。如只能访问公网的、只能访问本地的和两个容器之间用于过滤内容的容器。
  
• Cgroups机制
  主要是针对拒绝服务***。恶意进程会通过占有系统全部资源来进行系统***。Cgroups机制可以避免这种情况的发生，如CPU的cgroups可以在一个Docker容器试图破坏CPU的时候登录并制止恶意进程。Dan表示，需要设计更多的cgroups，用于控制那些打开过多文件或者过多子进程等资源的进程。类似的在文中Dan还介绍了设备cgroups。
  
• SELinux
  SELinux是一个标签系统，进程有标签，每个文件、目录、系统对象都有标签。SELinux通过撰写标签进程和标签对象之间访问规则来进行安全保护。它实现的是一种叫做MAC（Mandatory Access Control）的系统，即对象的所有者不能控制别人访问对象。具体可以参见Dan的这篇文章。至于如何用SELinux来进行容器的安全防护，Infoq会有另一篇文章来详细介绍Dan的思想。
  总而言之，为了保证Docker容器的安全性，Dan的团队尝试了非常多的安全机制，但是正如之前一篇文章中讲的，安全不在于机制的健全，而在于管理员自身的防范。在文章的结尾，Dan给出了管理员应该注意的一些事项，如只运行来自可信来源的应用，在安全防护比较好的宿主机上运行等等。
  6.Docker安全要依靠其他的辅助机制
  该作者还强调，如果坚持要root权限使用 Docker Engine ，系统的安全性可能会受到一系列众所周知的内核安全漏洞的影响。因此特别建议：
  · 在运行 Docker Engine 的系统中同时运行 AppArmor 或者 SELinux。
  · 将机器分成不同的组，相互信任的容器划在一组。
  · 不要以 root 权限运行任何不受信任的应用程序。
  在上述三条建议之上，还应该有一种机制，就是保障机制。要不停地轮序去检测，要能够发现可疑的行为，并且对任何可疑的行为要有反应。比如进程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被使用在私有云[注]环境中，那么它所带来的好处要远远多于其带来的问题。