当容器运行时（Container Runtime）的标准被提出以后，Red Hat 的一些人开始想他们可以构建一个更简单的运行时，而且这个运行时仅仅为 Kubernetes 所用。这样就有了 skunkworks项目，最后定名为 CRI-O， 它实现了一个最小的 CRI 接口。在 2017 Kubecon Austin 的一个演讲中， Walsh 解释说， ”CRI-O 被设计为比其他的方案都要小，遵从 Unix 只做一件事并把它做好的设计哲学，实现组件重用“。

根据 Red Hat 的 CRI-O 开发者 Mrunal Patel 在研究里面说的， 最开始 Red Hat 在 2016 年底为它的 OpenShift 平台启动了这个项目，同时项目也得到了 Intel 和 SUSE 的支持。CRI-O 与 CRI 规范兼容，并且与 OCI 和 Docker 镜像的格式也兼容。它也支持校验镜像的 GPG 签名。 它使用容器网络接口 Container Network Interface（CNI）处理网络，以便任何兼容 CNI 的网络插件可与该项目一起使用，OpenShift 也用它来做软件定义存储层。 它支持多个 CoW 文件系统，比如常见的 overlay，aufs，也支持不太常见的 Btrfs。

CRI-O 允许你直接从 Kubernetes 运行容器，而不需要任何不必要的代码或工具。只要容器符合 OCI 标准，CRI-O 就可以运行它，去除外来的工具，并让容器做其擅长的事情：加速你的新一代原生云程序。

CRI-O 最出名的特点是它支持“受信容器”和“非受信容器”的混合工作负载。比如，CRI-O 可以使用 Clear Containers 做强隔离，这样在多租户配置或者运行非信任代码时很有用。这个功能如何集成进 Kubernetes现在还不太清楚，Kubernetes 现在认为所有的后端都是一样的。

当 Kubernetes 需要运行容器时，它会与 CRI-O 进行通信，CRI-O 守护程序与 runc（或另一个符合 OCI 标准的运行时）一起启动容器。当 Kubernetes 需要停止容器时，CRI-O 会来处理，它只是在幕后管理 Linux 容器，以便用户不需要担心这个关键的容器编排。

CRI-O 有一个有趣的架构（见下图），它重用了很多基础组件，下面我们来看一下各个组件的功能及工作流程。

来自：https://www.crowdstrike.com/blog/cr8escape-new-vulnerability-discovered-in-cri-o-container-engine-cve-2022-0811/

从这个commit开始，CRI-O用Pinns给Pod设置内核参数，Pinns最常见的调用方式如下

所以恶意用户可以使用+或者=字符传入sysctl值，从而通过pinns设置额外的内核设置

判断是否受到影响：run crio —version

随后查看node 一定要是Ready

我们获取其中的upperdir就是从内核角度到容器根目录的路径

在创建环境的时候我们的启动命令如下

但是在Ubuntu虚拟机中，我们的启动命令如下

这里的--driver·docker，那么此时我们进入到pods中，使用mount，就不会有/var/lib/containers/storage/overlay/这个路径，而是/var/lib/docker/overlay2/这里并不知道具体的原因，只是在尝试后的发现，所以如果出现这种情况，换成Vmware Driver即可

注意：在Linux下是没有Vmware Driver的，所以只能是MacOs，或者Windows，当然如果有更好的，欢迎交流，自己搭建环境也可以

一定要给上权限这里建议直接

再创建一个ouput文本放在根目录即可

创建pod

这里创建之后并不会显示Running运行

随后我们再查看output就可以发现，成功执行了我们想要的命令

也就是写在UzJu.sh中的

https://blog.csdn.net/ccy19910925/article/details/118386726

https://zhuanlan.zhihu.com/p/334766611

https://www.crowdstrike.com/blog/cr8escape-new-vulnerability-discovered-in-cri-o-container-engine-cve-2022-0811/

https://linux.cn/article-9015-1.html

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课