Docker维护者采取了多种手段来减少运行容器的安全风险。例如：

• 某些特定的核心挂载点（如/proc和/sys）现在是以只读方式挂载的；
• 降低了默认的Linux能力；
• 现在已经存在对第三方安全系统（如SELinux和AppArmor）的支持。

本节中，我们会对这些有更深入的了解，可以采取其中的一些手段来降低在系统上运行容器的风险。

技巧93　限制能力

正如我们提到的，容器上的root用户和宿主机上的root用户是一样的。但是不是所有的root用户都生而平等。Linux允许为root用户分配进程级别的更加细粒度的权限。

这些细粒度的权限被称为能力（capability），这样即使是root用户，也能限制他们所能做的破坏。本技巧展示了当运行Docker容器的时候如何操纵这些能力，特别是在不完全信任其内容的时候。

问题

想要降低容器在宿主机上进行破坏性活动的能力。

解决方案

使用--drop-cap标志减少容器可以获得的能力。

1．Unix信任模型

为了了解“减少能力”的含义和作用，需要一点儿背景知识。当Unix系统被设计出来的时候，其信任模型并不复杂。存在被信任的管理员（root用户）和不被信任的用户。root用户可以做任何事情，然而普通用户只能影响他们自己的文件。因为这个操作系统一般是在大学实验室里使用而且本身不大，所以这个模型还是合理的。

随着Unix模型的发展以及互联网的到来，这个模型越来越不合理了。类似网络服务器的程序需要root权限来在80端口提供内容，同时它们也作为在宿主机上执行命令的有效代理。针对这些情况有些标准的应对模式，例如，绑定到端口80并把有效用户ID赋予一个非root用户。扮演着不同角色的用户，从系统管理员到数据库管理员，直到应用支持工程师和开发者，可能都需要对不同的系统上的资源有细粒度的访问权限。Unix用户组从某种程度上减轻了这个问题，但是正如任何系统管理员都会说的那样，为这些权限需求建模并不是一个小问题。

2．Linux能力

为了尝试支持一个更加细粒度的对用户权限进行管理的方式，Linux内核工程师们开发了能力（capability）。它尝试把单块的root权限拆解成各个可以独立授予的功能片段。读者可以通过执行man 7 capabilities来查看更多细节（假设安装了帮助手册）。

有用的是，Docker默认关闭了一些特定的能力。也就是说，即使在容器内有root权限，有些事也做不了。例如，允许影响网络栈的CAP_NET_ADMIN能力，默认就被禁用了。

表14-1列出了Linux的各项能力，给出了对它们允许做的事情的简要介绍，并且标明了它们是否在Docker容器内默认开启。

表14-1　Docker容器中的Linux能力

注意　

如果读者使用的不是Docker默认的容器引擎（libcontainer），这些能力可能在读者安装的软件上有所不同。如果有系统管理员，可以去请教他们，确认这些能力。

但是，内核维护者仅在系统内分配了32个能力，所以这些能力都拓展了自己的范围，同时越来越多的细粒度root权限在内核外被创造出来。最值得一提的是，命名模糊的CAP_SYS_ADMIN能力涵盖了从改变宿主机域名到超出系统范围内打开文件数量的上限等多种不同行为。

一种极端的做法是从容器内移除所有在Docker默认开启的能力，然后看一下什么不工作了。在此我们运行一个移除所有默认开启的能力的bash脚本：

$ docker run -ti --cap-drop=CHOWN --cap-drop=DAC_OVERRIDE 
--cap-drop=FSETID --cap-drop=FOWNER --cap-drop=KILL --cap-drop=MKNOD 
--cap-drop=NET_RAW --cap-drop=SETGID --cap-drop=SETUID 
--cap-drop=SETFCAP --cap-drop=SETPCAP --cap-drop=NET_BIND_SERVICE 
--cap-drop=SYS_CHROOT --cap-drop=AUDIT_WRITE debian /bin/bash

如果通过这个shell来运行程序，可以看到它是在什么地方如期失败，然后重新加上所需的能力。例如，用户可能需要改变文件所有权的能力，那么在前述的代码中就不能去掉FOWNER能力：

$ docker run -ti --cap-drop=CHOWN --cap-drop=DAC_OVERRIDE 
--cap-drop=FSETID --cap-drop=KILL --cap-drop=MKNOD 
--cap-drop=NET_RAW --cap-drop=SETGID --cap-drop=SETUID 
--cap-drop=SETFCAP --cap-drop=SETPCAP --cap-drop=NET_BIND_SERVICE 
--cap-drop=SYS_CHROOT --cap-drop=AUDIT_WRITE debian /bin/bash

提示　

如果想要启用或禁用所有的能力，可以使用all而不是某个特定的能力，如docker run -ti --cap-drop=all ubuntu bash。

讨论

如果在bash shell中以禁用所有能力来执行一些基本的命令，会发现这很有用。尽管在运行一些更复杂的程序的时候得到的好处可能会有所不同。

警告　

值得澄清的是，这些能力中的很大一部分是和影响系统上其他用户的对象的root能力相关的，而不是root自己的对象。一个root用户仍然能够使用chown命令改变宿主机上root文件的所有权。例如，假设他们是在容器内操作并且通过卷挂载的方式能够访问宿主机的文件。因此，纵使所有这些能力都关闭了，仍然值得把应用程序降级为一个非root用户。

这种对容器的能力的调优能力意味着对docker run使用--privileged标志就不必要了。需要能力的进程会被审计并且处于宿主机管理员的控制之下。

技巧94　扫描一个“坏”Docker镜像

Docker生态系统中大家很快认识到的问题之一就是其脆弱性——如果你的镜像不可改变，就无法获得任何安全修复。如果你遵循Docker最佳实践中的镜像极简主义准则，这可能也不是问题，但是这很难讲。

镜像扫描器就是作为这一问题的解决方案而创建的，但是它还是没解决如何评估它们的问题。

问题

想要知道镜像扫描器的效率如何。

解决方案

创建一个“已知的坏”镜像来测试扫描器。

我们在工作中要面对这种问题。有很多Docker镜像扫描器存在（如Clair），但是商业软件声称可以更加深入镜像来确定任何潜在的问题。

但是含有已知并且文档标明的漏洞以供我们测试这些扫描器的镜像并不存在。这不出奇，因为大多数镜像并不标榜自己不安全！

因此我们创建了一个已知的坏镜像。这一镜像可供下载：

$ docker pull imiell/bad-dockerfile

原则很简单：创建一个带有注明了的漏洞的镜像，然后在你候选的扫描器里指定该镜像。

该Dockerfile的最新版本还处于变化之中，所以这里没有印出。但是，它的形式还是相当简单的：

FROM 　　⇽---　该引用的坏dockerfile仓库使用了一个centos镜像，但是你可以换成接近你自己的基础镜像的镜像
RUN 　　⇽---　
COPY 　　⇽---　一系列的RUN/COPY/ADD命令来向这个镜像安装有漏洞的软件
[...]
CMD echo 'Vulnerable image' && /bin/false　　⇽---　因为显而易见的原因，让这个镜像尽量不允许自己执行的CMD命令

这一镜像含有各种各样的漏洞，足以让扫描器尽其所能。

在最简单的情况下，该镜像使用包管理器下载了各种各样有漏洞的软件。在各个领域，该Docker镜像都试图包含各种严重性的漏洞。

更复杂的植入漏洞的方式是使用，例如，复制有漏洞的JavaScript代码，使用各语言特定的包管理器（如JavaScript的npm、Ruby的gem和Python的pip）来安装有漏洞的代码，甚至编译特定版本的bash（有臭名昭著的Shellshock漏洞的那一版），将其放置在一个意想不到的位置来避免使用很多扫描技巧。

讨论

你可能会觉得最好的扫描方案就是能抓到最多的CVE的那个。但是这可不一定。显然，扫描器能找到镜像中的漏洞是很好的。但是除此之外，扫描漏洞可能比起科学更像是一门艺术。

提示　

公共漏洞与暴露（Common Vulnerability Exposure，CVE）是对于通用软件中的特定漏洞的一个标识符。一个CVE的例子可能是CVE-2001-0067，起始的4个字母代表发现的年份，第二部分代表了那一年发现的漏洞数。

例如，一个漏洞可能非常严重（如在你的宿主机上获得root权限），但是很难暴露出来（如需要一个国家的资源）。你（或者你负责的组织）可能更加担忧哪些没那么严重但是比较容易暴露的漏洞。例如，对你的系统有DoS攻击，这没有数据泄露或渗透的风险，但是可能因此无法开展业务，所以你可能更想给它打个补丁，而不是某些需要价值几万美金的计算力才能发起的模糊加密器攻击。

什么是DOS攻击　

DoS代表“denial of service”（拒绝服务）。这意味着，这种攻击可以降低你的系统按照指令工作的能力。拒绝服务攻击可以压迫Web服务器以至于它无法为合法用户提供服务。

同时，对于运行中的容器，也值得考虑一下该漏洞是否真的存在。镜像里可能有一个老版本的Apache服务器，但是如果它从来没运行过，这个漏洞就可以忽略。这很常见。包管理器经常带来一些并不是真正需要的依赖，只不过是为了让依赖管理更简单点。

如果安全确实是一个大问题，那么这也是有小镜像的另一个理由（见第7章）——就算有软件没用到，它仍然可能在安全扫描里出现，浪费了组织需要来搞明白需不需要打补丁的时间。

本技巧希望能让你思考哪个扫描器才是最合适的。一如既往，这是一种花费、需求以及为了获取正确的解决方式而花费的力气之间的平衡。

本文摘自《Docker实践 第2版》