足球免费推荐

（www.zq68.vip）是国内最权威的足球赛事报道、预测平台。免费提供赛事直播,免费足球贴士,免费足球推介,免费专家贴士,免费足球推荐,最专业的足球心水网。

外洋平安研究员champtar[1]在一样平常使用中发现Kubernetes tmpfs挂载存在逃逸征象，研究后发现runC存在条件竞争破绽，可以导致挂载逃逸[2]。

关于条件竞争TOCTOU和一些linux文件基础知识可见这篇文章《初探文件路径条件竞争 - TOCTOU&CVE-2019-18276》[3]。

CVE-2021-30465在Redteam的研究者视角中对照鸡肋，由于需要K8S批量确立POD的权限。但在产物平安的视角恰恰相反，针对Caas（Container as a service）类产物，用户/租户拥有批量确立POD权限，行使挂载逃逸可打破租户距离离，同时读取Host层面某些敏感数据，危害性极大。

RunC简介

为了让容器生态加倍开放，Linux基金会提议OCI（Open Container Initiative），目的是尺度化容器花样和运行时[4]，其中一个主要产物就是CRI（Container Runtime Interface），抽象了容器运行时接口，使得上层调控容器加倍便捷。containerd和runC都是其中代表产物，从dockerd中再剥离出containerd[5]，向上提供rpc接口，再通过containerd去治理runC。containerd在初期也是直接对runC举行治理，但为领会决containerd举行升级等操作时会造成不能用的问题，containerd再拆出containerd-shim，自力对接runC。containerd从Runtime、Distribution、Bundle维度提供容器全生命周期的治理能力[6]，runC专注于Runtime。

容器装备挂载相关基础知识

Namespace

Namespace是linux控制系统资源的抽象层，将差其余历程放置入差其余Namespace将获得差其余资源视角，该项手艺是容器实现的基础[7]。

linux提供8种差其余Namespace以提供差异维度的隔离能力，划分是：

1. Cgroup

2. IPC

3. Network

4. Mount

5. PID

6. Time

7. User

8. UTS

其中，Cgroup和Mount Namespace是最常接触的，在容器挂载相关能力均通过Mount Namespace举行实现。Namespace的使用主要通过clone和unshare 两个方式实现，其中clone确立新历程时，标志位为CLONE_NEW*将会确立新的Namespace并将子历程放入该Namespace[8]，unshare方式将挪用历程放入差其余Namespace中[9]。

Mount Namespace

Linux中有一个很焦点的头脑，那就是一切皆文件。在该头脑下，Linux通过挂载对差异装备中的文件举行治理。在Linux中，每一个空目录/文件都可以成为挂载点并设置响应的属性。在Mount Namespace下，处在当前Namespace中的历程只对当前Namespace中的挂载点可见，通过

提供差异维度的数据。每个task（在Linux中，岂论是历程照样线程，在内核的视角都是一个task）都市指向一个Namesapce（存放在task→nsproxy中）[10]。

struct nsproxy {  
   atomic_t count;  
   struct uts_namespace *uts_ns;  
   struct ipc_namespace *ipc_ns;  
   struct mnt_namespace *mnt_ns;  
   struct pid_namespace *pid_ns;  
   struct net        *net_ns;
 };

但Mount Namespace的引入也带来了新的问题，由于Mount Namespace中的隔离性，当用户需要挂载一个新的磁盘使所有Namespace可见时，就需要在所有的Namespace中都举行一次挂载，很穷苦，于是2.6.15中引入了共享子树（Shared Subrees）。通过在差异挂载点设置差其余属性，使挂载事宜在差其余维度（peer group[11]）举行流传。现在支持以下四种流传类型，其中MS_SHARED和MS_SLAVE对照常见。

1. MS_SHARED

2. MS_PRIVATE

3. MS_SLAVE

4. MS_UNBINDABLE

在MS_SLAVE流传属性的挂载点下，父挂载点（Master）的流传事宜可以吸收，但子挂载点下（Slave）的挂载事宜不再流传，容器的Rootfs挂载即为该种类型，也就是说在容器中挂载的挂载动作是不影响宿主机的，保证了容器隔离。

RunC破绽挂载逻辑剖析

checkout到修复commit(0ca91f44f1664da834bc61115a849b56d22f595f)[12]的上一个版本commitc(01a56034f5ab0c1aa314377a499fe60a9c26b36)。

整体流程如下

U交所

U交所（www.usdt8.vip）,全球頂尖的USDT場外擔保交易平臺。

RunC通过下令runc create + runc start 或runc run启动一个容器，runc create主要分为两部门，一部门是准备容器历程的启动参数，与真正实行容器runc init历程举行交互，保证容器初始化顺遂举行；另外一部门是执行克隆出的runc init历程，加入种种namespace并初始化容器历程的执行环境。本文以第二部门为切入点举行剖析，从

libcontainer/standard_init_linux.go的linuxStandardInit.Init()最先，在其中挪用prepareRootfs，准备初始化rootfs并举行挂载。

在prepareRootfs 中，挪用 prepareRoot 设置初始挂载点，并设置挂载标志位为 unix.MS_SLAVE | unix.MS_REC ，厥后使用 mountToRootfs 对container.json中设置的挂载举行操作。

prepareRoot 中设置容器根目录挂载标志位为unix.MS_SLAVE | unix.MS_REC ，容器在初始的时刻会通过镜像中的容器尺度包（bundle）挂载根文件系统（BaseFS），在这里runC默认将挂载点（Propagation Type）设置为slave。由于当前已经处于容器的mount namespace中，以是当前\  为容器根路径。rootfsParentMountPrivate 函数确保上一层的挂载点是PRIVATE ，应该是出于防止逃逸的思量。

在mountToRootfs 中，针对差其余装备类型存在差其余处置逻辑。

在tmpfs的处置逻辑中，configs.EXT_COPYUP默以为1。

首先准备/tmp 目录，在prepareTmp 函数中将这个挂载点设置为 MS_PRIVATE ，再确立runctmpdir 路径，将目的路径复制到 tmpDir 中，最后将dest 路径挂载到tmpDir 中，且Propagation Type设置为MS_MOVE 。对于MS_MOVE ，官方说明[13]如下：

If mountflags contains the flag MS_MOVE (available since Linux 2.4.18), then move a subtree: source specifies an existing mount point and target specifies the new location to which that mount point is to be relocated. The move is atomic: at no point is the subtree unmounted.

当此时的dest 为一个symlink时，subtree将笼罩已存在挂载点。以是此处存在TOCTOU（Time-of-check to time-of-use），在SecureJoin 函数执行时，dest 为正常路径，当挂在发生时，dest 为symlink，导致逃逸发生。

结论

RunC为了防止在路径组合中的路径穿越破绽，引入了filepath-securejoin[14]作为符号链接过滤函数，但r在挂载时并未校验挂载的现实目的路径，从而导致存在TOCTOU条件竞争破绽。

从securejoin的Readme中也可看出这一点。

之以是能够乐成逃逸的另一缘故原由在于tmpfs[15]中为了实现copy-up功效[16]使用MS_MOVE[17]作为挂载标志，凭证runC作者的形貌只有在tmpfs情形才气够逃逸[18]。

在补丁中，可以看出在tmpfs的挂载逻辑中，增添了doTmpfsCopyUp 函数。

在其中使用WithProcfd 函数防止TOCTOU破绽的发生，所有的 securejoin.SecureJoin 移入WithProcfd举行统一处置。

WithProcfd 中使用/proc/self/fd/ ，确保打开的文件是securejoin.SecureJoin 后的文件。

破绽作者给出的POC中给出了一个很精妙的组织，行使了这个看似很难行使的条件竞争破绽。

首先，确立两个公共tmpfs的挂载，名称为test1、test2，在容器A中，将test1挂载到/test1路径，test2挂载到/test2路径，同时将/test2/test2指向/ 。在容器B中，将test1挂载到/test1路径，test2挂载到/test1/mntx路径和/test1/zzz路径。

在容器A启动后，将/test1/mnt-tmpx指向rootfs路径，且交流mnt和mnt-tmpx，且rootfs/test2/test2指向/（K8S中，统一个pod下的rootfs在一个路径，形如/var/lib/kubelet/pods/$MY_POD_UID/volumes/kubernetes.io~empty-dir ）。

以是当条件竞争挂载的时刻，即容器B启动时，挂载test2，

mount('/','rootfs/test1/zzz')  ，同时MS_MOVE 标志位将原有该挂载点的subtree移至新挂载点下，造成逃逸发生。

Linux在引入symlink的时刻并不存在平安风险，但随着时代的变迁（容器的引入），symlink确着实一定水平上确实容易造成容器逃逸的发生。[19]Linux在实验在差其余角度去解决这个问题，但现在还没有很完全的能够解决此风险。这里不禁让人想引用tk的一句话：

平安意识要有时代靠山。

作者以为随同容器场景愈发庞大，平安研究的逐渐深入，非Linux内核破绽导致的容器逃逸耐久来看还会有一个增进的趋势。