tags: container,方法论

容器安全研究的三重境界

与其他形态的技术相比，容器安全的漏洞更聚集在设计层面，而非实现层面，准确得说，非编码层面。

编码层面的漏洞更容易发现，且更容易自动化发现，但这种“优势”不会一直存在。因此，必然将形成漏洞越来越难挖的局面。而对容器技术而言，这个时间点来得相当早。这使得深入容器安全显得不那么容易，使研究者沮丧，但这也会极大地锻炼安全研究者的思维能力。

一、四级安全性

如果我们作以下定义：

将理想状态的安全定义为“理想模型”
将实际设计的结果定义为“设计模型”
将真实实现的代码定义为“实现模型”

我们将会得到4个不同级别的安全性： $$ \begin{equation} \left\lbrace \begin{array}{lr} 理想模型 \newline 设计模型 \newline 实现模型 \newline 编码漏洞 \end{array} \right. \end{equation} $$

以及3个可供挖掘漏洞的空间：

1. 编码漏洞

该类问题通常与语言本身强相关，较为显著的包括C语言带来的内存安全类问题、PHP弱类型引发的问题等。各语言都有一些不同的、隐蔽的特性，如果开发者不能熟知这些特性，则可能会埋藏漏洞。

这类问题的发现手段多，包括Fuzz,代码审计等。呈现出的漏洞数量也相当可观。

2. 三种模型间的差距

分别分析出设计模型和实现模型，将二者对比，即可得出实现层面的漏洞
将设计模型与理想模型对比，则可得出设计层面的漏洞

二、三重境界

1. 设计漏洞

寻找设计层面的漏洞，我们需要回答两个问题

什么是容器的理想模型？
某容器相关的项目，当前的设计模型是什么样的

对于容器来说，问题2是容易回答的，oci有翔实的specification。

难点在于解答问题一，或者我们是否有已知的安全设计模式可以套上去？

我暂时没有发现有可以直接使用的方法论，也许我们可以自行总结一套。这方面，后续我可以尝试用很长一个篇幅解答。

2. 实现漏洞

我们将追求放低至发现实现层面的漏洞，需要做的事情就简单多了

熟读oci specification
走读容器相关项目的代码

看，简单多了——至少是可执行的！

3. 编码漏洞

开篇即谈到了，容器安全的漏洞更聚集于非编码层面。但这个论述的对象主要是针对容器相关产品自身而言的，但如果将范围扩大至容器生态链呢？

例如

docker所调用的各组件，甚至各LSM模块
由各云厂商以开源形式贡献至k8s的CNI
…

这样看，我们还是有希望在此层面挖掘相关漏洞的，但可能需要将挖掘范围扩大、将漏洞挖掘的方法进行微调，以适应于发现容器类漏洞。

三、结语

对容器来说，少有编码层面的漏洞可以挖，没有办法；对其他类型的技术栈来说，现在编码层面还有很大的研究空间，但已经有这种趋势，也应该尽早布局。

如果安全也有修仙一样的等级的话，挖掘编码层漏洞的集大成者就像是斗宗强者。当然很厉害了，但是上层似乎还有更广阔的空间。

(一个斗之气一段的臆想 T_T)