武汉大学学报(理学版) 2017, Vol. 63 Issue (2): 102-108
0

文章信息

王鹃, 胡威, 张雨菡, 陈铜, 于鹏, 赵波, 张焕国
WANG Juan, HU Wei, ZHANG Yuhan, CHEN Tong, YU Peng, ZHAO Bo, ZHANG Huanguo
基于Docker的可信容器
Trusted Container Based on Docker
武汉大学学报(理学版), 2017, 63(2): 102-108
Journal of Wuhan University(Natural Science Edition), 2017, 63(2): 102-108
http://dx.doi.org/10.14188/j.1671-8836.2017.02.002

文章历史

收稿日期：2016-08-15
Abstract              PDF              Figures              Tables
引用本文
王鹃, 胡威, 张雨菡, 陈铜, 于鹏, 赵波, 张焕国. 基于Docker的可信容器[J]. 武汉大学学报 (理学版),2017, 63(2): 102-108.
WANG Juan, HU Wei, ZHANG Yuhan, CHEN Tong, YU Peng, ZHAO Bo, ZHANG Huanguo. Trusted Container Based on Docker[J]. Journal of Wuhan University (Natural Science Edition) , 2017, 63(2): 102-108.
基于Docker的可信容器
王鹃1,2, 胡威1, 张雨菡1, 陈铜1, 于鹏1, 赵波1,2, 张焕国1,2    
1. 武汉大学 计算机学院, 湖北 武汉 430072;
2. 教育部空天信息安全与可信计算重点实验室，湖北 武汉 430072
收稿日期：2016-08-15
基金项目：国家自然科学基金项目 (61332019);国家重点基础发展计划 (973)(2014CB340600) 资助项目
作者简介：王鹃, 女，博士，副教授, 主要从事网络与系统安全、安全协议、身份认证、访问控制领域方面研究. E-mail: jwang@whu.edu.cn
摘要：针对Docker目前存在的容器及镜像被篡改、容器的恶意进程及非授权通信问题，利用可信计算的相关技术如信任链、完整性度量以及实时监控等方法，设计并实现了一个可信增强的Docker容器-DockerGuard.DockerGuard构造了一条从硬件到容器内部进程和文件的信任链，同时增加了包括进程监控、文件系统度量、网络监控三大功能于一体的安全防护模块，从而全方位对Docker进行度量与细粒度的监控.基于Docker1.6.0实现了具备上述功能的安全增强系统DockerGuard，并对系统进行了性能评估.结果表明，DockerGuard可以保护容器及镜像不被篡改，同时限制容器网络通信行为并监控容器内部进程，极大地提高了Docker容器的安全性.
关键词：Docker     容器     可信计算    
Trusted Container Based on Docker
WANG Juan1,2, HU Wei1, ZHANG Yuhan1, CHEN Tong1, YU Peng1, ZHAO Bo1,2, ZHANG Huanguo1,2    
1. School of Computer, Wuhan University, Wuhan 430072, Hubei, China;
2. Key Laboratory of Aerospace Information Security and Trust Computing, Ministry of Education, Wuhan 430072, Hubei, China
Abstract: Docker is a greatly popular open source container engine now. Compared with the hardware virtualization technology, Docker has some new features, including highly resource utilization, easy deployment, fast starting, good flexibility and so on. Because the virtualization technology of Docker is based on software and the sharing of same Linux kernel by multiple containers, hence its security problem is absolutely worse compared with the traditional hardware virtualization, such as unauthorized access to the underlying container resources, tampered container, and invaded container service, etc. Aiming at the security issues above, trusted computing, integrity measurement and real-time monitoring methods were used to reinforce the Docker container system so as to implement a security enhanced trusted container and its management system-DockerGuard. DockerGuard constructed a trusted chain from the hardware to the container internal process and document, also included the security module with the process monitoring, file system metrics, network monitoring functions, thus protecting the Docker with fully measure and fine-grained monitoring. We implemented a security enhanced system DockerGuard with the above functions based on Docker1.6.0 and evaluated the performance of the system. The results show that DockerGuard can protect the container and image from tampering, while limit the network communication behavior of the container and monitor the internal process of the container, which greatly improves the security of the Docker container.
Key words: Docker     container     trusted computing    
0 引言

Docker是一个开源的应用容器引擎[1]，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器.2013年Docker由PaaS提供商dotCloud开源，并托管在github上[2].Docker作为轻量级虚拟化技术的代表，是LXC技术的扩展，被认为是虚拟化领域的一次革新[3].与传统的硬件虚拟化方式不同，Docker采用的是基于操作系统层的虚拟化技术，即直接在宿主OS上对应用进行虚拟化，通过对应用组件的封装、分发、部署、运行等生命周期的管理，达到应用组件级别的“一次封装，到处运行”[4].

相比于硬件虚拟化技术，Docker在开发和运维的过程中，具有一些优势：1) 更快速的交付和部署；2) 更高效的资源利用；3) 更轻松地迁移和扩展；4) 更简单的更新管理.除此之外，Docker在性能上的优势最为明显.传统虚拟化方式中每个虚拟机都会有虚拟的GuestOS，需要额外的操作系统开销[5].而Docker容器使用公用的宿主OS，在运行容器中的应用之外，基本不消耗额外的系统资源[6].Docker具备的诸多优点使得其发展前景被业内普遍看好.在最近一次Linux基金会的调查中，Docker是仅次于OpenStack的最受欢迎的云计算开源项目.Google、微软、亚马逊等公司相继在其云平台上实现对Docker的支持，利用Docker做出了一些新的尝试，如利用Docker将Web服务迁移到云服务上[7]，可见Docker在行业内的火热程度.

随着Docker技术应用规模越来越大，领域越来越广，其面临的诸多安全挑战也逐渐被人们关注，诸如容器内用户越权访问底层资源，容器自身被篡改以及容器内服务被入侵等，这些安全隐患已经成为阻碍Docker发展的关键因素.从Docker中已被发现的各类安全问题中可以看出，Docker镜像及容器均存在被篡改的风险，同时不完全的隔离性导致容器之间存在非授权通信的风险，容器内部的恶意进程或恶意数据同样给Docker系统甚至宿主机带来风险.这些安全威胁在业内被广泛的认识到，已有不少方法来加强Docker的安全性，如强制访问控制[8].

针对上述安全威胁，我们提出一种面向Docker的容器可信加固方法.

1 Docker面临安全挑战

Docker所提供的安全性主要依赖于三种Linux内核安全机制：namespaces[9]负责构建隔离环境，cgroups[10]主要限制容器对系统资源的使用，capability[11]用于实现特权分离.三种机制协同工作，为Docker容器提供一个相对独立的工作环境[12].但事实上，仅仅依靠这三种安全机制并不能解决Docker面临的所有安全威胁.其中最主要的缺陷是，namespaces所提供的隔离性并不完全，特别是在网络通信方面[13].虽然每个容器都有自己的网络协议栈，但是容器仍然可以通过端口与宿主机或其他容器进行网络通信.与一般的网络通信一样，容器可以发送UDP数据包，建立TCP连接等等.除了显式的开放端口之外，Docker还提供了一种特殊的容器互联方式--link，该方式允许当前容器与特定容器进行网络通信，但并不能做出细粒度的限制，一旦允许通信，就可以访问任意端口.这样无疑增加了容器非授权通信的风险.

Docker Daemon的安全风险：Docker Daemon作为Docker的处理中心，承载着几乎全部的配置管理工作，其最主要的安全问题是特权过于集中.由于Daemon需要处理的任务众多，所以Docker在设计时赋予Daemon全部特权.这意味着攻击者只要攻陷Daemon，就等于拿到宿主机的root权限.这样的做法给Docker安全带来极大的隐患，给攻击者提供了更多的方式进行远程提权.

Docker镜像的安全风险：Docker镜像是Docker整体安全性中很弱的一环，根据CVE收录的有关于Docker的漏洞来看，由Docker镜像所引发的漏洞占了40%左右[14]，如CVE-2014-6407, CVE-2014-9356, CVE-2014-9357等.攻击者主要是通过符号链接攻击或硬链接攻击进行远程提权，攻击者通常需要事先构造一个恶意镜像或build，当用户下载了恶意镜像或build后，在解压提取过程中，会允许恶意代码任意读写文件系统，从而使攻击者得到root权限.虽然这些漏洞在新版本中都被修复，但是也说明了Docker在镜像管理方面所做的努力还远远不够.镜像被篡改后给系统带来的风险极大，保证镜像可信就变得至关重要.

Docker容器的安全风险：Docker容器是Docker虚拟化的最终表现形式，所有具体的应用均通过容器的形式呈现给用户.容器是运行在隔离环境下的Linux进程，但Docker的隔离性并不像传统虚拟化技术一样完备，运行在容器中的进程仅靠namespace技术很难保证其安全性.同时Docker支持共享目录功能，用户可以创建共享目录以实现容器与容器之间、容器与宿主机之间的文件共享，加之容器启动时默认以root用户运行.所以通过共享目录，用户可以无限制的从容器内部访问宿主机文件系统，或者从宿主机的角度任意更改容器内部的应用数据，这就给Docker带来非常大的安全风险.另一方面，Docker并不关心容器内部运行何种进程，产生何种数据.而随着Docker的应用领域越来越广，应用场景越来越多，Docker容器内部应用的安全性与可信性也变得愈发重要.例如基于Docker容器的大规模服务器集群应用场景，其中Docker容器内部运行了各种应用服务，这些服务是否始终安全可信，关乎整个服务器集群的安危.所以，对容器内部的安全增强也是关注的重点.除此之外，Docker对容器的网络通信行为没有细粒度的控制机制，仅可以设置容器允不允许联网，若容器可以联网，则代表其可以不加限制的访问互联网，这就易受到常见的网络攻击.

防范策略：

1) Docker镜像及容器均存在被篡改的风险，被篡改的恶意镜像会带来无法估量的后果.Docker隔离机制过于单薄的硬伤导致容器之间、容器与外界之间易出现非授权通信行为.其次，Docker混乱的共享机制增大了宿主机被篡改的风险.完整性度量技术则可以及时检测出容器是否被篡改，降低容器遭到破坏的可能性[15].

2) Docker容器内部运行的进程和文件如果被篡改会危害到外部宿主机的安全.Docker本身不完全的隔离性使得恶意容器存在逃逸的可能，即恶意容器可以穿透隔离机制直接影响宿主机，或者通过共享机制将恶意数据写入宿主机.不管何种方式，都将带来严重的安全风险.因此需要对Docker容器内的进程和文件进行监控，防范恶意进程.

3) 容器的通信行为没有被完善的监控，一旦容器被恶意程序感染，就存在通过网络通信传播恶意代码的可能性，因此需要对容器间的通信进行监控，以防止容器间的非授权通信.

综上所述，保护容器及镜像不被篡改十分重要，同时需要限制容器的网络通信行为并监控容器内部进程.这样即可规避大部分安全风险，极大地提高Docker容器的安全性.

2 Docker可信容器方案设计 2.1 设计思路

根据前文对Docker安全性风险的分析和结论，针对Docker中存在的容器及镜像被篡改、容器的恶意进程及非授权通信问题，设计了一个可信增强的Docker容器--DockerGuard.

2.2 总体设计框架

总体设计框架如图 1所示，DockerGuard分为客户端和管理端.管理端负责提供管理界面给管理员，管理界面包括定制进程监控和网络监控的白名单的接口以及每个客户端的可信状态的监视窗口.而客户端则包括由文件系统度量、进程监控、网络监控三大功能构成的安全防护模块，并采用信任链的思想，由TPM芯片作为硬件支持，对Docker进行度量与细粒度的监控，构建一个安全加固的Docker可信容器.

图 1 DockerGuard系统框架 Figure 1 DockerGuard framework
图选项

信任链结构如图 2所示，以TPM芯片为起点，利用TGrub实现安全启动，并在TGrub中实现对Docker可执行文件以及进程度量模块文件、文件度量模块的度量，在Docker启动后，文件系统度量模块和进程监控模块相继启动，整个系统启动完毕，开始工作.

图 2 信任链 Figure 2 Extend the trusted chain to Docker
图选项

1) 文件系统监控模块

文件系统监控模块包括镜像度量和容器度量两个部分.

镜像度量：当Docker执行pull、commit、load以及import操作中的任意一个，将触发文件度量模块对生成的新镜像进行度量，并将度量结果作为基准值.

容器度量：在容器被创建时，首先对容器依赖的镜像文件系统 (rootfs) 进行度量，判断可信后允许容器创建并运行，在容器被创建后，对容器的文件系统进行监控，循环度量，确保容器运行过程中可信[16].

2) 进程监控模块

在容器被创建后，系统根据用户设置的白名单对容器内部进程实施监控，一旦出现非法进程立即拦截并通知管理员.

3) 网络监控模块

网络监控模块根据用户设置的白名单对IP及端口做出限制，只允许容器与指定IP的主机通信，并只开放指定的容器端口.

3 系统实现 3.1 文件度量模块

Docker的文件系统采用了分层的概念.其中镜像是已经被封装好的“层的集合”[17].在各类镜像中，Base image比较特殊.它是纯净的Linux发行版镜像，只包含rootfs，即Linux文件系统.需要说明的是，一个完整的rootfs不一定只是一层，它可能是由多层共同组成的.在其他非Base image的镜像中除rootfs外，还存在其他一些层和元数据 (Metadata)，元数据中存储着镜像的相关信息，例如镜像id、创建时间等.这些层和元数据共同构成了镜像[18].

Docker中有关镜像下载/加载的操作有pull, commit, load和import.pull操作是从Registry下载镜像至本地，commit操作是将正在运行的容器封装成镜像，load和import操作都是从一个tar包提取镜像到本地[19].Docker在提取镜像的时候，首先是将它的每一层都提取到相应的目录下，然后再将每层的大小及元数据提取到相应目录下，最后将层的依赖关系 (该层的所有父层) 写入指定文件中.

由此看出，在Docker中，每一层的数据包括文件系统、元数据、层大小以及层间依赖关系表，分别对应的目录为/docker/aufs/diff/id、/docker/graph/id和/docker/aufs/layers/id.这些就是文件度量模块对镜像和容器度量的内容.

以镜像为例说明文件系统度量模块的工作流程.镜像下载到本地后，模块使用SHA-1算法分别计算得到镜像的各部分哈希值并连接起来再进行一次SHA-1计算得到最后的哈希值.将此哈希值作为基准值，利用TPM的bind命令将哈希值加密为512位密文存入数据库中.DockerGuard接收到用户发出的启动容器命令时，首先从数据库中读出加密的基准值，用TPM进行解密得到基准值；然后再重计算镜像的哈希值，作为度量值；将度量值与基准值进行对比，若比对成功则启动容器，否则将弹框警告提示管理员，提示镜像已被损坏，并且不启动容器.当镜像被删除时，同时也会删除数据库中对应的基准值.通过以上操作就可以确保容器是从一个安全的可信的没有被篡改的镜像中启动的.

3.2 进程监控模块

系统调用是嵌入在内核中的函数，可以被系统的每个操作使用，对应用户和内核之间的转换.在用户空间打开一个文件对应内核空间的sys_open系统调用.Docker容器内所有的进程都是通过调用动态库或打开程序文件来创建进程然后执行进程来实现.因此可以通过hook sys_open () 的方法来拦截进程的产生和实现.

在3.x版本以上的Linux内核中，sys_call_table的地址在sys_close和loops_per_jiffy中间.又因为sys_call_table是只读的，所以可以通过在sys_close和loops_per_jiffy之间的地址遍历来寻找sys_call_table的入口地址[20].sys_call_table分配表的内存属性为只读，因此，首先要修改CR0寄存器的WP位，使只读属性失效以清除对应地址的写保护.CR0中含有控制处理器操作模式和状态的系统控制标志.当16位的WP位为1时，为只读，所以需要在用set_memory_rw将sys_call_table变为可写之前将wp位变为0.并且在完成操作后，恢复CR0的值.用my_sys_open () 替换原始sys_open系统调用.

为了对拦截的进程进行处理，设置了白名单功能.白名单中保存了容器id和该容器中信任的进程名称.用户可以通过proc文件来在用户态和内核态之间交互.用户通过该proc文件更新whiteList中的内容，利用my_sys_open () 灵活的限制进程.当被拦截的进程不在白名单中时，该进程将会被杀掉.

3.3 网络监控模块

使用了Iptables技术来实现对Docker网络通信的细粒度控制.通过编写Iptables规则，并使规则生效来限制容器通信的IP和端口.每一个容器都有一张IP白名单，该名单上的IP是允许连接的，除此之外任何地址都不允许连接.

实现方式：创建IP规则文件，将白名单上的IP地址补全成规则，分别写入INPUT链和OUTPUT链，最后一条写入REJECT ALL.当新创建一个容器时，首先检查规则文件的最后一条是否为REJECT ALL，若是则删除该条规则，添加新规则，最后仍然写入REJECT ALL.当有容器被销毁时，检查规则文件，对与该容器有关的规则全部删除.

规则补全：首先需要指定填充的表，如Filter，依次在OUTPUT链与INPUT链中添加规则，OUTPUT链中的目的地址为白名单中的IP地址，同理INPUT链中的源地址也为白名单中的IP地址，这些规则的ACTION均为accept，表示容器与这些IP地址通信时，主机无条件允许；同时，由于容器网络连接方式的特殊性，还需要填充NAT表，需要在PREROUTING链和POSTROUTING链中添加规则，这两条链分别代表DNAT变化和SNAT变换.当外界主动连接容器时，需要做DNAT变换，所以需要添加规则，使数据包能够发送到容器内部.同理容器主动连接外部时，需要做SNAT变换，同样要添加规则.而容器间通信则不需要NAT变换，由于容器间通信均发生在本地，且通过Docker0网桥实现，所以需要修改Filter表中的FORWARD链，通过Docker0网桥将数据包从一个容器转发至另一个容器.在上述各规则链填写完成后，都要在最后加上一条DROP ALL或REJECT ALL的规则，代表着除了符合上述规则的情况允许通信，其他数据包均丢弃.如此一来，便可以做到只允许容器与指定主机、容器进行通信.

4 实验

为了验证上述基于Docker实现的安全加固设计能否有效地解决Docker镜像和容器中存在的文件篡改和网络通信问题，我们设计了对Docker的容器、进程等方面进行攻击的实验，并对Docker中的完整性度量进行性能分析.

4.1 实验环境

采用如表 1实验配置.

表1 实验环境 Table 1 Testing environment
实验设备 型号
CPU Intel core i3
内存 2.9GB DDR3
硬盘 500GB SATA
TPM芯片 Infineon V1.2
系统版本 Ubuntu14.04-64bit
内核版本 3.13.0
Docker版本 1.6.0
TSS协议栈 trousers-0.3.13
表选项
4.2 功能测试

功能测试是为了评估本文中所提方案是否能对容器的文件系统、进程和网络通信进行综合性保护.

4.2.1 文件度量模块测试

在文件系统度量模块的试验中，通过对系统中关键文件进行修改来说明本文提到的方案的有效性.攻击者通过修改系统中的关键文件来篡改关键数据.实验结果如图 3和图 4所示.图 3是攻击之前采用本文的度量机制对关键文件所在层进行度量得到的基准值.图 4是攻击之后的情形.攻击者修改成功后该层的度量值也发生改变.

图 3 攻击前度量值图 Figure 3 The measurement before being attacked
图选项
图 4 攻击后度量值图 Figure 4 The measurement after being attacked
图选项
4.2.2 进程监控模块测试

在进程监控模块的试验中，采用运行白名单以外的敏感进程来说明进程监控模块的时效性和准确性.将ls进程写入白名单，在容器中运行ls命令和ps、md5sum命令.如图 5，可以看出ls命令正常运行，而ps和md5sum命令则无法运行.

图 5 进程监控测试图 Figure 5 Process monitoring test
图选项
4.2.3 网络通信模块测试

在网络通信的测试中，通过测试在设定网络通信白名单前后两个容器能否互相通信来说明网络通信模块的准确性.

首先创建一个容器，其IP为172.17.0.1.针对该容器，输入白名单，即该名单上的IP允许通信，其他数据包一律丢弃.在IP为172.17.0.1的容器中执行ping 172.17.0.2，可以通信，因为该IP在白名单中.在IP为172.17.0.1的容器中执行ping 192.168.1.102，不可以通信，因为该IP不在白名单中.

4.3 性能测试

在性能测试中针对DockerGuard对主机的影响和对容器运行的影响进行了三项测试.一是对DockerGuard运行前后磁盘读写速度进行了比对，二是对文件系统度量模块的度量速度进行了计算，三是对容器启动时间进行了测试.

4.3.1 磁盘读写速度测试

运行前磁盘的读写速度是62.5 MB /s，运行DockerGuard后测试得到DockerGuard占用了25%的磁盘读写速度，即16.1 MB/s.这是可以接受的.

4.3.2 文件度量速度测试

首先对7个大小不同的容器进行了多次文件度量测试，得到这7个容器的度量时间，然后对测量数据求平均值得出平均度量时间，再计算得出文件度量模块的度量速度，如表 2所示.因为对容器文件系统的度量操作中包括了大量文件操作，因此当容器文件系统增大时，度量的时间开销逐渐增大，而度量速度增长缓慢.

表2 文件系统度量时间开销 Table 2 The time cost of measuring filesystem
size/MB t/ms v/MB·s-1
7.8 690 11.3
18.2 1 478 12.3
124.8 7 231 17.3
128.6 7 436 17.3
225.4 14 088 16.0
310.1 17 214 18.0
表选项
4.3.3 容器启动时间测试

对文件系统监控模块启用前后的容器的启动时间进行了测试.测试数据如图 6，我们对8个容器进行了对比测试，左侧实心条是未启动文件系统监控模块时容器的启动时间，右侧空心条是启动了文件系统监控模块后容器的启动时间.8个容器的大小从左往右逐步增大.容器越大，所需启动时间越长，文件系统监控模块对容器的启动时间的影响越大.文件系统监控模块对容器的启动时间的影响在20%左右.

图 6 可信加固前后时间开销对比 Figure 6 Time cost before and after being trusted protection
图选项
5 结论

Docker作为时下最热门的轻量型虚拟化容器系统，其不完备的隔离性使得Docker面临巨大的安全挑战.本论文针对Docker目前存在的容器及镜像被篡改、容器的恶意进程及非授权通信问题，提出了一种基于Docker的容器可信加固方法.该方法利用可信计算技术、信任链技术、Hook技术等构造了一条从硬件到容器内部进程和文件的信任链，同时增加了包括进程监控、文件系统度量、网络监控三大功能于一体的安全防护模块，从而全方位对Docker进行度量与细粒度的监控，构建了一个安全加固的Docker可信容器系统-DockerGuard.最后基于开源软件Docker1.6.0进行了系统测试和评估，测试结果表明，DockerGuard可以抵御镜像篡改攻击，同时能够限制容器的网络通信行为并监控容器内部进程，以较小的性能开销确保容器的可信启动和可信运行.

参考文献
[1] Docker.What is Docker[EB/OL].[2016-08-15].http://www.docker.com/whatisdocker.
[2] MERKEL D. Docker:Lightweight linux containers for consistent development and deployment[J]. Linux Journal, 2014, 2014(239) : 2.
[3] 汪恺, 张功萱, 周秀敏. 基于容器虚拟化技术研究[J]. 计算机技术与发展, 2015(8) : 138–141. WANG K, ZHANG G X, ZHOU X M. Research on virtualization technology based on container[J]. The Computer Technology and Development, 2015(8) : 138–141(Ch).
[4] SOLTESZ S, TZL H, FIUCZYNSKI M E, et al. Container-based operating system virtualization:A scalable, high-performance alternative to hypervisors[J]. Acm Sigops Operating Systems Review, 2007, 41(3) : 275–287. DOI:10.1145/1272998
[5] CALARCO G, CASONI M. On the effectiveness of Linux containers for network virtualization[J]. Simulation Modelling Practice & Theory, 2013, 31 : 169–185.
[6] XAVIER M G, NEVES M V, ROSSI F D, et al.Performance Evaluation of Container-based Virtualization for High Performance Computing Environments[DB/OL].[2016-08-12].http://ieeexplore.ieee.org/document/6498558/.
[7] SLOMINSKI A, MUTHUSAMY V, KHALAF R.Building a Multi-tenant Cloud Service from Legacy Code with Docker Containers[DB/OL].[2016-08-13].http://ieeexplore.ieee.org/document/7092950/.
[8] BACIS E, MUTTI S, CAPELLI S, et al.DockerPolicyModules:Mandatory Access Control for Docker Containers[DB/OL].[2016-09-12].http://ieeexplore.ieee.org/document/7346917/:IEEE, 2015:749-750.
[9] BIEDERMAN E W, NETWORX L.Multiple Instances of the Global Linux Namespaces[DB/OL].[2016-06-11].http://www.landley.net/kdocs/ols/2006/ols2006v1-pages-101-112.pdf.
[10] JUSTIN W.Introduction to Linux Control Groups (Cgroups)[EB/OL].[2016-09-15].https://sysadmincasts.com/episodes/14-introduction-to-linux-control-groups-cgroups.
[11] MICHAEL K.Capabilities-Overview of Linux Capabilities[EB/OL].[2016-09-11].http://www.man7.org/linux/man-pages/man7/capabilities.7.html.
[12] MORABITO R, KJÄLLMAN J, KOMU M.Hypervisors vs.Lightweight Virtualization:A Performance Comparison[DB/OL].[2016-09-12].http://ieeexplore.ieee.org/document/7092949/.
[13] WANG J C, CHENG W F, CHEN H C, et al.Benefit of Construct Information Security Environment Based on Lightweight Virtualization Technology[DB/OL].[2016-08-23].http://ieeexplore.ieee.org/document/7389695/.
[14] CVE.Common Vulnerabilities and Exposures:Docker[EB/OL].[2016-09-21].http://www.scap.org.cn/cve_list.php?keyword=docker&action=search.
[15] 林杰, 刘川意, 方滨兴. IVirt:基于虚拟机自省的运行环境完整性度量机制[J]. 计算机学报, 2015, 38(1) : 191–203. LIN J, LIU C Y, FANG B X. IVirt:Runtime environment integrity measurement based on virtual machine introspection[J]. The Chinese Journal of Computers, 2015, 38(1) : 191–203(Ch). DOI:10.3724/SP.J.1016.2015.00191
[16] 谭良, 徐志伟. 基于可信计算平台的信任链传递研究进展[J]. 计算机科学, 2008, 35(10) : 15–18. TAN L, XU Z W. Development of the transitive trusted chain based on TPM[J]. The Computer Science, 2008, 35(10) : 15–18(Ch).
[17] FELTER W, FERREIRA A, RAJAMONY R, et al.An Updated Performance Comparison of Virtual Machines and Linux Containers[DB/OL].[2016-09-21].http://ieeexplore.ieee.org/document/7095802/.
[18] BOETTIGER C. An introduction to Docker for reproducible research[J]. ACM SIGOPS Operating Systems Review, 2015, 49(1) : 71–79. DOI:10.1145/2723872
[19] 孙宏亮.Docker源码分析 (一):Docker架构[EB/OL].[2016-09-11].http://www.infoq.com/cn/articles/docker-source-code-analysis-part1/. SUN H L.The Analysis of Docker Source Code Part Ⅰ:The Architecture of Docker[EB/OL].[2016-09-18].http://www.infoq.com/cn/articles/docker-source-code-analysis-part1/(Ch).
[20] XU M, JIANG X, SANDHU R, et al.Towards a VMM-based usage control framework for OS kernel integrity protection[C]//Proceedings of the 12th ACM Symposium on Access Control Models and Technologies.New York:ACM, 2007:71-80.