Linux脚本沙盒原理与实践：基于命名空间与cgroups的安全隔离

1. 项目概述：一个安全的脚本沙盒环境

在运维和开发工作中，我们经常会遇到一个头疼的问题：需要运行一个来源不明、或者功能尚不明确的脚本。直接在生产环境或自己的主力机器上执行？风险太高，一个rm -rf /或者一个死循环就可能导致服务中断或数据丢失。在虚拟机里跑？太重了，启动慢、占用资源多，而且每次测试都要重新配置环境，效率低下。这时候，一个轻量级、隔离性好、用完即弃的脚本沙盒环境就成了刚需。

Th0rgal/sandboxed.sh这个项目，就是为解决这个痛点而生的。它是一个用纯 Bash 编写的脚本，核心目标是为任意命令或脚本创建一个临时的、高度受限的运行环境。你可以把它理解为一个“一次性安全屋”，脚本在里面怎么折腾，都很难影响到外部的真实系统。它通过 Linux 内核提供的多种命名空间（如 PID, Mount, Network, UTS, IPC, User）来构建隔离层，同时结合cgroups进行资源限制，再配合精心设计的文件系统视图（使用overlayfs），最终实现了一个功能相对完整、但资源消耗极低的沙盒。

这个工具非常适合以下几类场景：安全研究人员需要动态分析可疑脚本的行为；开发者想测试一个可能会修改系统配置的安装脚本；运维人员希望验证某个自动化运维脚本在不同条件下的执行效果；或者，你只是想在一个干净的环境里快速试试某个命令行工具，而不想污染自己的主系统。它的存在，让“大胆测试”变得没有后顾之忧。

2. 核心原理与架构拆解

要理解sandboxed.sh的精妙之处，我们需要深入其实现原理。它并非简单地用chroot换个根目录，而是构建了一个多层级的隔离体系，每一层都针对特定的风险进行了防护。

2.1 命名空间隔离：进程的“平行宇宙”

Linux 命名空间是容器技术的基石，它允许进程看到不同的系统视图。sandboxed.sh主要利用了以下几个命名空间：

• PID 命名空间：沙盒内的进程拥有独立的进程树，其 PID 从 1 开始编号。这意味着沙盒内的进程看不到宿主机上的其他进程，也无法通过 PID 向它们发送信号。一个典型的例子是，你在沙盒里运行ps aux，看到的只会是沙盒内自身的几个进程，而不是宿主机上成百上千的进程列表。
• Mount 命名空间：这是实现文件系统隔离的关键。沙盒拥有独立的挂载点列表。sandboxed.sh会在这里创建一个精简的根文件系统视图。通过pivot_root系统调用，沙盒进程会将自己的根目录切换到临时创建的文件系统，从而无法直接访问宿主机的真实根目录。
• Network 命名空间：沙盒拥有独立的网络栈，包括自己的网卡、路由表、防火墙规则等。默认情况下，沙盒内没有网络连接，形成了一个网络孤岛。项目也提供了选项，可以创建一个虚拟网卡对（veth pair），将沙盒连接到宿主机网络，甚至进行网络流量限制。
• UTS 命名空间：隔离主机名和域名。沙盒可以设置自己的主机名，而不会影响宿主机。
• IPC 命名空间：隔离进程间通信资源，如信号量、消息队列和共享内存。防止沙盒内进程通过 IPC 与宿主机进程通信。
• User 命名空间：这是实现非特权用户运行沙盒的魔法所在。它允许在沙盒内部将普通用户映射为 root 用户（uid 0），拥有沙盒内的最高权限，可以执行挂载等操作；但在沙盒外部（宿主机），该进程仍然以原来的非特权用户身份运行，权限受到严格限制。这极大地提升了安全性，避免因沙盒逃逸而导致宿主机被提权。

注意：并非所有 Linux 发行版都默认启用用户命名空间。你需要检查/proc/sys/kernel/unprivileged_userns_clone的值是否为 1。如果是 0，则需要以 root 权限执行，或者修改该内核参数。

2.2 联合文件系统与资源视图

仅有命名空间还不够，还需要为沙盒提供一个“看起来像”完整系统的文件系统。sandboxed.sh通常使用overlayfs来构建这个视图。

1. 创建临时目录结构：脚本会创建几个临时目录：lower（只读层）、upper（可写层）、work（工作目录）和merged（合并视图层）。
2. 填充只读层：lower层通常包含一个最小化的根文件系统，比如从 Docker 镜像（如busybox、alpine）中提取，或者直接使用宿主机的/usr、/lib等目录的绑定挂载（bind mount）。这提供了运行基本命令所需的库和二进制文件。
3. 挂载 Overlay：将lower、upper、work和merged通过overlayfs挂载起来。对沙盒进程来说，merged目录就是它的根目录/。所有在沙盒内对文件的修改，都只会写入upper层，而lower层保持原样。当沙盒退出后，直接删除整个临时目录，所有修改痕迹荡然无存，实现了“用完即焚”。

2.3 资源限制与管控

通过cgroups（控制组），sandboxed.sh可以对沙盒内进程使用的资源进行硬性限制，防止其耗尽系统资源。

• 内存限制：可以设置内存和交换空间的上限，一旦超过，内核会终止相关进程。
• CPU 限制：可以分配 CPU 时间片权重，或者限制只能使用特定的 CPU 核心。
• 进程数限制：防止fork bomb攻击。
• 块设备 I/O 限制：限制磁盘读写速率。

这些限制通过写入cgroup虚拟文件系统（通常是/sys/fs/cgroup/下的相应目录）来实现。sandboxed.sh会在启动时创建专属的cgroup，将沙盒进程加入其中，并设置好限制参数。

2.4 能力集与安全策略

即使沙盒内进程以 root 身份运行，其能力也是被阉割的。Linux 的能力机制将 root 特权细分为几十个独立的“能力”。sandboxed.sh在创建沙盒时，会调用capset系统调用，丢弃掉绝大多数危险的能力，例如：

• CAP_SYS_ADMIN：执行系统管理操作的能力（如挂载、设置主机名）。
• CAP_NET_ADMIN：执行网络管理操作的能力。
• CAP_SYS_MODULE：加载和卸载内核模块的能力。
• CAP_SYS_PTRACE：调试其他进程的能力。

只保留少数沙盒运行所必需的能力。这遵循了“最小权限原则”，即使攻击者突破了命名空间隔离，其能造成的破坏也极其有限。

3. 从零开始构建一个简易沙盒

理解了原理，我们不妨动手，抛开sandboxed.sh，用最原始的命令来体验一下构建沙盒的过程。这能让你对每一层隔离有更深刻的体会。

3.1 环境准备与依赖检查

首先，确保你的系统支持所需功能。一个现代化的 Linux 发行版（如 Ubuntu 20.04+, Fedora, Arch）通常都满足要求。

# 检查内核是否支持命名空间和 overlayfs uname -r # 建议 4.x 以上 lsmod | grep overlay # 检查 overlay 模块是否加载 cat /proc/filesystems | grep overlay # 检查是否支持 overlay 文件系统 # 检查用户命名空间是否允许非特权使用 cat /proc/sys/kernel/unprivileged_userns_clone # 输出 1 表示允许，0 表示不允许。如果是0，可以临时启用（需要sudo）： # sudo sysctl -w kernel.unprivileged_userns_clone=1 # 或者永久生效：在 /etc/sysctl.conf 或 /etc/sysctl.d/ 下添加 kernel.unprivileged_userns_clone=1 # 安装必要工具（以Ubuntu/Debian为例） sudo apt update sudo apt install -y util-linux cgroup-tools busybox-static

util-linux提供了unshare命令，它是我们手动创建命名空间的核心工具。cgroup-tools用于管理 cgroups。busybox-static为我们提供了一个极简的、静态链接的二进制集合，非常适合作为沙盒的根文件系统。

3.2 分步手动创建沙盒

我们创建一个临时目录作为工作区，并分步骤构建沙盒。

# 1. 创建工作目录和 overlay 所需目录 WORKDIR=$(mktemp -d) cd $WORKDIR mkdir -p rootfs/{bin,lib,etc,proc,sys,dev,tmp,home} overlay/{lower,upper,work,merged} # 2. 准备一个最小的根文件系统 (lower层) # 将 busybox 复制到 rootfs/bin，并创建必要的符号链接 cp /bin/busybox rootfs/bin/ cd rootfs/bin for cmd in $(./busybox --list); do ln -s busybox $cmd 2>/dev/null done cd $WORKDIR # 3. 使用 unshare 创建命名空间并启动沙盒 # 这条命令是关键： sudo unshare \ --pid --fork --mount-proc \ --mount --uts --ipc --net --user --map-root-user \ --cgroup \ bash -c " # 此时我们已经在新的命名空间里了，但根目录还没变 echo '沙盒内 PID: $$' hostname my-sandbox # 4. 设置 cgroup 限制 (需要先挂载 cgroup2，如果系统使用 unified hierarchy) # 这里以 memory 为例 CGROUP_DIR=\"/sys/fs/cgroup/$(cat /proc/self/cgroup | grep 0:: | cut -d: -f3)/sandbox_$$\" mkdir -p \$CGROUP_DIR echo 100000000 > \$CGROUP_DIR/memory.max # 限制内存约100MB echo $$ > \$CGROUP_DIR/cgroup.procs # 将当前进程加入该cgroup # 5. 准备 OverlayFS mount -t overlay overlay -o lowerdir=$WORKDIR/rootfs,upperdir=$WORKDIR/overlay/upper,workdir=$WORKDIR/overlay/work $WORKDIR/overlay/merged # 6. 切换根目录 (pivot_root) cd $WORKDIR/overlay/merged mkdir -p old_root pivot_root . old_root # 卸载旧的根目录并清理 umount -l old_root rmdir old_root # 7. 挂载必要的虚拟文件系统 mount -t proc proc /proc mount -t sysfs sys /sys mount -t tmpfs tmpfs /tmp mount -t devtmpfs devtmpfs /dev 2>/dev/null || mount -t tmpfs devtmpfs /dev # 8. 现在，一个基本的沙盒已经就绪！ echo '=== 沙盒环境信息 ===' hostname cat /proc/self/cgroup df -h / echo '=== 尝试一些命令 ===' ls -la /bin ps aux # 应该只看到沙盒内的进程 # 启动一个交互式shell export PS1='[Sandbox] \w \$ ' exec /bin/sh "

步骤解析与注意事项：

1. unshare参数：
   • --pid --fork --mount-proc: 创建 PID 命名空间，并自动挂载新的/proc。--fork是--pid所必需的。
   • --mount: 创建 Mount 命名空间。
   • --uts,--ipc,--net,--user: 创建对应的命名空间。--map-root-user在 User 命名空间内将外部用户映射为内部 root。
   • --cgroup: 创建 Cgroup 命名空间。
2. Cgroup 设置：我们创建了一个以进程 PID 命名的子 cgroup 来设置内存限制。这是cgroup v2的写法。如果你的系统是cgroup v1，路径和文件会有所不同（如/sys/fs/cgroup/memory/sandbox_$$/memory.limit_in_bytes）。
3. pivot_root与chroot：pivot_root比传统的chroot更安全。chroot只是改变了进程的根目录视图，但通过某些文件描述符仍可能访问外部文件系统。pivot_root则完全将旧根目录移走并挂载在新的位置，隔离更彻底。
4. 权限问题：上述命令使用了sudo，因为挂载文件系统通常需要特权。如果配置了用户命名空间且系统支持非特权挂载，理论上可以不用sudo，但配置过程更复杂。
5. 网络隔离：通过--net创建的网络命名空间默认是空的，没有网卡。你可以手动创建veth设备对来连接宿主机网络，但这需要更多步骤和权限。

执行完上述命令后，你会进入一个全新的 shell 环境。尝试运行一些命令，你会发现/下的文件很少，ps看到的进程也很少，并且无法访问宿主机的网络。输入exit退出后，整个$WORKDIR临时目录可以被安全删除。

4. sandboxed.sh 的实战应用与高级配置

手动构建虽然有助于理解，但效率太低。现在让我们回到Th0rgal/sandboxed.sh，看看它如何将这些复杂步骤封装成一个简洁易用的工具。

4.1 基本安装与快速上手

首先获取脚本。通常这类项目会托管在 GitHub 或 GitLab 上。

# 假设从 GitHub 获取 curl -L -o sandboxed.sh https://raw.githubusercontent.com/Th0rgal/sandboxed.sh/main/sandboxed.sh chmod +x sandboxed.sh # 查看帮助 ./sandboxed.sh --help

一个最简单的使用例子是运行一个可能有风险的命令：

# 在一个隔离环境中运行未知脚本 ./sandboxed.sh bash -c "curl -s http://example.com/suspicious-script.sh | sh" # 这样，即使脚本包含 `rm -rf /` 或 `:(){ :|:& };:` (fork炸弹)，也不会伤害宿主机。 # 测试一个会修改系统配置的命令 ./sandboxed.sh apt-get install some-package # 沙盒退出后，`some-package` 并没有真正安装到宿主机上。

4.2 核心参数详解与场景配置

sandboxed.sh提供了丰富的参数来定制沙盒环境，以下是一些关键参数及其应用场景：

• -r, --root: 指定沙盒的根文件系统镜像。这是最重要的参数之一。

  # 使用一个最小的 Alpine Linux 镜像作为根文件系统 ./sandboxed.sh -r /path/to/alpine-minirootfs.tar.gz -- ls -la / # 这对于需要特定发行版环境（如测试基于glibc或musl的软件）非常有用。

• -w, --working-dir: 设置沙盒内的工作目录。可以配合文件映射使用。

  # 将宿主机的当前目录映射到沙盒内的 /workspace，并在其中工作 ./sandboxed.sh -w /workspace --bind $PWD:/workspace -- ls /workspace

• -b, --bind: 将宿主机目录只读或读写挂载到沙盒内。这是与外界交换数据的桥梁。

  # 只读挂载一个数据目录 ./sandboxed.sh -b /usr/share/zoneinfo:/etc/zoneinfo:ro -- cat /etc/zoneinfo/UTC # 读写挂载一个临时输出目录 OUTPUT_DIR=$(mktemp -d) ./sandboxed.sh -b $OUTPUT_DIR:/output:rw -- bash -c "echo 'Hello from sandbox' > /output/test.txt" cat $OUTPUT_DIR/test.txt

• -n, --network: 配置网络。选项可以是none（无网络，默认）、host（共享宿主机网络栈，隔离性降低）、bridge（连接到网桥）等。

  # 允许沙盒访问网络（比如测试下载或API调用） ./sandboxed.sh -n bridge -- curl -I https://www.google.com # 使用 `none` 可以彻底杜绝脚本进行网络通信，适用于分析离线恶意软件。

• --cpu-shares,--memory,--pids-limit: 设置 cgroup 资源限制。

  # 限制沙盒最多使用 1个CPU核、512MB内存、最多100个进程 ./sandboxed.sh --cpu-shares 1024 --memory 512m --pids-limit 100 -- stress --cpu 4 --vm 2 --vm-bytes 256M --timeout 10s # 即使 stress 命令试图超限使用资源，也会被 cgroup 限制住。

• --cap-add/--cap-drop: 精细控制沙盒内的 Linux 能力。这是高级安全配置。

  # 默认情况下，很多危险能力已被丢弃。你可以根据需要添加，但务必谨慎。 # 例如，如果沙盒内的程序需要设置系统时间（通常不需要），可以添加 CAP_SYS_TIME # ./sandboxed.sh --cap-add SYS_TIME -- date -s \"20230101\"

• --readonly-rootfs: 将整个根文件系统设置为只读。任何写入/的尝试都会失败。这非常适合运行那些只需要读取依赖库，但绝不应该修改系统的应用程序。

4.3 典型应用场景实操

场景一：安全分析未知的 Shell 脚本

你从论坛下载了一个号称能优化系统的脚本optimize.sh，但不敢直接运行。

# 1. 首先，在无网络、只读根目录的严格沙盒中静态检查 ./sandboxed.sh -n none --readonly-rootfs -- bash -n ./optimize.sh # 检查语法 ./sandboxed.sh -n none --readonly-rootfs -- shellcheck ./optimize.sh # 使用shellcheck进行静态分析 # 2. 动态分析：运行它，但限制其资源并记录行为 # 使用 `strace` 或 `bash -x` 来跟踪系统调用和命令执行 ./sandboxed.sh --memory 256m --pids-limit 50 -- strace -f -o trace.log ./optimize.sh # 分析 trace.log，查看脚本尝试打开了哪些文件，执行了哪些命令，建立了哪些网络连接。 # 3. 如果有读写目录的需求，可以映射一个临时目录给它 TEMP_DIR=$(mktemp -d) ./sandboxed.sh -b $TEMP_DIR:/tmp/scratch:rw -- ./optimize.sh # 运行后，检查 $TEMP_DIR 里被创建或修改了哪些文件，以了解脚本的行为。

场景二：构建可重复的软件测试环境

你需要测试一个软件在不同 Linux 发行版下的兼容性。

# 准备不同发行版的根文件系统镜像（可以从Docker Hub下载） # alpine: docker export $(docker create alpine:latest) | gzip > alpine.tar.gz # ubuntu: docker export $(docker create ubuntu:22.04) | gzip > ubuntu.tar.gz # 在 Alpine 环境中测试 ./sandboxed.sh -r ./alpine.tar.gz -w /app -b $(pwd):/app:ro -- sh -c "cd /app && ./configure && make test" # 在 Ubuntu 环境中测试 ./sandboxed.sh -r ./ubuntu.tar.gz -w /app -b $(pwd):/app:ro -- bash -c "cd /app && apt-get update && apt-get install -y build-essential && ./configure && make test"

这样，你可以在同一台宿主机上，快速切换不同的、纯净的发行版环境进行测试，无需管理多个虚拟机。

场景三：作为轻量级 CI/CD 运行器

在 GitLab CI 或 GitHub Actions 中，你可以使用sandboxed.sh来运行用户提交的、可能不信任的构建脚本。

# 假设的 CI 配置片段 test_job: script: - | # 下载并准备沙盒工具 curl -L -o sandboxed.sh https://example.com/sandboxed.sh chmod +x sandboxed.sh # 在沙盒中运行用户定义的构建步骤 ./sandboxed.sh \ --memory 2g \ --cpu-shares 1024 \ --pids-limit 512 \ -b $CI_PROJECT_DIR:/builds:rw \ -w /builds \ -- \ bash -c "./user_build_script.sh"

这比直接使用 Docker 容器更轻量，启动更快，并且由于定制了更严格的能力集和资源限制，可能更安全。

5. 深入排查：常见问题与安全边界

即使有了沙盒，也并非绝对安全。理解其局限性和常见问题，才能更好地使用它。

5.1 常见问题速查表

5.2 安全边界与逃逸风险认知

必须清醒认识到，基于命名空间的沙盒并非银弹，它存在已知的逃逸风险：

1. 内核漏洞：这是最大的威胁。如果内核存在漏洞，允许进程突破命名空间隔离（如Dirty COW,CVE-2022-0492等），那么沙盒将形同虚设。防御方法：保持内核更新到最新稳定版本。
2. 挂载泄露：如果沙盒内被授予了CAP_SYS_ADMIN能力，并且可以挂载宿主机目录或设备，就可能逃逸。例如，挂载宿主机/到沙盒内某个目录。防御方法：遵循最小权限原则，在沙盒内丢弃CAP_SYS_ADMIN能力，并谨慎使用--bind。
3. 符号链接与文件描述符攻击：通过/proc/self/fd/或巧妙的符号链接，可能访问到沙盒外的文件。防御方法：确保沙盒的根文件系统是干净的，并且procfs被正确限制（如使用hidepid挂载选项）。
4. 共享资源攻击：如果沙盒与宿主机共享了某些全局资源，如 System V IPC 键、/dev/shm下的文件，且未通过 IPC 命名空间隔离，可能构成攻击面。防御方法：确保创建了完整的命名空间集合（IPC, UTS等）。
5. 侧信道攻击：通过 CPU 缓存、内存总线等物理侧信道进行的攻击，这类攻击难度极高，但理论上存在。

最佳实践建议：

• 非特权运行：尽可能配置系统以支持非特权用户命名空间，让沙盒在非 root 用户下运行。这能将破坏范围限制在该用户权限内。
• 最小权限：使用--cap-drop ALL然后--cap-add仅添加必需的能力。
• 只读根文件系统：除非必要，始终使用--readonly-rootfs。
• 限制资源：总是设置合理的内存、CPU 和进程数限制。
• 审计与监控：结合auditd、strace、bpftrace等工具，监控沙盒进程的系统调用和异常行为。
• 纵深防御：不要完全依赖一层沙盒。对于极高风险的代码，应考虑在虚拟机中运行沙盒，或者使用专门的安全沙盒产品（如gVisor,Firecracker）。

sandboxed.sh这类工具的价值在于，它在便捷性和安全性之间取得了很好的平衡。对于绝大多数非恶意的测试、开发和轻度隔离场景，它提供了足够的安全保障。但对于对抗真正的恶意软件或处理极端敏感的任务，你需要评估风险，并考虑更强的隔离方案。理解它的工作原理和边界，正是安全、有效使用它的前提。