1. 研究目的与意义（文献综述）

本课题为“Docker安全机制改进研究”，Docker是 PaaS 提供商 dotCloud 于2013年开源的一个基于 LXC 的高级容器引擎，它是轻量级的虚拟容器技术，与VirtualBox、VMware相比它具有轻量，可控性，可迁移，配置方便等优点而逐渐让人熟知，目前广泛应用于云计算中。但在安全方面，VMware、VirtualBox是硬件虚拟化平台，他所虚拟的每个空间都有完整的操作系统内核，而Docker是基于Linux系统之上的虚拟技术，所以相比传统的虚拟模式，Docker的安全性还需要研究改进。

1.1研究目的

本课题针对目前Docker的安全性，运用Docker所提供的API开发一个可对Docker进行访问控制的系统，通过此系统可以让用户打包加密自己的Image镜像，而拥有秘钥的用户则可以将Image解压到本地容器中进行环境部署。

1.2国内外研究现状分析

首先了解一下Docker的架构，Docker是一个C/S模式的架构^[1-2]，而Docker的后端是一个非常松耦合的架构，模块各司其职，并有机组合，支撑Docker的运行，如图1所示。

图1 Docker架构

Docker 守护进程

如上图所示，Docker 守护进程运行在一台主机上。用户并不直接和守护进程进行交互，而是通过 Docker 客户端间接和其通信。

Docker 客户端

Docker 客户端，实际上是 docker 的二进制程序，是主要的用户与 Docker 交互方式。它接收用户指令并且与背后的 Docker 守护进程通信，如此来回往复。

此外Docker还有三个非常重要的概念^[3-6]，Docker 镜像 -Docker images，Docker 仓库 -Docker registries，Docker 容器 -Docker containers

1)Docker 镜像

Docker 镜像是 Docker 容器运行时的只读模板，每一个镜像由一系列的层 (layers) 组成。Docker 使用 UnionFS 来将这些层联合到单独的镜像中。UnionFS 允许独立文件系统中的文件和文件夹(称之为分支)被透明覆盖，形成一个单独连贯的文件系统。正因为有了这些层的存在，Docker 是如此的轻量。当你改变了一个 Docker 镜像，比如升级到某个程序到新的版本，一个新的层会被创建。因此，不用替换整个原先的镜像或者重新建立(在使用虚拟机的时候你可能会这么做)，只是一个新 的层被添加或升级了。现在你不用重新发布整个镜像，只需要升级，层使得分发 Docker 镜像变得简单和快速^[7-10]。

2)Docker 仓库

Docker 仓库用来保存镜像，可以理解为代码控制中的代码仓库。同样的，Docker 仓库也有公有和私有的概念。公有的 Docker 仓库名字是 Docker Hub。Docker Hub 提供了庞大的镜像集合供使用。这些镜像可以是自己创建，或者在别人的镜像基础上创建。Docker 仓库是 Docker 的分发部分。

3)Docker 容器

Docker 容器和文件夹很类似，一个Docker容器包含了所有的某个应用运行所需要的环境。每一个 Docker 容器都是从 Docker 镜像创建的。Docker 容器可以运行、开始、停止、移动和删除。每一个 Docker 容器都是独立和安全的应用平台，Docker 容器是 Docker 的运行部分。

那么Docker的安全是怎么维护的呢？我们知道Docker是基于Linux的开源项目，Linux通过Linux Namespaces机制提供一种资源隔离方案。PID,IPC,Network等系统资源不再是全局性的，而是属于特定的Namespace。每个Namespace里面的资源对其他Namespace都是透明的。要创建新的Namespace，只需要在调用clone时指定相应的flag。LinuxNamespaces机制为实现基于容器的虚拟化技术提供了很好的基础，LXC（Linux containers）就是利用这一特性实现了资源的隔离。不同container内的进程属于不同的Namespace，彼此透明，互不干扰。namespace将container的进程、网络、消息、文件系统、UTS("UNIXTime-sharing System")和用户空间隔离开。

1)pid namespace

不同用户的进程就是通过pidnamespace隔离开的，且不同 namespace 中可以有相同pid。所有的LXC进程在docker中的父进程为docker进程，每个lxc进程具有不同的namespace。同时由于允许嵌套，因此可以很方便的实现 Docker inDocker。

2)net namespace

有了 pid namespace, 每个namespace中的pid能够相互隔离，但是网络端口还是共享host的端口。网络隔离是通过net namespace实现的， 每个net namespace有独立的 network devices, IPaddresses, IP routing tables, /proc/net 目录。这样每个container的网络就能隔离开来。docker默认采用veth的方式将container中的虚拟网卡同host上的一个docker bridge: docker0连接在一起。

3)ipc namespace

container中进程交互还是采用linux常见的进程间交互方法(interprocess communication - IPC), 包括常见的信号量、消息队列和共享内存。然而同 VM 不同的是，container 的进程间交互实际上还是host上具有相同pid namespace中的进程间交互，因此需要在IPC资源申请时加入namespace信息 - 每个IPC资源有一个唯一的 32 位 ID。

4)mnt namespace

类似chroot，将一个进程放到一个特定的目录执行。mnt namespace允许不同namespace的进程看到的文件结构不同，这样每个 namespace 中的进程所看到的文件目录就被隔离开了。同chroot不同，每个namespace中的container在/proc/mounts的信息只包含所在namespace的mount point。

5)uts namespace

UTS("UNIX Time-sharingSystem") namespace允许每个container拥有独立的hostname和domain name, 使其在网络上可以被视作一个独立的节点而非Host上的一个进程。

6)user namespace

每个container可以有不同的 user 和 group id, 也就是说可以在container内部用container内部的用户执行程序而非Host上的用户^[11-13]。

所以Docker的安全性问题90%以上都可以归结为隔离性问题，而Docker的安全问题本质上就是容器技术的安全性问题，这包括共用内核问题以及Namespace还不够完善的限制：/proc、/sys等未完全隔离、Top,free, iostat等命令展示的信息未隔离、Root用户未隔离、/dev设备未隔离、内核模块未隔离。

SELinux、time、syslog等所有现有Namespace之外的信息都未隔离当然，镜像本身不安全也会导致安全性问题。在接纳了“容器并不是全封闭”这种思想以后，开源社区尤其是红帽公司，连同Docker一起改进Docker的安全性，改进项主要包括保护宿主不受容器内部运行进程的入侵、防止容器之间相互破坏。开源社区在解决Docker安全性问题上的努力包括：

1)Audit namespace

作用：隔离审计功能

未合入原因：意义不大，而且会增加audit的复杂度，难以维护。

2)Syslognamespace

作用：隔离系统日志

未合入原因：很难完美的区分哪些log应该属于某个container。

3)Device namespace

作用：隔离设备（支持设备同时在多个容器中使用）

未合入原因：几乎要修改所有驱动，改动太大。

4)Time namespace

作用：使每个容器有自己的系统时间

未合入原因：一些设计细节上未达成一致，而且感觉应用场景不多。

5)Task count cgroup

作用：限制cgroup中的进程数，可以解决forkbomb的问题

未合入原因：不太必要，增加了复杂性，kmemlimit可以实现类似的效果。(最近可能会被合入)

6)隔离/proc/meminfo的信息显示

作用：在容器中看到属于自己的meminfo信息^[14-18]

一些企业也做了很多工作，比如一些项目团队采用了层叠式的安全机制，这些可选的安全机制具体如下：

1)文件系统级防护

文件系统只读：有些Linux系统的内核文件系统必须要mount到容器环境里，否则容器里的进程就会罢工。这给恶意进程非常大的便利，但是大部分运行在容器里的App其实并不需要向文件系统写入数据。基于这种情况，开发者可以在mount时使用只读模式。比如下面几个： /sys 、/proc/sys 、/proc/sysrq-trigger 、 /proc/irq、/proc/bus

写入时复制（Copy-On-Write）：Docker采用的就是这样的文件系统。所有运行的容器可以先共享一个基本文件系统镜像，一旦需要向文件系统写数据，就引导它写到与该容器相关的另一个特定文件系统中。这样的机制避免了一个容器看到另一个容器的数据，而且容器也无法通过修改文件系统的内容来影响其他容器。

2)Capability机制

Linux对Capability机制阐述的还是比较清楚的，即为了进行权限检查，传统的UNIX对进程实现了两种不同的归类，高权限进程（用户ID为0，超级用户或者root），以及低权限进程（UID不为0的）。高权限进程完全避免了各种权限检查，而低权限进程则要接受所有权限检查，会被检查如UID、GID和组清单是否有效。从2.2内核开始，Linux把原来和超级用户相关的高级权限划分成为不同的单元，称为Capability，这样就可以独立对特定的Capability进行使能或禁止。通常来讲，不合理的禁止Capability，会导致应用崩溃，因此对于Docker这样的容器，既要安全，又要保证其可用性。开发者需要从功能性、可用性以及安全性多方面综合权衡Capability的设置。目前Docker安装时默认开启的Capability列表一直是开发社区争议的焦点，作为普通开发者，可以通过命令行来改变其默认设置。

3)NameSpace机制

Docker提供的一些命名空间也从某种程度上提供了安全保护，比如PID命名空间，它会将全部未运行在开发者当前容器里的进程隐藏。如果恶意程序看都看不见这些进程，攻击起来应该也会麻烦一些。另外，如果开发者终止pid是1的进程命名空间，容器里面所有的进程就会被全部自动终止，这意味着管理员可以非常容易地关掉容器。此外还有网络命名空间，方便管理员通过路由规则和iptable来构建容器的网络环境，这样容器内部的进程就只能使用管理员许可的特定网络。如只能访问公网的、只能访问本地的和两个容器之间用于过滤内容的容器。

4)Cgroups机制

主要是针对拒绝服务攻击。恶意进程会通过占有系统全部资源来进行系统攻击。Cgroups机制可以避免这种情况的发生，如CPU的cgroups可以在一个Docker容器试图破坏CPU的时候登录并制止恶意进程。管理员需要设计更多的cgroups，用于控制那些打开过多文件或者过多子进程等资源的进程^[19]。

5)SELinux

SELinux是一个标签系统，进程有标签，每个文件、目录、系统对象都有标签。SELinux通过撰写标签进程和标签对象之间访问规则来进行安全保护。它实现的是一种叫做MAC（Mandatory Access Control）的系统，即对象的所有者不能控制别人访问对象^[20-25]。

在Docker镜像方面，由于镜像没有经过校验，镜像经由HTTPS服务器下载后，通过一个未加密的管道流进入Docker守护进程，导致不安全的处理管道。

1)解压缩

Docker支持三种压缩算法：gzip、bzip2和xz。前两种使用Go的标准库实现，是内存安全（memory-safe)的，因此这里的攻击类型应该是拒绝服务类的攻击，包括CPU和内存使用上的当机或过载等等。

第三种压缩算法，xz，比较有意思。因为没有现成的Go实现，Docker 通过执行(exec)xz二进制命令来实现解压缩。

xz二进制程序来自于XZ Utils项目，由大概2万行C代码生成而来。而C语言不是一门内存安全的语言。这意味着C程序的恶意输入，在这里也就是Docker镜像的XZ Utils解包程序，潜在地存在可能会执行任意代码的风险。

Docker以root权限运行 xz 命令，更加恶化了这一潜在威胁。这意味着如果在xz中出现了一个漏洞，对docker pull命令的调用就会导致用户整个系统的完全沦陷。

2)Tarsum

对tarsum的使用，其出发点是好的，但却是最大的败笔。为了得到任意一个加密tar文件的准确校验和，Docker先对tar文件进行解密，然后求出特定部分的哈希值，同时排除剩余的部分，而这些步骤的顺序都是固定的。

由于其生成校验和的步骤固定，它解码不可信数据的过程就有可能被设计成攻破tarsum的代码。这里潜在的攻击既包括拒绝服务攻击，还有逻辑上的漏洞攻击，可能导致文件被感染、忽略、进程被篡改、植入等等，这一切攻击的同时，校验和可能都是不变的。

3)解包

解包的过程包括tar解码和生成硬盘上的文件。这一过程尤其危险，因为在解包写入硬盘的过程中有另外三个已报告的漏洞。任何情形下未经验证的数据都不应当解包后直接写入硬盘。

补救措施可以摒弃tarsum并且真正对镜像本身进行验证，出于安全原因tarsum应当被摒弃，同时，镜像在完整下载后、其他步骤开始前，就对镜像的加密签名进行验证。

1)添加权限隔离

镜像的处理过程中涉及到解压缩或解包的步骤必须在隔离的进程（容器）中进行，即只给予其操作所需的最小权限。任何场景下都不应当使用root运行xz这样的解压缩工具。

2)替换 libtrust

应当用更新框架(The Update Framework)替换掉libtrust，这是专门设计用来解决软件二进制签名此类实际问题的。其威胁模型非常全方位，能够解决libtrust中未曾考虑到的诸多问题，目前已经有了完整的说明文档。作为将更新框架加入Docker的一部分，还应当加入一个本地密钥存储池，将root密钥与registry的地址进行映射，这样用户就可以拥有他们自己的签名密钥，而不必使用Docker公司的了。

此外还有些资料提出了一些加固方案，1.减少容器主机本身的漏洞，2.加强容器主机权限控制， 3.加强容器主机资源隔离，4.加强容器间隔离，5.容器基础镜像安全管理，6. 容器安全监控与审计，7. 容器安全防护与入侵检测^[26-30]。

1.3研究意义

Docker最早由PaaS提供商dotCloud于2013 年开源，由于其深度契合云时代对容器技术的需求，在业内得以快速传播，并在 2014 年实现爆发式发展。目前该技术已得到 IBM、Google、亚马逊、Red Hat、VMware 和微软等重量级云计算企业的大力支持，纷纷宣布在自己的操作系统、虚拟机或是云计算平台中支持 Docker。在国内，百度、腾讯、搜狐、中科院软件所等企事业单位也在积极参与 Docker 的应用和开发。可以预见，以 Docker 为代表的云时代容器技术凭借其巨大的技术优势将逐渐替代传统硬件虚拟化技术，成为云计算基础环境实施的主流技术方案。所以Docker容器的安全就显得格外的重要，云计算安全技术也是当前技术发展的热点。

2. 研究的基本内容与方案

本课题通过利用docker提供的api设计访问控制插件来达到，用户打包自己的镜像，将其只分享给需要分享的用户成为可能，来提高docker的安全性。

2.1 基本内容与研究目标

通过docker api 的调用，编写docker-py client实现对image文件的加密解密，从而实现docker镜像的访问控制。

3. 研究计划与安排

第 1-4周：完成毕业设计选题调研、文献阅读和外文翻译，收集相关资料，完成开题报告，进行小组内选题答辩。上传开题报告到教务网，完成开题任务。

第 5-6周：熟悉linux操作系统及内核相关知识、go语言、python语言及docker-py库。

第 7-12周：利用docker-py库完成访问控制算法代码的实现。

4. 参考文献（12篇以上）

[1]karl matthias sean p. kane. docker:uprunning[m]. o’reilly. 2015

[2] 杨宝华，戴王剑，曹亚仑. docker技术入门与实战[m].机械工业出版社.2014