1. sandboxing由来
sandboxing，俗称沙箱，是一个在现在看来非常普遍前有效的安全防御措施（比如chrome浏览器里有沙箱，docker也算一种沙箱，etc）
沙箱的诞生也是尤其历史原因的。
1. 起始时，大约1950年，计算机中的一切都运行在bare metal（直接在逻辑硬件上执行指令而无需操作系统的计算机）上
那时候，每个进程都是omnipotent（万能的），想干啥就干啥。这就有安全问题：一个进程出问题，整个机器都会出问题
2. 大约1960年，硬件措施被研发出来，用于隔离os代码和用户空间代码
这也有弱点，运行在操作系统的进程仍然可以互相影响
3. 大约1980年，虚拟内存地址空间技术出现，每个进程的内存空间被隔离开来
4. 大约1990年，in-process seperation也流行开来，最主要的做法是隔离解释器和被解释代码
例如，java解释器和java代码，python解释器和python代码
5. 大约2000年，浏览器的攻击手法丰富了起来，当时主要围绕三个浏览器特性进行攻击：
Adobe Flash
ActiveX
Java Applets
通过这些特性，攻击者需要让受害者访问恶意网址，触发漏洞，就能控制受害者系统
6. 大约2010年，浏览器也出了很多的缓解措施。
比如直接关闭这些特性
像Adobe Flash、ActiveX、Java Applets都不允许被使用了
但是这出现了问题：攻击者把目光投向了浏览器的其他特性：
JS engine(JS解析器)漏洞、Media Codec(音频编解码器)漏洞，Imaging library(图像库)漏洞
有些有识之士提出的解决方案是不受信任的代码/数据应该存活在进程的zero-permissions状态下
大致方法是发起父子进程，父进程为高权限进程，子进程为不受信任进程（存放不受信任代码/数据），子进程每次需要运行权限操作，都要经过父进程同意,沙箱应运而生
沙箱是一个非常强力的缓解措施，它直接导致了：
1. 需要一系列漏洞以利用沙盒进程
2. 需要另一系列漏洞来打破沙盒
2. chroot
传统的沙盒就是chroot，chroot第一次出现在1979年的UNIX系统上，随后不久也出现在了BSD上。
chroot修改了 ‘/’ 对于一个进程（包括其子进程）的含义
比如
chroot("/tmp/jail");
//会让进程认为 '/tmp/jail'目录（操作系统中的）就是自己的'/'目录
所以chroot是一个事实上的sandboxing utility(沙盒功能组件)
值得注意的一点是，chroot并没有禁止系统调用，也没有其他隔离功能
2.1 chroot使用注意事项
使用chroot时有很多点需要注意:
1. chroot系统调用执行时需要privilege，一般情况下需要root权限，所以执行时若不是root用户，需要执行sudo
不使用root权限的代价如下：
2. 被执行的命令或程序，需要在被限制的目录下
比如sudo chroot /tmp /bin/bash
这种情况下，在/tmp/bin目录中需要有bash文件
不在tmp目录下放/bin/bash实验结果如下:
3. 被执行程序，需要是静态编译好的，否则，需要把动态链接所需的所有库都放入jail当中
值得一提的是，如果动态库没有放好，也会报没有文件或目录的错误，如下图所示：
如果你在想要的目录下放好了所有动态程序所需的依赖,效果如下：
当然，个人建议还是使用静态程序，比较安逸，这里推荐使用busybox（集成了很多常见的unix命令，像ls cat这些都有），busybox官网https://busybox.net/，可以直接在上面下载编译好的程序使用
使用busybox的图如下:
2.2 chroot作用
chroot("/tmp/jail") 有2个作用:
1. 对于这个进程而言，改变 "/"的含义，使其为 "/tmp/jail"
2. 然后下面的一切： "/flag" 变成 "/tmp/jail/flag",对于这个进程而言，"/tmp/jail/.." 指向 "/tmp/jail"
chroot是有缺点的
chroot("/tmp/jail") 不能:
1. 关闭原本已经开启的指向其他目录（非jail目录）的文件描述符等系统资源。
2. cd (chdir()) 来进入jail，需要显示得调用chdir("/");才行
3. 做其他事情！
2.3 chroot陷阱
先前提到，chroot不会对原本已经开启的文件描述符等系统资源做限制。
与 open 和 execve类似, Linux 还有 openat 和 execveat 的系统调用:
int open(char *pathname, int flags);
int openat(int dirfd, char *pathname, int flags);
int execve(char *pathname, char **argv, char **envp);
int execveat(int dirfd, char *pathname, char **argv, char **envp, int flags);
dirfd 能表示为任何一个打开着的目录文件描述符, 或者是特殊值 AT_FDCWD(在linux代表的是当前工作目录) (注意: chroot()
不会改变当前工作目录)!
另外，内核并不会记得程序已经在一个jail当中，也就是说，你可以通过在使用一次chroot("/")来跳出jail(当然这要求进程有CAP_SYS_CHROOT权限，通常就是root)
2.4 chroot安全性讨论
当然chroot不安全，首先，euid为0(即具备root或suid)的程序可以随时跳出jail,除非chroot被禁用了
另外，chroot也没有对做PID network IPC的隔离，比如：
在知道了PID后，你可以开启其他终端来中断jail的运行。
3. seccomp
现代的sandboxing会严格的限制进程的系统调用；这主要通过一个内核级的sandboxing机制——seccomp来实现
seccomp机制能够允许开发者写下复杂的规则来完成以下事情:
1. 允许进程使用system call
2. 禁止进程使用system call
3. 筛选允许和不允许的系统调用
另外有一点，当前进程的seccomp是能够被其子进程继承的！
3.1 seccomp示例
请看示例：
//gcc seccomp.c -o seccomp -lseccomp
#include <sys/sendfile.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <seccomp.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>
#include <assert.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
#include <time.h>
#include <fcntl.h>
int main(){
scmp_filter_ctx ctx;
ctx = seccomp_init(SCMP_ACT_ALLOW);
seccomp_rule_add(ctx,SCMP_ACT_KILL,SCMP_SYS(read),0);
seccomp_load(ctx);
execl("/bin/cat","cat","/flag",0);
}
实际上，作为该进程的子进程cat无法读取flag！
用strace跟踪系统调用，结果如下:
3.2 seccomp工作原理
seccomp实际上是通过prctl系统调用来实现控制的，而prctl系统调用又依赖于eBPF(extended Berkeley Packet Filters),eBPF是运行于内核态的一个”可证明安全“的虚拟机，它能在内核中插入用户想要实现的功能：
1. 通常用于网络包过滤（比如iptables）
2. 可用于实现系统调用跟踪和限制！
bpf详情可参考https://github.com/iovisor/bcc
4. escaping seccomp
seccomp是现代非常强力的sandbox机制，chrome/firefox浏览器的安全机制也都需要依赖seccomp！
这么强力的安全保护机制，我们要如何对其进行逃逸呢？
4.1 直觉
一个处于sandbox状态的进程要想做些有用的事情，就需要和特权进程进行通信；而这意味着允许sandboxed process 使用某些特定的系统调用
这打开了新的攻击面：
1. permissive policies:允许策略
2. syscall confusion：系统调用混淆
3. kernel vulnerabilities in the syscall handlers： 内核漏洞
4.2 permissive policies：允许策略
所谓允许策略，主要通过两个因素进行联合导致的：
1. linux内核中有很多的system calls，并且他们都很复杂
2. 开发者可能会想要避免通过许可方面的错误，导致破坏功能
这两点意味着：开发者很可能不会对策略上做过多的限制，这可能会导致原本开发的程序功能不可用！
🤭不知道大伙自己有没有开发过东西，这是很正常的一个心理反应，毕竟你开发就够麻烦了，还要考虑奇奇怪怪的东西
但是这会导致很多的系统调用没有被限制，而这会导致沙箱逃逸问题,举个例子：
1. ptrace: 如果ptrace没有被禁用，那么沙箱进程可以通过ptrace系统调用
来操纵一个非沙箱进程，从而导致逃逸！
2. sendmsg： sendmsg可以允许进程间同步文件描述符，如果非沙箱进程中的一个进程描述符
指向一个关键文件（沙箱进程无法访问），非沙箱进程可以通过sendmsg与沙箱进程同步该描述
符，导致关键文件信息泄露
3. prctl：prctl系统调用可能有奇怪的影响：prctl控制自身进程的一些属性，能够直接写内
存，如果prctl没有被限制，沙箱进程可能通过一些特殊手法修改自身属性，导致逃逸。
4. process_vm_writev：该系统调用允许直接访问其他进程的内存，这意味着可以从其他进程
里面偷东西
4.3 syscall confusion
正常情况下，64位系统都是兼容32位程序的！
在一些系统中(例如amd64),一个进程是可以在32位和64位之间切换的，这意味着操作系统需要准备32位和64位程序所需的一切！
这当然也包括了系统调用。
然而，不同的架构的系统调用号是不同的，这也包括相同架构的32位和64位程序
例如：
exit 在amd64的下的系统调用号为 60
而在 x86下的系统调用号为1
在允许进程随时切换32/64位的操作系统中，沙盒的策略很有可能只关注64位，而忽视了32位！这就让攻击者有机可乘。
4.4 kernel vulnerabilities in the syscall handlers
如果开发者很聪明，seccomp的策略很正确，那么挖内核漏洞就变成了最终手段
因为seccomp不可能限制全部的系统调用，可以通过挖相关触发的内核漏洞，触发沙箱逃逸。
https://github.com/allpaca/chrome-sbx-db中就记录了chrome浏览器的漏洞
4.5 思考你的目标
大多情况下，攻击者的目标不是为了拿到shell（当然，拿到最好）
以ctf比赛为例，我们的目标是为了拿flag，即使你不能直接的与外部世界进行通信，你也可以发送烟雾信号
1. Runtime of a process (see sleep(x) system call) can convey a lot of data.
这是一个很tricky的点，如果你想传送数据，你可以不断使用sleep来确定睡眠的时间，根据睡眠时间传送数据（比如 睡1秒就是\x01）
2. Clean termination or a crash? This can convey one bit.
遇到一个crash就是1，没有crash就是0，这样能传送1 bit 数据
3. Return value of a program (exit(x)) can convey one byte.
根据程序退出的返回值来传送数据
一个现实的例子是攻击者利用DNS查询机制来绕过network egress filter(网络出口过滤器)
1. 你攻击进入了某个内网服务器，但是你不能进行网络请求，除了dns查询
2. 你可以让它执行一个域名查询，比如 www.password.xxx.com，把password信息带出内外服务器