来复现一下这次的CVE-2021-3493

该漏洞是通过创建一个虚拟环境，在虚拟环境当中通过某软件赋予某文件高权限，由于程序检查不严密，该权限逃逸到现实环境中也生效。

overlayfs ：虚拟的，堆叠文件系统

capability：权限管理机制

namespace：一种命名空间

能把多个文件夹里的文件合并为到同一个文件夹当中，这么听起来这个文件系统好像挺鸡肋的，但是它支持了一个我们最喜欢用的软件：docker。docker里面分容器和镜像的概念，一个镜像可以派生出多个容器，跟虚拟机差不多，一个镜像可以创建多个虚拟机。容器分公有数据和私有数据，docker比虚拟机优势的一点就是docker中的公有数据所有容器共享，这样就能省磁盘空间，私有数据则可以各个容器独占，保证数据独立。docker的实现机制就是通过 overlayfs 文件系统实现的。

overlayfs 依赖并建立在其它的文件系统之上（例如ext4fs和xfs等等），并不直接参与磁盘空间结构的划分，仅仅将原来底层文件系统中不同的目录进行“合并”，然后向用户呈现。

其中lower dirA / lower dirB目录和upper dir目录为来自底层文件系统的不同目录，用户可以自行指定，内部包含了用户想要合并的文件和目录，merge dir目录为挂载点。当文件系统挂载后，在merge目录下将会同时看到来自各lower和upper目录下的内容，并且用户也无法（无需）感知这些文件分别哪些来自lower dir，哪些来自upper dir，用户看见的只是一个普通的文件系统根目录而已（lower dir可以有多个也可以只有一个）。

挂载一个overlay文件系统，可以通过mount -t overlay -o <options> overlay <mount point>来实现。

<mount point>是最终overlay的挂载点。

其中overlay的options有如下：

下面将lower和upper进行overlay，挂载到merge目录，临时workdir为work目录。

如下同样将lower和upper进行overlay到merge，但是merge为只读属性。

在使用如上mount进行overlayfs合并之后，遵循如下规则：

在docker当中，我们为了方便理解，假设只有三个目录：upper dir,lower dir和merge dir。我们的镜像处于lower dir当中，初始情况下，我们通过镜像创建出来一个容器，lower dir 中就是一个镜像，upper dir 中为空，我们创建多个容器得到的都是和镜像一模一样的系统。当我尝试查看容器中的某个文件，根据规则1，因为 upper dir 为空，我们看的的内容是 lower dir 中的内容，也就是镜像的内容；当我尝试修改容器中的文件内容时，根据规则5，lower dir 中的内容只读，因此拷贝一份到 upper dir 中，根据规则1，我们之后将只能看到该文件 upper dir 中的内容，修改完成会将结果保存在 upper dir 当中，之后再次修改这个文件，将只在upper dir 当中进行。但是在我们的视角当中，我们跟操作一个完整的操作系统并没有很大的区别。并且多个容器大部分数据是共享的，因此比较节省磁盘空间。

我们新建四个文件夹：upper，lower，work 和 merge。

mount 命令用于挂载操作，第一个 overlay 指定挂载类型为 overlay 第二个 overlay 指定挂载点，-o 选项指定上层目录，下层目录，工作目录，最后挂载到 merge 目录下。

挂载完成之后我们在 lower 和 upper 中分别创建 1.txt 和 2.txt。我们使用 ls -lR 来查看目录

我们可以发现， merge 目录中也出现了 1.txt 和 2.txt。

我们修改 upper 和 lower 中文件对应的内容，可以发现，merge 目录中也会有相同的改变，这非常符合 overlayfs 的规则。

我们尝试直接在 merge 目录中修改在 upper 目录中出现的文件再观察一下变化。

可以发现我们在 merge 目录中修改 upper 目录中出现的文件，对应也修改了 upper 目录的主体文件。

我们尝试在 merge 目录中修改只在 lower 目录出现的文件再观察一下变化。

我们发现，lower 目录中对应的 1.txt 并没有发生改变，反而是 upper 目录多了一个 1.txt 文件，并且内容与我们填写的一致。

那么这个 1.txt 就可以理解为docker中的镜像，2.txt 就是我容器中不同于镜像的文件。

首先介绍几个概念：uid，ruid，euid，suid。

标识用户身份， 比如常见的 root就是0，我们安装完操作系统获得的第一个账号就是1000，当登录完成之后，这个用户的ruid就是确定的了。

euid是用户的有效id，用于系统决定对系统资源的访问权限，通常情况下，euid=ruid。我们都知道：只有进程的创建者和root用户才有权利对该进程进行操作（kill，或者挂起，又或者是 fork）。于是，记录一个进程的创建者(也就是属主)就显得非常必要，进程的 uid 通常就是进程创建者的 uid，若创建者为另一个进程（fork），那么这个进程的 uid 会被继承，除非子进程被设置了 suid。

用于对外权限的开放。跟ruid及euid是用一个用户绑定不同，它是跟文件而不是跟用户绑定，在运行这个文件时，用户会暂时获得属主的身份。

进程运行之后，会获得和运行者一样的权限，它们同样受到了自身的权限访问控制。事实上这样的管理是比较安全的，我如果想自己无法直接访问这个文件，那么我通过创建进程访问文件同样会没有权限。但是如果这样管理则不能满足一些需要，比如密码文件 /etc/shadow，这个文件的权限是 r--------，属主和数组均为 root，那就意味着，除了 root 用户没有人可以查看或者修改这个文件，但是里面同时也存了我自己的密码，如果我不管怎样都获得不了 root 权限，那意味着我自己都修改不了我自己的密码，那这显然不太合理。于是乎就出现了 suid（Set User ID execution），我们都知道在 linux 当中，我们想修改自己的密码是使用 passwd 命令，那我们查看 passwd 的权限发现它被设置了 suid 选项。它允许我在执行这个程序的时候短暂地获得 root 权限，这个进程拥有 root 权限之后，我们就能修改 /etc/shadow 文件，修改完成之后，进程直接退出。

这么一看确实挺方便了，但是会带来很大的安全问题：假设， passwd 文件在编写的时候，存在漏洞，若在执行 passwd 的过程中，能通过漏洞创建一个 shell 进程，那么这个 shell 进程也会是 root 权限，简而言之，SUID 机制增大了系统的安全攻击面。

为了对 root 权限进行更细粒度的控制，实现按需授权，Linux 引入了另一种机制叫 capability。

Capabilities 机制是在 Linux 内核 2.2 之后引入的一个权限管理机制，原理就是把超级用户 root(uid=0) 的特权划分为不同的功能组，每个功能组都可以独立启用和禁用。其本质上就是将内核调用分门别类，具有相似功能的内核调用被分到同一组中。

这样一来，我权限检查就变成了：如果非 root 用户，那么检查进程是否有对应的操作权限，决定是否可以进行该操作。同样，这个权限可以在执行的时候赋予：根据进程创建者或者 setuid 获得，也可以从父进程继承。假如我给 nginx 可执行文件赋予了 CAP_NET_BIND_SERVICE capabilities ，那么它就能以普通用户的身份运行并监听一个1024以内的端口。

每一个进程，具有 5 个 capabilities 集合，每一个集合使用 64 位掩码来表示，显示为 16 进制格式。这 5 个 capabilities 集合分别是：

这5个集合的具体含义如下：

在进程执行时，该可执行文件的 Permitted 集合中的 capabilites 自动被加入到进程的 Permitted 集合中。进程可以通过系统调用 capset() 来从 Effective 或 Inheritable 集合中添加或删除 capability，前提是添加或删除的 capability 必须包含在 Permitted 集合中。

内核检查线程是否可以进行特权操作时，检查的对象便是 Effective 集合。如之前所说，Permitted 集合定义了上限，线程可以删除 Effective 集合中的某 capability，随后在需要时，再从 Permitted 集合中恢复该 capability，以此达到临时禁用 capability 的功能。

比如我可能一个程序可能中间需要用户来操作，但是呢，我不希望它有过高的权限，那么我在交给用户操作的时候，我把一些权限较高的capability 禁用了，如果用户通过漏洞获取持久权限那将也不能够获取较高的权限。

当执行exec() 系统调用时，能够被新的可执行文件继承的 capabilities，被包含在 Inheritable 集合中。这里需要说明一下，包含在该集合中的 capabilities 并不会自动继承给新的可执行文件，即不会添加到子进程的 Effective 集合或 Inheritable，它只会影响新线程的 Permitted 集合。

Bounding 集合，它定义了能被继承的权限的上限，是 Inheritable 集合的超集，如果某个 capability 不在 Bounding 集合中，即使它在 Permitted 集合中，该线程也不能将该 capability 添加到它的 Inheritable 集合中。

Bounding 集合的 capabilities 在执行 fork() 系统调用时会传递给子进程的 Bounding 集合，并且在执行 execve 系统调用后保持不变。

Linux 4.3 内核新增了一个 capabilities 集合叫 Ambient ，用来弥补 Inheritable 的不足。Ambient 具有如下特性：

文件的 capabilities 被保存在文件的扩展属性中。如果想修改这些属性，需要具有 CAP_SETFCAP 的 capability。文件与进程的 capabilities 共同决定了通过 execve() 运行该文件后的线程的 capabilities。

文件的 capabilities 功能，需要文件系统的支持。如果文件系统使用了 nouuid 选项进行挂载，那么文件的 capabilities 将会被忽略。

类似于进程的 capabilities，文件的 capabilities 包含了 3 个集合：

这3个集合的具体含义如下：

这个集合中包含的 capabilities，在文件被执行时，会与进程的 Bounding 集合计算交集，然后添加到该进程的 Permitted 集合中。

这个集合与线程的 Inheritable 集合的交集，会被添加到执行完 execve() 后的线程的 Permitted 集合中。

这不是一个集合，仅仅是一个标志位。如果设置开启，那么在执行完 execve() 后，线程 Permitted 集合中的 capabilities 会自动添加到它的 Effective 集合中。对于一些旧的可执行文件，由于其不会调用 capabilities 相关函数设置自身的 Effective 集合，所以可以将可执行文件的 Effective bit 开启，从而可以将 Permitted 集合中的 capabilities 自动添加到 Effective 集合中。

共40个

比如我们熟知的 ping 命令，它所用到的底层是使用 socket 实现的，而 socket 是 root 用户才有权限使用的。在 Ubuntu 18.04LTS 的发行版当中，我们看看它是怎么解决这个权限问题的。

它设置了 s 权限位，意味着我运行 ping 的时候， ping 这个 process uid 为 0，也就是 root 用户。

若我取消设置它的 s权限位，它将不再具有 ping 的功能。

原因就如上所示，底层的 socket 并不允许普通用户运行。

而当我把自己权限提升之后又能够使用 ping 命令了，是因为 root 用户执行读写和某些底层操作时不检查权限。

在这里我们只需要使用 setcap 命令将 ping 加上 socket 权限就可以让我们运行的时候获得 socket 权限，正常使用 ping 命令，这么做的好处就是假如我的 ping 命令有漏洞存在，那么当别人借着 ping 命令来提权我的计算机时会发现它获得的 shell 只拥有 socket 这么一个特权操作，其它的操作与普通用户并没有区别，这样极大地降低了安全风险，而如果我使用 s 权限位，那么别人通过这个获取漏洞之后将能直接获得 root 权限能操作计算机的一切资源。

在添加完权限之后，我们发现又可以使用 ping 命令了，这是因为我们通过 setcap 让 /bin/ping 重新拥有了 socket 权限。

在这个地方我们对 capability 也不再深入下去了。

引用一下 wiki 对 namespace 的定义

Namespaces are a feature of the Linux kernel that partitions kernel resources such that one set of processes sees one set of resources while another set of processes sees a different set of resources. The feature works by having the same namespace for a set of resources and processes, but those namespaces refer to distinct resources.

直观翻译就是

namespace 是 Linux 内核的一项特性，它可以对内核资源进行分区，使得一组进程可以看到一组资源；而另一组进程可以看到另一组不同的资源。该功能的原理是为一组资源和进程使用相同的 namespace，但是这些 namespace 实际上引用的是不同的资源。

简单来说 namespace 是由 Linux 内核提供的，用于进程间资源隔离的一种技术。将全局的系统资源包装在一个抽象里，让进程（看起来）拥有独立的全局资源实例。同时 Linux 也默认提供了多种 namespace，用于对多种不同资源进行隔离。

Linux 从 2.4 版本加入了 namespace 机制到 3.8 版本实现了 User namespace。

Cgroup namespace 是进程的 cgroups 的虚拟化视图，通过 /proc/[pid]/cgroup 和 /proc/[pid]/mountinfo 展示。

有了namespace之后，PID,IPC,Network等系统资源不再是全局性的，而是属于特定的Namespace。每个Namespace里面的资源对其他Namespace都是透明的。要创建新的Namespace，只需要在调用clone时指定相应的flag。

以上为自己搜集的资料整理，以下为自己个人解读。

电脑开机的时候，系统会创建7个 init 的 namespace，一个进程只能切必须属于七个特定不同的 namespace，那么这个就是我们默认的 namespace。使用 ls -l /proc/$$/ns 可以查看本进程的 namespace 在这里 $$ 变量表示自己的进程号。

在这之前我一直有一个疑问，就是为什么我普通用户 -map-root-user 会导致我没有 root 的操作权限而 root 用户创建的 namespace 即使是普通用户也有操作权限。比如如下两个例子。

unshare 命令用于取消子进程的共享 namespace，通过--user --map-root-user 选项可以新建一个 user namespace 并使新建进程的用户为 root 用户。

此时出现了 root 用户无法操作 /etc/shadow 的场面，但是我们无论是 id 还是 whoami 看上去都跟真的 root 一样，确没有操作权限，确实也是比较奇怪的。但是，又合情合理，因为我普通用户我不通过 su 或者是 sudo 命令去正常提权那都是利用漏洞。

然后再来看另一个例子

虽然看起来我是普通用户，但是实际上我有 root的权限。

因此我在这里一直不理解 namespace 的组织形式，直到我看到一篇博客上面画着树状图，我才猛然顿悟。

namespace 是树状图的一种形式，然后文件系统中在标记属主的时候会标记一个 namespace 字段，标识由哪一个 namespace 的用户创建的，然后再检查权限的时候若当前用户不属于当前 namespace 那么就会向上寻找，直到找到对应的 namespace，然后检查是谁创建的。然后对应的权限就是那个 namespace 的创建者的。如果是这样的话，那么就能解释通了，我之前疑惑的点不在于为什么我没有操作权限而是它怎么判断的我没有操作权限，因为没有操作权限属于正常现象，如果我的想法不对也请师傅们指正，这只是一个我认为比较合理能解释得通的解释。

我们先创建好 overlayfs 的那几个文件夹，准备挂载，然后在其中的 upper 目录中写上我们的 exp 并编译好。

exp 非常简单，就是 setuid 和 setgid 为 0，也就是 root。

然后我们再创建一个 user namepsace 和 mount namespace 。

在 ./merge 当中，我们为刚刚编译的 exp 设置 setuid 的权限。

然后再开一个终端，我们发现 upper 目录中的 exp 同样具有了 setuid 的权限，说明我们的权限逃逸成功了。

我们运行 exp 成功获得了真实的 root 权限。

首先我第一步呢，就是去求证了一下我上面的猜想是否正确，在 github 上找到对应的 namespace 的代码，这里不用管什么版本了，大体变化是不会很大的，我们先来看 user_namespace 结构体的定义：

我们很清楚地能看到里面的一个定义：user_namespace *parent，这里也能说明，它是存在父子关系的，和我们之前的猜测大体是一样的，并且会标注 owner 和 group，这里应该是创建这个 namespace 的属主和属组。我们同时也看到还有一个 level 变量，这里我大概猜测一下，是 namespace 的深度，也就是往后迭代了多少次，这个学过算法设计应该还是好理解的，我在建立树的时候，我们一般也会标记深度方便去查找，我猜测在这里我们需要的就是进行权限检查，如果 namespace 双方为父子关系，那么我们直接看父亲的权限即可，然而实际情况比较复杂，首先谁是父亲谁是儿子就很难判断，所以我跟上深度能很容易知道谁是父亲谁是儿子，如果不是父子关系，那么我们可以查 LCA 找到最近公共祖先，看看两个 namespace 的创建者权限如何。

我们找到对应的 user_namespace.c 文件，看看创建一个 namespace 的时候发生了什么。这里推荐给大家读内核代码的一些思路：大部分的代码都会写一个完全不带安全检查的函数，比如我创建一个 namespace，那么我们一定能找到只实现创建 namespace 的一个函数，这个函数通常会在进行了一系列安全检查之后才允许被调用，包括我们平时做一些网站开发之类的也一样，我们会写一个定向只做某些事情的接口，但是接口不会直接被调用而是会进行一系列安全检查，诸如非法数据判断和权限问题，我们默认传进去的参数都是合法的，它常规的三部曲就是：检查，执行，善后。那么言归正传，看到代码

参数应该是一个父进程，因为它在第一行写了 parent_ns=new->user_ns，parent_ns 我们很容易知道是父 namespace，而这里传进去的是一个 cred 结构体，结构体中有一个 user_ns 应该是 user_namespace。下面两行设置了 euid 和 egid，那么很清晰了，owner 和 group 就是创建这个 namespace 的属主和属组。

下面有一个如果父进程的 user namepsace 层数超过 32 那么直接 goto fail，那就是说这里不允许这棵树创建超过32的深度。

后面执行一个 inc_user_namespaces 函数并判断是否执行成功，我们往下深挖一下代码，这里因为代码比较短，就贴这里了。

不难看出来，这里应该只是分配一个 ucounts 结构体的内存，我猜测 ucounts 应该是 namespace 的衍生类，因为我们看到 inc_user_namespace 增加 user namespace 实际就是调用增加 ucounts 的一个方法，并且估计其它的 namespace 也需要通过这个调用来分配内存，并且我们观察枚举类也能发现有我们所有 namespace 的一个定义。

但是去看了 ucounts 结构体的定义发现里面就定义了一个 user_namespace 的指针和一个链表，队列，以及标识了一个 uid。这个 ucounts 可能只是一个用于做某些标记的东西，我们暂且不管把先。

后面有一个 current_chrooted 函数，我们同样看看它的定义：

根据注释以及关键的语句 chrooted = !path_equal(&fs_root, &ns_root); 我们大概也能猜测出来，它应该就是判断 namespace 的根目录是否于文件系统一致，一致才允许你创建这个 namespace。

然后在这里需要判断一下属主和数组是否映映射到了父 namespace 上。

后面的话基本上和我们复现的漏洞无关了，我们这么来了解了一下构成形式，namespace 确实是树状图形式，而且下面我们很清楚地能看到 ns->level=parent_ns->level+1。

这里我们来查看对应版本的代码，链接贴上。

先来看到 416 行，对 setxattr 函数进行分析，这里解释一下 setxattr 的一个名字由来（自己意淫的，非官方说法，经供参考），set 就是设置， x 其实它可以代表 extended 扩展的，attr 就是属性了，连起来就是设置扩展属性，这里的扩展属性就是指 capability。其实我感觉吧， x 好像能表示一切 ex 开头的单词，比如我们经常见到的三个权限位，用 x 标识 execute。

乍一看逻辑有点小复杂，主要是很多的宏定义和很多没见过的函数，也不太能够望文生义，于是我找到了Linux手册对于 setxattr 的说明：

setxattr() sets the value of the extended attribute identified by name and associated with the given path in the filesystem. The size argument specifies the size (in bytes) of value; a zero-length value is permitted.

貌似介绍的也比较笼统，还是靠自己试试吧。

flags & ~(XATTR_CREATE|XATTR_REPLACE)，这其实是很常见的掩码写法，差不多意思就是 flag 标志只在 create 和 replace 位上设置，如果设置了其它位则退出。

strncpy_from_user(kname, name, sizeof(kname)) 对传入的 name 参数进行拷贝，拷贝到了 kname 也就是内核栈当中。第一个判断应该是判断空字符串和防止溢出，因为如果 sizeof(kname) 字节都被占满了那么这个字符串还会跟下面连续的字符串相连，造成一些错误。

这里出现了我的知识盲区，这里也来解释一下，在内核里面，看见全大写字母的变量基本都不是变量，都是宏定义。而我实在不知道字符串常量有直接拼接的做法：

我还以为是宏定义的特殊写法呢，这里mark一下。

这里给出这些宏定义的最终结果

那么第一个 if 我们 duck 不必关心，我们主要关心第二个跟 capability 相关的分支。

我们具体逻辑也不进一步分析了，我们就看看这个函数给的注释：

This function will then take care to map the inode according to @mnt_userns before checking permissions.

我们也不难看出来，在检查权限之前就是会对文件系统和 user namespace 进行映射，这个函数叫 cap_convert_nscap，那其实就是对 capability 的 userns 进行一个映射了（应该是这个意思。

就是可能，它会在不同的 namespace 上嘛，比如这个文件夹是其中一个 user namespace 创建的，不可能我换一个 namespace 去检测权限也是相同的手法，肯定是要把权限映射一下的，映射到同一个 namespace 上才能进行权限检查。

经过一系列检查之后，走到了 vfs_setxattr，也就是虚拟文件系统的扩展属性设置。

第一条不深入挖下去了，就是判断有没有写的权限，然后上锁，防止发生竞争，然后进行 security_inode_setxattr 函数进行进一步的权限校验，最后执行 __vfs_setxattr_noperm 函数，它的后缀 noperm 就是还没有进行权限检查的 __vfs_setxattr 与我们之前说的分析思路是一致的。在这个函数里面有一个大 if 判断文件是否有权限，最终调用一个 __vfs_setxattr 去真实设置 xattr。

因此我们可以发现，在调用设置文件扩展属性时候，会有一系列的检查，比如你是否是 root，你对文件操作是否有权限之类的，因为即使你是 root 也得看看那个文件系统的权限是否归你所有，有可能是其它 user_namespace 的用户创建的，那么你有可能也是没有权限的，这个地方是不会出现越权行为的。

然后我们看到 overlayfs 的设置文件扩展属性。

其它的我们不看，我们解释比较容易理解的。

这个地方其实就是我们说的，如果文件在 lower 当中，那么拷贝一份到 upper 当中去，然后把新的文件节点指向 upper。

然后直接调用 vfs_setxattr 函数了，我们知道在 vfs_setxattr 之前有一个入口，也就是 setxattr 这个地方会有一个调用，调用 cap_convert_nscap 函数去检查 user namespace 是否一致。而这里直接调用 vfs_setxattr 这个函数就绕过了 namespace 的检查。

所以我们之前的利用步骤就是先创建了一个 namespace，然后挂载了一个 overlayfs，在 merge 文件夹中是我们创建的 fs namespace，因此我们创建的 root 用户对这个 fs namespace 有设置 capability 的操作权限，这个其实没有问题，因为我即使运行了这个 a.out 也不会有真正的 root 权限，有的只是我们创建的这个 user namespace 的 root 权限，而这个权限实际是 init 的 user 创建的，因此实际操作还是获得不了真实的 root，但是问题就是 overlayfs 的这个特性：我们修改了 merge 中的 a.out 会反向修改之前在 upper 中的 a.out，因此我们给它 setuid 的权限导致了 upper/a.out 也有 setuid 的权限，而 upper/a.out 是在实际的 init user namespace 创建的，因此它有了 init user namespace 的 setuid 权限。我们运行 upper/a.out 直接获取真实 root 权限。

这个其实我个人认为应该是 overlayfs 的问题，在修改的时候应该检查 user namespace 才对，但是它修改了 xattr.c 中的 vfs_setxattr 函数，这个函数重新用了一个 cap_convert_nscap 函数检查 namespace。

当然这样也能完成漏洞的修复，不过我认为在其它文件系统中这里检查了两次就比较没有必要，也是比较困惑的点吧，也可能防止其它文件系统调用这个函数也没有检查，大概是这样的。

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)