hierarchical protection domains---->分级保护环#

分级保护域（hierarchical protection domains）又被称作保护环，简称 Rings ，是一种将计算机不同的资源划分至不同权限的模型

在一些硬件或者微代码级别上提供不同特权态模式的 CPU 架构上，保护环通常都是硬件强制的。Rings 是从最高特权级（通常被叫作 0 级）到最低特权级（通常对应最大的数字）排列的

Intel 的 CPU 将权限分为四个等级：Ring0、Ring1、Ring2、Ring3，权限等级依次降低，现代操作系统模型中我们通常只会使用 ring0 和 ring3，对应操作系统内核与用户进程，即 CPU 在执行用户进程代码时处在 ring3 下

现在我们给【用户态】与【内核态】这两个概念下定义：

• 用户态：CPU 运行在 ring3 + 用户进程运行环境上下文。

• 内核态：CPU 运行在 ring0 + 内核代码运行环境上下文。

  而两者是可以切换的

状态切换#

CPU 在不同的特权级间进行切换主要有两个途径：

• 中断与异常（interrupt & exception）：当 CPU 收到一个中断 / 异常时，会切换到 ring0，并根据中断描述符表索引对应的中断处理代码以执行。
• 特权级相关指令：当 CPU 运行这些指令时会发生运行状态的改变，例如 iret 指令（ring0->ring3）或是 sysenter 指令（ring3->ring0）

基于这些特权级切换的方式，现代操作系统的开发者包装出了系统调用（syscall），作为由 “用户态” 切换到 “内核态” 的入口，从而执行内核代码来完成用户进程所需的一些功能。当用户进程想要请求更高权限的服务时，便需要通过由系统提供的应用接口，使用系统调用以陷入内核态，再由操作系统完成请求。

user space to kernel space （系统调用）#

当发生 系统调用，产生异常，外设产生中断 等事件时，会发生用户态到内核态的切换，进入到内核相对应的处理程序中进行处理。

系统调用是内核与用户通信的直接接口，因此我们主要关注用户空间比较常用的系统调用这一行为，其具体的过程为：

注意：当系统调用指令执行后，CPU 便进入内核态，以下操作在内核态完成。

1. 通过 swapgs 切换 GS 段寄存器，将 GS 寄存器值和一个特定位置的值进行交换，目的是保存 GS 值，同时将该位置的值作为内核执行时的 GS 值使用。
2. 将当前栈顶（用户空间栈顶）记录在 CPU 独占变量区域里，将 CPU 独占区域里记录的内核栈顶放入 rsp/esp。
3. 通过 push 保存各寄存器值，具体的 代码 如下:

1
 ENTRY(entry_SYSCALL_64)
2
 /* SWAPGS_UNSAFE_STACK是一个宏，x86直接定义为swapgs指令 */
3
 SWAPGS_UNSAFE_STACK
4

5
 /* 保存栈值，并设置内核栈 */
6
 movq %rsp, PER_CPU_VAR(rsp_scratch)
7
 movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp
8

9

10
/* 通过push保存寄存器值，形成一个pt_regs结构 */
11
/* Construct struct pt_regs on stack */
12
pushq  $__USER_DS      /* pt_regs->ss */
13
pushq  PER_CPU_VAR(rsp_scratch)  /* pt_regs->sp */
14
pushq  %r11             /* pt_regs->flags */
15
pushq  $__USER_CS      /* pt_regs->cs */
16
pushq  %rcx             /* pt_regs->ip */
17
pushq  %rax             /* pt_regs->orig_ax */
18
pushq  %rdi             /* pt_regs->di */
19
pushq  %rsi             /* pt_regs->si */
20
pushq  %rdx             /* pt_regs->dx */
21
pushq  %rcx tuichu    /* pt_regs->cx */
22
pushq  $-ENOSYS        /* pt_regs->ax */
23
pushq  %r8              /* pt_regs->r8 */
24
pushq  %r9              /* pt_regs->r9 */
25
pushq  %r10             /* pt_regs->r10 */
26
pushq  %r11             /* pt_regs->r11 */
27
sub $(6*8), %rsp      /* pt_regs->bp, bx, r12-15 not saved */

​ 4. 通过汇编指令判断是否为 x32_abi。

​ 5. 通过系统调用号，跳到全局变量 sys_call_table 相应位置继续执行系统调用。

虚拟内存空间#

在现代操作系统中，计算机的虚拟内存地址空间通常被分为两块——供用户进程使用的用户空间（user space）与供操作系统内核使用的内核空间（kernel space），对于 Linux 而言，通常位于较高虚拟地址的虚拟内存空间被分配给内核使用，而位于较低虚拟地址的虚拟内存空间责备分配给用户进程使用

1
详细见程序员的自我修养

32位下的内存分配

64位下的内存分配

进程权限管理#

内核 kernel 调度着一切的系统资源，并为用户应用程式提供运行环境，相应地，应用程式的权限也都是由 kernel 进行管理的。

1
/* Process credentials: */
2

3
/* Tracer's credentials at attach: */
4
const struct cred __rcu        *ptracer_cred;
5

6
/* Objective and real subjective task credentials (COW): */
7
const struct cred __rcu        *real_cred;
8

9
/* Effective (overridable) subjective task credentials (COW): */
10
const struct cred __rcu        *cred;

1
/*
2
 * The security context of a task
3
 *
4
 * The parts of the context break down into two categories:
5
 *
6
 *  (1) The objective context of a task.  These parts are used when some other
7
 *  task is attempting to affect this one.
8
 *
9
 *  (2) The subjective context.  These details are used when the task is acting
10
 *  upon another object, be that a file, a task, a key or whatever.
11
 *
12
 * Note that some members of this structure belong to both categories - the
13
 * LSM security pointer for instance.
14
 *
15
 * A task has two security pointers.  task->real_cred points to the objective
16
 * context that defines that task's actual details.  The objective part of this
17
 * context is used whenever that task is acted upon.
18
 *
19
 * task->cred points to the subjective context that defines the details of how
20
 * that task is going to act upon another object.  This may be overridden
21
 * temporarily to point to another security context, but normally points to the
22
 * same context as task->real_cred.
23
 */
24
struct cred {
25
    atomic_long_t   usage;
26
    kuid_t      uid;        /* real UID of the task */
27
    kgid_t      gid;        /* real GID of the task */
28
    kuid_t      suid;       /* saved UID of the task */
29
    kgid_t      sgid;       /* saved GID of the task */
30
    kuid_t      euid;       /* effective UID of the task */
31
    kgid_t      egid;       /* effective GID of the task */
32
    kuid_t      fsuid;      /* UID for VFS ops */
33
    kgid_t      fsgid;      /* GID for VFS ops */
34
    unsigned    securebits; /* SUID-less security management */
35
    kernel_cap_t    cap_inheritable; /* caps our children can inherit */
36
    kernel_cap_t    cap_permitted;  /* caps we're permitted */
37
    kernel_cap_t    cap_effective;  /* caps we can actually use */
38
    kernel_cap_t    cap_bset;   /* capability bounding set */
39
    kernel_cap_t    cap_ambient;    /* Ambient capability set */
40
#ifdef CONFIG_KEYS
41
    unsigned char   jit_keyring;    /* default keyring to attach requested
42
                     * keys to */
43
    struct key  *session_keyring; /* keyring inherited over fork */
44
    struct key  *process_keyring; /* keyring private to this process */
45
    struct key  *thread_keyring; /* keyring private to this thread */
46
    struct key  *request_key_auth; /* assumed request_key authority */
47
#endif
48
#ifdef CONFIG_SECURITY
49
    void        *security;  /* LSM security */
50
#endif
51
    struct user_struct *user;   /* real user ID subscription */
52
    struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
53
    struct ucounts *ucounts;
54
    struct group_info *group_info;  /* supplementary groups for euid/fsgid */
55
    /* RCU deletion */
56
    union {
57
        int non_rcu;            /* Can we skip RCU deletion? */
58
        struct rcu_head rcu;        /* RCU deletion hook */
59
    };
60
} __randomize_layout;

进程权限改变#

前面我们讲到，一个进程的权限是由位于内核空间的 cred 结构体进行管理的，那么我们不难想到：只要改变一个进程的 cred 结构体，就能改变其执行权限。

在内核空间有如下两个函数，都位于 kernel/cred.c 中：

• struct cred* prepare_kernel_cred(struct task_struct* daemon)：该函数用以拷贝一个进程的 cred 结构体，并返回一个新的 cred 结构体，需要注意的是 daemon 参数应为有效的进程描述符地址。

• int commit_creds(struct cred *new)：该函数用以将一个新的 cred 结构体应用到进程。

  当prepare_kernel_cred返回为空的时候，就会使得commit_creds创建一个null的结构体，而root组的id恰好是0,这样就达到了提权的目的

Loadable Kernel Modules(LKMs)#

Linux Kernel 采用的是宏内核架构，一切的系统服务都需要由内核来提供，虽然效率较高，但是缺乏可扩展性与可维护性，同时内核需要装载很多可能用到的服务，但这些服务最终可能未必会用到，还会占据大量内存空间，同时新服务的提供往往意味着要重新编译整个内核。

综合以上考虑，可装载内核模块（Loadable Kernel Modules，简称 LKMs）出现了，位于内核空间的 LKMs 可以提供新的系统调用或其他服务，同时 LKMs 可以像积木一样被装载入内核 / 从内核中卸载，大大提高了 kernel 的可拓展性与可维护性。

常见的 LKMs 包括：

• 驱动程序（Device drivers）
  • 设备驱动
  • 文件系统驱动
  • …
• 内核扩展模块 (modules)

LKMs 的文件格式和用户态的可执行程序相同，Linux 下为 ELF，Windows 下为 exe/dll，mac 下为 MACH-O，因此我们可以用 IDA 等工具来分析内核模块。

模块可以被单独编译，但不能单独运行。它在运行时被链接到内核作为内核的一部分在内核空间运行，这与运行在用户控件的进程不同。

模块通常用来实现一种文件系统、一个驱动程序或者其他内核上层的功能。

Linux 内核之所以提供模块机制，是因为它本身是一个单内核 (monolithic kernel)。单内核的优点是效率高，因为所有的内容都集合在一起，但缺点是可扩展性和可维护性相对较差，模块机制就是为了弥补这一缺陷。

系统调用简介#

系统调用，指的是用户空间的程序向操作系统内核请求需要更高权限的服务，比如 IO 操作或者进程间通信。系统调用提供用户程序与操作系统间的接口，部分库函数（如 scanf，puts 等 IO 相关的函数实际上是对系统调用的封装（read 和 write））

在 /usr/include/x86_64-linux-gnu/asm/unistd_64.h 和 /usr/include/x86_64-linux-gnu/asm/unistd_32.h 分别可以查看 64 位和 32 位的系统调用号。

同时推荐一个很好用的网站 Linux Syscall Reference，可以查阅 32 位系统调用对应的寄存器含义以及源码。64 位系统调用可以查看 Linux Syscall64 Reference

系统调用：ioctl#

在 *NIX 中一切都可以被视为文件，因而一切都可以以访问文件的方式进行操作，为了方便，Linux 定义了系统调用 ioctl 供进程与设备之间进行通信。

ioctl 是一个专用于设备输入输出操作的一个系统调用，其调用方式如下：

1
int ioctl(int fd, unsigned long request, ...)

其第一个参数为打开设备 (open) 返回的 文件描述符，第二个参数为用户程序对设备的控制命令，再后边的参数则是一些补充参数，与设备有关。

对于一个提供了 ioctl 通信方式的设备而言，我们可以通过其文件描述符、使用不同的请求码及其他请求参数通过 ioctl 系统调用完成不同的对设备的 I/O 操作。

使用 ioctl 进行通信的原因：

操作系统提供了内核访问标准外部设备的系统调用，因为大多数硬件设备只能够在内核空间内直接寻址, 但是当访问非标准硬件设备这些系统调用显得不合适, 有时候用户模式可能需要直接访问设备。

比如，一个系统管理员可能要修改网卡的配置。现代操作系统提供了各种各样设备的支持，有一些设备可能没有被内核设计者考虑到，如此一来提供一个这样的系统调用来使用设备就变得不可能了。

为了解决这个问题，内核被设计成可扩展的，可以加入一个称为设备驱动的模块，驱动的代码允许在内核空间运行而且可以对设备直接寻址。一个 Ioctl 接口是一个独立的系统调用，通过它用户空间可以跟设备驱动沟通。对设备驱动的请求是一个以设备和请求号码为参数的 Ioctl 调用，如此内核就允许用户空间访问设备驱动进而访问设备而不需要了解具体的设备细节，同时也不需要一大堆针对不同设备的系统调用

常见内核态函数#

在内核当中我们无法使用用户态的 C 库中的函数，内核自己有着对应的各种函数，其中常用的功能函数如下：

• printf() -> printk()，但需要注意的是 printk() 不一定会把内容显示到终端上，但一定在内核缓冲区里，可以通过 dmesg 查看效果
• memcpy() ->copy_from_user()/copy_to_user()
• copy_from_user() 实现了将用户空间的数据传送到内核空间 User---->Kernel
• copy_to_user() 实现了将内核空间的数据传送到用户空间 Kernel----->User
• malloc() -> kmalloc()，内核态的内存分配函数，和 malloc() 相似，但使用的是 slab/slub 分配器
• free() -> kfree()，同 kmalloc()

此外，kernel 管理进程，因此 kernel 也记录了进程的权限。kernel 中有两个可以方便的改变权限的函数：

• int commit_creds(struct cred *new)
• struct cred* prepare_kernel_cred(struct task_struct* daemon)

从函数名也可以看出，执行 commit_creds(prepare_kernel_cred(&init_task)) 即可获得 root 权限，即拷贝 init 进程的 cred 作为当前进程的新的 credentials。

更多关于 prepare_kernel_cred 的信息可以参考 源码

执行 commit_creds(prepare_kernel_cred(&init_task)) 也是最常用的提权手段，这些函数与变量的地址都可以在 /proc/kallsyms 中查看（较老的内核版本中是 /proc/ksyms），该文件的内容通常需要 root 权限才能正确查看。

1
$ sudo cat /proc/kallsyms | grep "T commit_creds"
2
ffffffffbb11ab20 T commit_creds
3
$ sudo cat /proc/kallsyms | grep "T prepare_kernel_cred"
4
ffffffffbb11b080 T prepare_kernel_cred
5
$ sudo cat /proc/kallsyms | grep "D init_cred"
6
ffffffffbce58840 D init_cred

proc_create函数：

关于这个函数一般出现在init_module里面，这个的作用一般是创建一个文件在/proc下并且把这个文件的操作逻辑绑定到我定义的 fops，当你对这个文件进行操作的时候，就会触发fogs函数表里面的函数，

for example：

1
proc_entry = (proc_dir_entry *)proc_create("pwncollege", 438, 0, &fops);
2
.data:0000000000000AA0 fops            file_operations <0, 0, offset device_read, offset device_write, 0, 0, \
3
.data:0000000000000AA0                                  0, 0, 0, 0, 0, 0, 0, 0, offset device_open, 0, \
4
.data:0000000000000AA0                                  offset device_release, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
5
.data:0000000000000AA0                                  0, 0, 0, 0, 0>

那么这里就会先调用device_read，然后调用device_write。。。。。。，以此类推

KASLR#

KASLR 即内核空间地址随机化（kernel address space layout randomize），与用户态程序的 ASLR 相类似——在内核镜像映射到实际的地址空间时加上一个偏移值（粒度为 256MB），但是内核内部的相对偏移其实还是不变的。

在未开启 KASLR 保护机制时，内核代码段的基址为 0xffffffff81000000 ，direct mapping area 的基址为 0xffff888000000000

FGKASLR#

KASLR 虽然在一定程度上能够缓解攻击，但是若是攻击者通过一些信息泄露漏洞获取到内核中的某个地址，仍能够直接得知内核加载地址偏移从而得知整个内核地址布局，因此有研究者基于 KASLR 实现了 FGKASLR，以函数粒度重新排布内核代码

STACK PROTECTOR#

类似于用户态程序的 canary，通常又被称作是 stack cookie，用以检测是否发生内核堆栈溢出，若是发生内核堆栈溢出则会产生 kernel panic。

内核中的 canary 的值通常取自 gs 段寄存器某个固定偏移处的值。

SMAP/SMEP#

SMAP 即管理模式访问保护（Supervisor Mode Access Prevention），SMEP 即管理模式执行保护（Supervisor Mode Execution Prevention），这两种保护通常是同时开启的，用以阻止内核空间直接访问 / 执行用户空间的数据，完全地将内核空间与用户空间相分隔开，用以防范 ret2usr（return-to-user，将内核空间的指令指针重定向至用户空间上构造好的提权代码）攻击，与NX保护类似

SMEP 保护的绕过有以下两种方式：

• 利用内核线性映射区对物理地址空间的完整映射，找到用户空间对应页框的内核空间地址，利用该内核地址完成对用户空间的访问（即一个内核空间地址与一个用户空间地址映射到了同一个页框上），这种攻击手法称为 ret2dir 。
• Intel 下系统根据 CR4 控制寄存器的第 20 位标识是否开启 SMEP 保护（1 为开启，0 为关闭），若是能够通过 kernel ROP 改变 CR4 寄存器的值便能够关闭 SMEP 保护，完成 SMEP-bypass，接下来就能够重新进行 ret2usr，但对于开启了 KPTI 的内核而言，内核页表的用户地址空间无执行权限，这使得 ret2usr 彻底成为过去式 。

在 ARM 下有一种类似的保护叫 PXN。

KPTI#

KPTI 即 内核页表隔离（Kernel page-table isolation），内核空间与用户空间分别使用两组不同的页表集，这对于内核的内存管理产生了根本性的变化。

需要进行说明的是，在这两张页表上都有着对用户内存空间的完整映射，但在用户页表中只映射了少量的内核代码（例如系统调用入口点、中断处理等），而只有在内核页表中才有着对内核内存空间的完整映射，但两张页表都有着对用户内存空间的完整映射，如下图所示，左侧是未开启 KPTI 后的页表布局，右侧是开启了 KPTI 后的页表布局。

KPTI 的发明主要是用来修复一个史诗级别的 CPU 硬件漏洞：Meltdown。简单理解就是利用 CPU 流水线设计中（乱序执行与预测执行）的漏洞来获取到用户态无法访问的内核空间的数据，属于侧信道攻击的一种

KPTI 同时还令内核页表中属于用户地址空间的部分不再拥有执行权限，这使得 ret2usr 彻底成为过去式。

Hardened Usercopy¶#

hardened usercopy 是用以在用户空间与内核空间之间拷贝数据时进行越界检查的一种防护机制，主要检查拷贝过程中对内核空间中数据的读写是否会越界：

• 读取的数据长度是否超出源 object 范围。
• 写入的数据长度是否超出目的 object 范围。

这一保护被用于 copy_to_user() 与 copy_from_user() 等数据交换 API 中，不过这种保护 不适用于内核空间内的数据拷贝 ，这也是目前主流的绕过手段。

Hardened freelist¶#

类似于 glibc 2.32 版本引入的保护，在开启这种保护之前，slub 中的 free object 的 next 指针直接存放着 next free object 的地址，攻击者可以通过读取 freelist 泄露出内核线性映射区的地址，在开启了该保护之后 free object 的 next 指针存放的是由以下三个值进行异或操作后的值：

• 当前 free object 的地址。
• 下一个 free object 的地址。
• 由 kmem_cache 指定的一个 random 值。

攻击者至少需要获取到第一与第三个值才能篡改 freelist，这无疑为对 freelist 的直接利用增添不少难度。

在更新版本的 Linux kernel 中似乎还引入了一个偏移值，笔者尚未进行考证。

Random freelist¶#

这种保护主要发生在 slub allocator 向 buddy system 申请到页框之后的处理过程中，对于未开启这种保护的一张完整的 slub，其上的 object 的连接顺序是线性连续的，但在开启了这种保护之后其上的 object 之间的连接顺序是随机的，这让攻击者无法直接预测下一个分配的 object 的地址。

需要注意的是这种保护发生在 slub allocator 刚从 buddy system 拿到新 slub 的时候，运行时 freelist 的构成仍遵循 LIFO。

CONFIG_INIT_ON_ALLOC_DEFAULT_ON¶#

当编译内核时开启了这个选项时，在内核进行 “堆内存” 分配时（包括 buddy system 和 slab allocator），会将被分配的内存上的内容进行清零，从而防止了利用未初始化内存进行数据泄露的情况。

据悉性能损耗在 1%~7% 之间。