1 引言

近年来Docker技术在开发者社区迅速升温, Docker具有高移动性和可扩展性, 以简便的方式确保运行环境一致. 虚拟化技术的开发和使用呈爆炸式增长, 潜在的镜像安全问题也接踵而至. 如用户可以在Docker hub或其他镜像库中随意上传和下载任何镜像文件^[1], 但据绿盟2018年的研究显示目前Docker hub上的76%镜像都存在安全风险. 镜像是容器运行的基础, 其安全极大程度影响容器安全, 镜像安全与用户的财产安全紧密相关, 而针对Docker镜像安全的研究还存在较大欠缺, 高效且安全的可信镜像源检测需求也逐步增加, 对镜像的安全检测工作迫在眉睫.

镜像文件包含高危漏洞、恶意代码或因本地镜像仓库缺乏安全防护导致镜像文件篡改等现象, 会导致容器逃逸、拒绝服务攻击^[2]等安全问题的产生, 因此镜像安全是保证可信容器的重要关注点. 本文提出一种可信镜像源检测模型, 它验证本地镜像是否被篡改并检测镜像漏洞, 输出镜像安全评估结果. 本文的主要贡献如下:

(1) 分析Docker hub云存储库中镜像分布情况, 建立涵盖官方镜像、验证镜像及社区镜像的父镜像数据集, 对其进行漏洞扫描构建父镜像漏洞数据库.

(2) 构建基准值数据库, 利用vTCM可信密码模块加密存储镜像基准值, 保证镜像从下载、本地存储、漏洞扫描至最终镜像运行过程中不被篡改.

(3) 扩展Clair镜像扫描器, 将父镜像漏洞数据库用于镜像漏洞扫描过程, 通过依赖关系避免重复扫描, 结合文件度量、漏洞扫描信息与自定义阈值对比从而判别可信镜像.

2 相关工作

本节概述Docker镜像安全工作研究现状及Docker镜像文件存储原理.

2.1 研究现状

Docker自2013年面世至今有许多前辈为其安全问题作出贡献, 他们多将Linux容器防护技术运用至Docker, 如Amith等^[3]将Linux安全模块LSM与Docker进行交互以提高Docker安全性; Jian等^[4]提出一种基于命名空间状态的防御方法, 检测异常进程防止Docker容器逃逸; Loukidis-Andreou等^[5]提出一种全自动化容器安全增强机制Docker-sec, 利用创建容器时配置文件访问规则及容器运行时附加规则限制非授权容器进程通信, 保护容器免受伤害. 吉晨等^[6]将可信安全容器机制用于容器环境, 保护容器的数据安全问题. 上述对Docker安全的分析和研究解决了容器逃逸、拒绝服务攻击等问题, 在一定程度上提升了Docker使用安全性, 但都从容器角度防护忽略了Docker镜像的安全检测问题.

目前国内外对云环境下容器镜像安全研究较少, Jain等^[7]介绍了现存镜像扫描器, 如Anchroe利用Syft模块生成软件安装包清单, Grppe模块完成对容器镜像的扫描, 从而对容器镜像进行检查、分析和认证. Dcoker scan扫描网络并尝试定位远程注册表信息、镜像中的敏感信息进行安全审查; Brady等^[8]利用多阶段持续集成和持续部署技术来评估Docker镜像的安全性, 并在Clair基础上使用AWS环境搭建动态API扫描器实现镜像检测. Kwon等^[9]提出镜像漏洞诊断系统DIVDS, 利用IVD模块检测Docker镜像中潜存的漏洞, 使用IVE模块计算镜像漏洞分数, 通过检测分数决定是否允许使用该镜像建立可靠的Docker容器运行环境. 王娟等^[10]提取Roofts文件详细信息, 计算哈希值将其连接再次进行哈希运算使用TPM可信计算平台bind命令加密后保存. 在这种方式下若文件被篡改无法具体到某一个镜像, 而需销毁所有镜像, 且使用TPM芯片作为可信根对硬件环境要求较高.

综上, 现存镜像扫描框架均未考虑本地镜像文件的篡改风险, 且每次扫描镜像时从高到低依次扫描镜像层, 存在重复扫描导致扫描速度缓慢. 本文提出DTDIS模型预先构建基准值数据库, 通过度量保证所用镜像未被篡改; 结合父子依赖构建父镜像漏洞数据库, 利用父镜像漏洞数据库扩展Clair避免重复扫描根据扫描结果, 最终判断镜像源是否可信.

2.2 Docker 镜像

Docker镜像有两种创建方式, 一是使用Docker commit将正在运行的容器中所有已安装应用和配置文件等打包为新的镜像, 二是使用Dockerfile将所需数据库、资源、程序、配置文件、配置参数等打包装入镜像当中. Docker镜像生成时可利用已有镜像(父镜像)生成新镜像, 其中父镜像可以是Docker官方或其他官方所制作的基础镜像, 或为在基础镜像基础上制作的普通镜像.

镜像创建成功后可上传到Docker公司运行维护的镜像云存储库Docker hub中, 当需要某个本地不存在镜像时通过Docker引擎从云存储库中拉取, 下载到本地后存储镜像Roofts等文件, 镜像启动时在本地文件上添加读写层则变为容器container. Docker镜像生命周期如图1所示.

镜像文件是一个特殊的文件系统, 其中包含代码、系统环境、数据库和配置文件等软件运行所需的所有内容. 镜像由4部分组成: manifest文件、镜像层文件、镜像配置文件、镜像索引序列号(可选). 当需要某个镜像时使用Docker pull命令进行拉取, 拉取具体步骤如下:

1)下载manifest文件:

$ {\textit{manifest}} = {\textit{manSvc}}.Get(tag) \tag{1}$

(2-1)

2)读取digest摘要:

$ digest = {{\textit{schema}}2{\textit{Manifest}}}(ref, {\textit{mfst}}) \tag{2}$

(2-2)

3)下载镜像配置文件:

$ con f ig J son = schema2Mani f est{Im} ageC on f ig(imageDigest) \tag{3}$

(2-3)

4)使用加密存储镜像文件:

$ imageID = {\textit{SHA}}256(digest.FormBytes(data)) \tag{4}$

(2-4)

用户输入镜像名称和标签(默认latest)至云存储库, 在manifests列表中解析获得对应manifest, 读取digest数字摘要,digest是镜像manifest经SHA256加密得到的摘要. 若某镜像层已存在直接指向本地文件, 不存在则向云存储库发送请求下载镜像配置文件和层文件, 镜像层下载完成后保存在本地仓库.

Docker镜像按照配置文件中指定顺序分层堆叠, 利用联合文件技术将不同的镜像层整合为一个文件系统^[11]. 镜像层可共享, 为防止文件被修改, 引入写时复制机制(copy on write, COW)构建镜像. Docker镜像文件由“层”堆砌而成, 下层存放多个只读层文件, 当容器启动时添加一个轻量可重用读写层在顶层^[12], 容器对文件所做的任何操作都存储在该读写层中, 镜像运行时在静态文件上添加一个可读写的容器层, Python镜像分层示意如图2所示.

3 DTDIS模型

本节介绍DTDIS模型架构及具体工作流程.

3.1 模型架构

DTDIS模型由文件度量模块和漏洞扫描模块组成, 用户使用Docker pull命令从Docker hub中拉取Docker镜像, Docker引擎下载完成后存储到本地. 文件度量模块负责首次加载镜像时, 计算基准值并将哈希值等相关信息经vTCM加密存储后存入基准值数据库, 容器运行前再次进行文件度量并输出度量信息. 漏洞扫描模块利用父镜像漏洞数据库避免重复扫描, 对比所设置CVE数据库漏洞数据输出镜像漏洞信息, 最终结合漏洞信息、度量信息对镜像计算镜像可信评分判定镜像是否可信, DTDIS模型架构图如图3所示.

3.2 工作流程

图4展示DTDIS工作流程, 具体步骤可概括为以下:

1)用户使用Docker pull [image name]命令从Docker hub云仓库请求下载父镜像数据集名单中Docker镜像.

2) Docker引擎解析Docker pull命令, Docker hub匹配成功后允许下载执行, 镜像下载完成保存在本地镜像仓库.

3)对于步骤2)下载的镜像使用Clair进行镜像扫描, 将扫描结果存入父镜像漏洞数据库中.

4)用户使用Docker pull [image name]:[tag]从Docker hub云仓库请求所需Docker镜像.

5)重复步骤2).

6)将步骤5)获取的镜像加载至DTDIS, 若该镜像为初次加载则文件度量模块提取Roofts文件, 使用算法1对其进行加密存储.

7)对于步骤6)加载的镜像, 提取Roofts文件元数据依次判断镜像层是否存在于父镜像漏洞数据库, 若存在则直接获取漏洞信息.

8)若步骤7)发现镜像层在父镜像漏洞数据库未找到, 则使用算法2进行漏洞扫描, 与漏洞数据库中易受攻击软件包依次匹配, 输出漏洞信息.

9)运行镜像前使用文件度量模块对镜像进行度量, 得到度量信息.

10)使用式(1)对步骤9)所得度量信息与步骤7)或8)所得漏洞信息进行计算输出镜像可信分数image_score.

11)将阈值与步骤10)所得image_score进行比较后, 将可信镜像提供给用户.

4 DTDIS核心模块

本节介绍DTDIS模型核心, 文件度量模块和漏洞扫描模块实现细节.

4.1 文件度量模块

Docker使用3个文件存储镜像, repositories.json存储仓库名称、镜像版本号和镜像ID, imagedb存储镜像的元数据配置文件, layerdb存储镜像分层信息.

镜像分层存储, 按照由低到高的顺序存储在Roofts文件中, Layer.DiffID用来检测镜像层文件的完整性, 据式(6)为对镜像未压缩的元数据内容进行SHA256所得^[13]. 如图5所示Python镜像层Layer.DiffID值为119360…127bce等.

Docker内容寻址机制采用ChainID为索引ID, 每个ChainID都对应一个目录, 每个目录代表一个镜像层, 且该目录中包含一个parent文件存储其父层的ChainID. 如果当前层是最底层, 不存在父层镜像则使用式(7), 如果当前层存在父层镜像则使用式(8)计算.

$ {{{Im}}}ageID = {\textit{SHA}}256(ConfigJson) \tag{5}$

(4-1)

$ {Layer.{\textit{DiffID}} = {\textit{SHA}}256(Uncompressed\_layer\_data)} \tag{6}$

(4-2)

$ Layer.ChainID(Layer0) = Layer.{\textit{DiffID}}(Layer0) \tag{7}$

(4-3)

$ \begin{split} Layer.ChainID = & {\textit{SHA}}256hex(Layer.ChainID(layerN - 1))\\ &+“.”+{\textit{DiffID}}(layerN)) \end{split} \tag{8}$

(4-4)

本文使用Cube-vTCM运行在Linux内核中实现可信环境搭建, 使用分层哈希值存储逐一对应镜像层, 具体文件度量模块原理如算法1展示.

输入当前镜像的Roofts文件, R代表镜像文件的详细信息R={R[0], R[1], R[2], …, R[K]}, 其中K为镜像层数; R.layer_id代表当前镜像层ID; R.layer_chain_id代表当前镜像层的父镜像层id; R.image_pkg _name表示镜像内应用软件包名称; R.image_version代表镜像内应用软件包版本.

算法1. 文件度量算法

输入: 镜像Roofs文件R

输出: 镜像基准值result

1)　fori in range(0, K) do

　　　//获取层id

2)　　P1 = hashlib.sha1(R[i].layer_id).hexdigest()

　　　//获取寻址索引id

3)　　P2 = hashlib.sha1(R[i].layer_chain_id).hexdigest()

　　　//获取软件包名称

4)　　P3 = hashlib.sha1(R[i].image_pkg_name) .hexdigest()

　　　//获取软件包版本

5)　　P4 = hashlib.sha1(R[i].image_version).hexdigest()

6)　　str = P1 + P2 + P3 + P4

7)　　ref_value = hashlib.sha1()

8)　　result = ref_value.update(str).hexdigest()

9)　　result → vTCM //存储基准值

10)　endfor

文件度量模块存储基准值及镜像度量, 当镜像首次载入文件度量模块, 使用SHA-1算法对各镜像层进行散列运算, 连接后二次哈希运算所得值使用vTCM加密存储作为基准值存入数据库中, 漏洞扫描结束后进行文件度量.

4.2 漏洞扫描模块

基于父镜像构建新镜像虽减少文件存储空间、加快镜像构建速度, 但这种可重用性导致漏洞依赖传递, 若基础镜像中存在镜像漏洞会导致所有以它为基础的镜像也存在同样的安全问题. 本文利用这种依赖传递关系, 构建父镜像漏洞数据库避免重复扫描, 提取镜像文件元数据与CVE漏洞数据库信息进行对比, 算法2具体实现过程如下.

输入当前镜像的Roofts文件, 其表示方法同文件度量模块. DI代表数据库中存储的镜像层信息, DI={DI[0], DI[1],DI[2], …, DI[N]}, 其中N为镜像层数, 定义DI.layer_id代表镜像层ID; DI.layer_cve_number代表镜像内漏洞CVE唯一编号; DI[j].layer_cve_desc代表CVE漏洞描述信息.

漏洞扫描模块利用Clair的CVE数据库模块从乌班图CVE追踪器, Debian漏洞追踪器, 红帽安全数据集等公开CVE字典库定时收集漏洞, 更新漏洞数据库. 定义V代表CVE漏洞数据库中的存在漏洞软件包条目, V={V[0], V[1], V[2], …, V[M]}, 其中M代表数据库中漏洞的总数. 定义V.cve_number表示漏洞的CVE唯一编号; V.cve_description表示漏洞的详细描述; V.cve_pkg_name当前漏洞所属软件包名称; V.cve_pkg_version当前漏洞所属软件包版本.

算法2. 漏洞扫描算法

输入: 镜像Roofs文件R, 父镜像漏洞DI, CVE漏洞V

输出: 镜像漏洞信息vul_Info

1)　fori in range(0, K) do

2) 　　 for j in ranger(0,N) do

　　　　//判断是否存在父镜像信息

3) 　　　 if R[i].layer_chain_id ==DI[j].layer_id

4) 　 vul_Info[index]=DI[j].layer_cve_number, DI[j].layer_cve_ desc

5) 　　　 　 index++;//扫描所有镜像层

6) 　　 　 endif

7) 　 　 endfor

　　　　//匹配软件包名称及版本

8) 　 　 for t in range(0, M) do

9) 　　 　 if V[t].cve_pkg_name == R[i].image_pkg_name and　　　　　　 V[t].cve_p kg_version == R[i].image_version

10) 　　　 vul_Info [index] = V[t].cve_number, V[t].cve_des cription

11) 　　　 index++;

12) 　　 endif

13) 　 endfor

14) 　endfor

15) 　if index == 1 //判断是否存在漏洞信息

16) 　　vul_Info [index] = “The image has no vulnerabilities”

17) 　endif

18) 　Output vul_Info

19)　end

镜像经漏洞扫描后输出所包含的CVE漏洞详细信息, 结合文件度量信息根据式(9)计算对镜像进行可信评分, 其中 ${r}_{\rm sv}$ 为漏洞扫描模块所得镜像包含漏洞总数, ${w\_vul}_{\rm sv}$ 为表1中漏洞对应权重^[11], ${w\_dat}_{\rm sv}$ 为表2中包含漏洞的软件包最近更新时间权重, ${v}_{\rm init}$ 为文件度量模块数据库中存储的镜像初始基准值, ${v}_{\rm cur}$ 为镜像当前基准值, $w_{\rm ref}$ 为表3中文件度量权重.

$ imag{e_{\rm score}} = \sum\limits_{i = 1}^{{r_{\rm sv}}} {(w\_vu{l_{sv}} + w\_da{t_{\rm sv}})} + 100 \cdot ({v_{\rm init}} - {v_{\rm cur}}) \cdot {w_{\rm ref}} $

(5)

通过式(9)计算镜像可信得分, 因不同应用场景对安全程度规定不同, 故本模型采用自定义阈值θ, 将其与镜像可信得分比较, 根据式(10)比较阈值θ和 ${image}_{\rm score}$ , 若 ${image}_{\rm score}$ 高于θ则认为该镜像不可信, 根据式(11)比较阈值 ${image}_{\rm score}$ 和θ, 若 ${image}_{\rm score}$ 低于或等于θ则认为该镜像可信, 阈值θ可由用户设置.

$ \begin{split} imag{e_{\rm score}} =& \sum\limits_{i = 1}^{{r_{\rm sv}}} {(w\_vu{l_{\rm sv}} + w\_da{t_{sv}})} \\ &+ 100 \cdot ({v_{\rm init}} - {v_{\rm cur}}) \cdot {w_{\rm ref}} > \theta \end{split} $

(6)

$ \begin{split} imag{e_{\rm score}} =& \sum\limits_{i = 1}^{{r_{\rm sv}}} {(w\_vu{l_{\rm sv}} + w\_da{t_{\rm sv}})} \\ &+ 100 \cdot ({v_{\rm init}} - {v_{\rm cur}}) \cdot {w_{\rm ref}} \leqslant \theta \end{split} $

(7)

对于不同安全等级漏洞给予不同权重, 且保留白名单功能, 最终可信值计算时忽略白名单中所出现的CVE漏洞. CVE漏洞权重取值参考文献[11]与CVSS(安全漏洞评分系统)分数设定, 文献[9]指出镜像更新时间与安全程度呈正相关故表2权重取值如下, 文献[10]指出本地镜像文件被篡改具有安全的严重隐患, 故本文将镜像文件篡认作最高等级危急事件, 设置基准值权重为表3所示.

5 实验结果与分析

本节介绍DTDIS模型的实验结果与分析, 包括实验环境, 镜像集分布及功能架构等相关细节实现.

5.1 实验环境

Docker容器大多运行在云环境下, 本文使用阿里云ECS服务器CentOS 7系统, 利用Cube-vTCM搭建可信环境进行单机仿真实验, 具体实验环境如表4所示.

5.2 镜像数据集构建

截止到2021年12月Docker hub拥有约850万个镜像, 分别存储在官方仓库、验证仓库和社区仓库, 具体分布如表5所示.

本文的数据集涵盖官方、社区和验证3种镜像, 且为保证高效, 同一个存储库中的镜像只拉取最新更改版本, 有些许镜像在下载过程中存在未知错误无法使用:

1)如“mcr.microsoft.com/hpcacm”属于验证仓库镜像, 通过Docker hub可视化界面搜索可得, 但无法使用Docker pull命令完成下载任务, 抛出错误.

Pulling repository mcr.microsoft.com/hpcacm

Error: image hpcacm:latest not found

同样的错误出现在官方仓库共计9个镜像无法使用Docker pull命令下载.

2)如“Docker/cheers”属于官方仓库镜像, 因为其最新版本号不是latest需要指定版本号下载, 使用Docker pull命令拉取会抛出以下错误.

Trying to pull repository docker.io/ docker/cheers

manifest for docker.io/cheers:1atest not found

同样的错误出现在验证仓库中共计18个镜像无法使用Docker pull命令下载, 忽略这些镜像最终镜像数据集构成如表6.

参与Verified Publisher计划的用户所发布的镜像为验证镜像, 该仓库镜像未有详细分类. 最终父镜像集如表6所示, 使用762社区镜像、162官方镜像及8 620个验证镜像共9 544个镜像构成, 依次下载镜像从Roofs文件中提取元数据扫描后构建父镜像漏洞数据库.

5.3 实验结果与分析

由于镜像可信为相对概念, 在不同使用场景用户对镜像安全度要求不同, 故该模型采用用户自定义阈值判断镜像是否可信. 采取与文献[11]相同的阈值, 设置θ为200. 将CVE-2014-4210、CVE-2019-19814等100个高危漏洞放入镜像文件使其成为有毒镜像, 使用DTDIS模型进行检测结果如图6所示.

由图6可知Python镜像存储在本地后载入DTDIS模型, 利用vTCM加密存储后文件度量值为“9e3cb3d7…”, 因Python镜像文件与Linux镜像层部分重合, 且Linux镜像已存入父镜像漏洞数据库故“00e698ca…”, “5e1ae504…”等5个镜像层无需再次进行漏洞扫描, 表7展示部分镜像漏洞信息.

由表7可知Python:latest镜像中包含Linux、glibc等软件包, 软件包中含有危急漏洞CVE-2019-19814、高危漏洞CVE-2021-33574等, 通过CVE详细描述可获取漏洞详细信息. 漏洞扫描结束后将漏洞信息结合文件度量信息, 由图6最后一行所示, 经计算Python:latest镜像可信得分为490.6, 高于当前阈值θ, 则判定其是一个有毒镜像.

6 总结

本文提出DTDIS模型判断Docker镜像源是否可信, 该模型主要包括文件度量模块和漏洞扫描模块. 文件度量模块构建镜像基准值数据库, 使用vTCM进行加密、度量保证所用镜像未被篡改. 漏洞扫描模块在Clair镜像扫描器基础上开发, 构建父镜像漏洞数据库, 通过父子依赖避免CVE漏洞重复扫描, 并通过自定义阈值判断镜像源是否可信. 在云服务器验证DTDIS模型效果, 结果表明DTDIS模型可以在较短时间内分析镜像, 判断Docker镜像源是否可信, 确保用户使用可信镜像从而降低容器逃逸、信息泄露等安全危害发生. 本文只考虑镜像静态安全, 未来将结合动态安全分析技术进一步保证Docker容器的安全使用.