Dify-Sandbox：不可信代码的安全机制

Dify-Sandbox：不可信代码的安全机制

引言

在 LLM 应用开发平台中，用户经常需要在工作流中嵌入自定义代码逻辑。Dify 提供了"代码节点"功能，允许用户编写 Python3 或 NodeJS 代码来处理数据。然而，直接在服务端执行用户提交的代码是极其危险的——恶意代码可能读取敏感文件、发起网络攻击、甚至提权控制整个服务器。

Dify-Sandbox 正是为解决这一问题而设计的独立微服务。它采用 Go 语言编写，以多层纵深防御策略确保用户代码在严格隔离的环境中安全执行。本文基于 0.2.15 版本源码，深入剖析它的功能全貌与安全隔离机制，并特别关注近期版本中几项重要的安全修复。

一、Dify-Sandbox 做了什么

1.1 总体定位

Dify-Sandbox 是一个独立的 HTTP 微服务，监听在 8194 端口上。Dify 主服务通过 HTTP 调用将用户代码发送给沙箱执行，沙箱在隔离环境中运行代码后返回执行结果。这种架构将不可信代码的执行与主服务完全解耦，即使沙箱被攻破，主服务也不会受到影响。

1.2 核心功能一览

Dify-Sandbox 提供了以下核心能力：

代码执行是它的本职工作。它接收 Python3 或 NodeJS 代码，在隔离环境中执行，并将标准输出和标准错误返回给调用方。

依赖管理是面向 Python 的附加能力。沙箱支持通过 pip 安装第三方依赖，可以列出已安装的依赖列表，也可以定期刷新依赖以保持更新。默认预装了 httpx、requests、jinja2 和 PySocks 等常用库。

网络访问控制允许管理员配置是否允许沙箱中的代码访问网络。当启用网络时，还可以配置 HTTP/SOCKS5 代理来进一步约束网络行为。

预加载脚本机制允许在用户代码执行前先运行一段初始化脚本，例如预导入某些库。但出于安全考虑，该功能默认关闭。

并发与资源控制通过最大 Worker 数和最大请求数两个维度限制并发执行量，同时每个代码执行任务都有超时机制，超时后进程会被强制终止。

1.3 一次代码执行的完整旅程

当用户在 Dify 工作流中触发一个代码节点时，整个执行流程如下：

Dify 主服务中的 CodeExecutor 类构造 HTTP 请求，目标地址为沙箱服务的 /v1/sandbox/run 接口，请求头中携带 API Key 用于身份认证，请求体包含语言类型、代码内容、预加载脚本和网络开关四个字段。

沙箱服务收到请求后，首先经过 Auth 中间件校验 API Key，然后经过 MaxRequest 中间件检查当前请求总数是否超限，再经过 MaxWorker 中间件检查当前并发 Worker 数是否已达上限。三层检查通过后，请求进入 RunSandboxController 控制器。

控制器根据语言类型将请求分发到对应的 Service 层。Service 层负责参数校验（例如检查网络是否被全局禁用）、超时时间计算，然后调用对应的 Runner 执行代码。

Runner 是整个流程的核心。它负责从 UID 池中获取一个可用的 UID、初始化执行环境、创建子进程并通过管道传递用户代码、捕获输出、清理临时文件并归还 UID。不同语言的 Runner 有不同的实现细节，这将在下一节详细展开。

1.4 Python 代码的执行细节

Python Runner 的执行流程经过了一次重要的安全重构。在早期版本中，用户代码通过 XOR 加密后写入临时文件，密钥通过命令行参数传递。而在当前版本中，这一机制被更优雅的管道传输方案取代。

当 Runner 接收到用户代码后，它首先从 UID 池中获取一个可用的 UID。然后生成 prescript.py 引导脚本，将 UID、GID 和网络开关等参数注入到模板中。引导脚本以 0600 权限写入临时文件，并通过 chown 将文件所有者设为即将使用的沙箱 UID，确保只有该 UID 的用户才能读取引导脚本。

接下来，Runner 创建一对匿名管道（pipe），将读端作为子进程的额外文件描述符传入。子进程启动后，Runner 在一个独立的 Goroutine 中将用户代码明文写入管道的写端，写完后立即关闭写端。子进程则从文件描述符 3（即管道的读端）读取用户代码。

prescript.py 模板是整个 Python 执行流程的关键。它的核心逻辑如下：首先通过 ctypes 加载一个名为 python.so 的 C 共享库，这个库导出了一个名为 DifySeccomp 的函数。然后从命令行参数中获取运行路径。接着执行预加载脚本（如果有的话）。随后调用 DifySeccomp 函数，这一步会依次执行 Chroot、设置 NO_NEW_PRIVS、加载 Seccomp 规则、降权等一系列安全初始化操作，将进程锁入沙箱。在沙箱激活之后，脚本通过 os.fdopen(3, "rb") 从文件描述符 3 读取用户代码，并通过 exec(compile(code, "<fd3>", "exec")) 执行。

这里有一个非常关键的设计：用户代码的读取和执行发生在 Seccomp 激活之后。也就是说，当用户代码开始运行时，进程已经被内核级别的安全策略锁定了，用户代码无法做出任何越权行为。同时，由于用户代码通过管道传递而非写入磁盘，代码明文从未出现在文件系统中，从根本上消除了磁盘窥探的风险。

子进程的环境变量被完全清空，只按需添加代理配置和允许的系统调用列表。这防止了通过环境变量泄露主服务中的敏感信息，比如数据库密码或其他 API Key。

代码执行完毕或超时后，Runner 会自动关闭管道、删除临时引导脚本文件、将 UID 归还到池中，不留痕迹。

1.5 NodeJS 代码的执行细节

NodeJS Runner 的执行流程与 Python 有所不同，主要体现在文件系统隔离策略上。

与 Python 类似，NodeJS Runner 也从 UID 池中获取一个独立的 UID 用于本次执行。它采用了一种基于临时目录的文件系统隔离方案。每次执行代码时，它会创建一个带有随机 UUID 的临时目录，然后将 NodeJS 运行所需的最小文件集合拷贝进去。这些必需文件包括 NodeJS 项目文件、seccomp 共享库、SSL 证书、DNS 解析配置和 hosts 文件等。拷贝完成后，工作目录切换到这个临时目录，代码执行完毕后整个临时目录会被删除。

在代码注入方式上，NodeJS 也采用了与 Python 相同的管道传输方案。Runner 创建一对匿名管道，将读端作为子进程的额外文件描述符传入，在独立 Goroutine 中将用户代码写入管道。子进程通过 fs.readFileSync(3, 'utf8') 从文件描述符 3 读取代码，然后用 eval 执行。

prescript.js 的核心逻辑与 Python 版本类似：通过 koffi 库加载 nodejs.so 共享库，调用 DifySeccomp 函数激活沙箱。DifySeccomp 函数接收的参数是通过命令行传入的 uid、gid 和一个 JSON 格式的选项字符串。

1.6 共享库的编译与加载

无论是 Python 还是 NodeJS，它们加载的 .so 共享库都是通过 Go 的 CGO 机制编译的。源码位于 cmd/lib/python/main.go 和 cmd/lib/nodejs/main.go，它们都导出了一个名为 DifySeccomp 的 C 函数，内部调用对应语言的 InitSeccomp 函数。

编译时使用 -buildmode=c-shared 参数，Go 编译器会生成一个标准的 C 共享库，包含导出函数和对应的头文件。Python 通过 ctypes 加载，NodeJS 通过 koffi 加载，两者殊途同归。

这种设计将安全策略的实现与脚本语言解耦。安全策略用 Go 编写，编译为机器码，脚本语言只负责调用，用户代码无法篡改安全策略的实现。

1.7 依赖管理

沙箱的 Python 依赖管理分为三个部分：安装、环境准备和定期更新。

安装过程通过 pip3 命令执行，依赖列表从 dependencies/python-requirements.txt 文件中读取。当配置了 pip 镜像地址时，安装命令会自动添加镜像地址和对应的 trusted-host 参数，避免 SSL 证书验证失败。安装完成后，每个包的名称和版本会被记录到一个内存映射表中。

环境准备是将系统 Python 库文件拷贝到沙箱目录的过程。这一步通过一个名为 env.sh 的 Shell 脚本完成。该脚本的核心策略是：对于符号链接文件，直接拷贝链接本身；对于设备文件，拷贝后设为只读；对于普通文件，优先创建硬链接，如果硬链接失败则拷贝并设为只读权限。这种只读策略确保了沙箱中的代码无法修改运行时依赖的库文件。

定期更新通过一个后台 Goroutine 实现，默认每 30 分钟执行一次，重新安装依赖并刷新环境，保持沙箱中的依赖始终是最新的。

二、安全隔离机制的深度剖析

Dify-Sandbox 采用了多层纵深防御策略，从内核级别到应用级别逐层设防。下面由内而外逐一剖析。

2.1 Seccomp-BPF：内核级系统调用过滤

这是整个沙箱最核心、最根本的安全机制。

Seccomp（Secure Computing Mode）是 Linux 内核从 2.6.12 版本开始引入的安全特性。它允许进程在运行时为自己设置一个系统调用过滤器，限制自身可以调用的系统调用集合。Seccomp-BPF 是 Seccomp 的增强模式，它使用 Berkeley Packet Filter（BPF）规则来定义过滤策略，支持更细粒度的控制。

Dify-Sandbox 的 Seccomp 实现位于 internal/core/lib/seccomp.go。其工作原理如下：

首先，通过 libseccomp-golang 库创建一个过滤器，默认动作设为 ActKillProcess。这意味着任何未被显式允许的系统调用都会导致进程被内核直接杀死，而不是返回错误码。这是最严格的策略，不给攻击者任何试探的空间。

然后，将允许的系统调用添加为白名单规则，动作为 ActAllow。将需要返回错误但不杀进程的系统调用添加为灰名单规则，动作为 ActErrno。

接下来，将过滤规则导出为 BPF 字节码，通过 seccomp 系统调用加载到内核中。一旦加载，过滤规则就无法被撤销或修改，即使进程本身也无法绕过。

白名单中允许的系统调用经过了精心筛选，只包含运行 Python 或 NodeJS 所必需的最小集合。以 Python 为例，允许的系统调用分为以下几类：

文件 I/O 类包括 openat、read、write、close、lseek、getdents64、newfstatat、fstat、fcntl 和 ioctl。这些是 Python 解释器读取代码文件和库文件所必需的。其中 fstat 和 fcntl 在早期版本中仅在网络模式下允许，后来因为管道传输代码需要通过 fd 读取，这两个调用被提升到了基础白名单中。

内存管理类包括 mmap、brk、mprotect、munmap 和 mremap。Python 解释器的内存分配器依赖这些系统调用。

线程与进程类包括 futex、getpid、getppid、gettid、exit、exit_group、tgkill、sched_yield、set_robust_list 和 get_robust_list。Python 的线程和垃圾回收机制需要这些调用。

用户与组类包括 setgroups、setgid、setuid 和 getuid。这些用于在 Seccomp 激活后依次清除补充组、设置 GID 和降权 UID。其中 setgroups 是近期版本新增的，用于在降权前先清除进程的补充组，防止通过补充组保留意外权限。

时间类包括 clock_gettime、gettimeofday、nanosleep 和 time。Python 的 time 模块依赖这些调用。

信号类包括 rt_sigaction、rt_sigprocmask、rt_sigreturn 和 sigaltstack。Python 的信号处理机制需要这些调用。

灰名单中包含 clone、mkdirat 和 mkdir 三个系统调用。这些调用不会被允许执行，但也不会导致进程被杀，而是返回一个错误码。这样设计是因为某些 Python 库在初始化时可能会尝试调用这些函数，直接杀进程会导致不必要的执行失败。

网络相关的系统调用（socket、connect、bind、listen、accept、sendto、recvfrom 等）只有在 enable_network 为 true 时才会被加入白名单。这意味着在默认配置下，沙箱中的代码完全无法进行任何网络通信。

以下系统调用被严格禁止，一旦尝试调用会导致进程被杀：execve 和 execveat（禁止执行新程序）、fork 和 vfork（禁止创建子进程）、chroot 和 pivot_root（禁止修改文件系统根）、mount 和 umount（禁止挂载文件系统）、ptrace（禁止调试其他进程）、reboot（禁止重启系统），以及所有其他未在白名单中的系统调用。

这种默认拒绝的策略意味着攻击面被压缩到了极致。即使攻击者找到了某种漏洞，他也无法执行新程序、无法创建子进程、无法修改文件系统结构，甚至连尝试的机会都没有——进程会直接被内核杀死。

2.2 Chroot：文件系统隔离

Chroot 是 Unix 系统中一种传统的文件系统隔离手段，它将进程的根目录切换到指定目录，使进程无法访问该目录之外的文件。

在 Dify-Sandbox 中，Chroot 操作在 Seccomp 规则加载之前执行。这是必须的，因为 chroot 系统调用需要特权，而 Seccomp 生效后 chroot 会被禁止。

Python 和 NodeJS 的 Chroot 策略有所不同。

Python 的 Chroot 目标是 /var/sandbox/sandbox-python 目录。在沙箱服务启动时，env.sh 脚本已经将 Python 解释器运行所需的全部库文件拷贝到了这个目录中，并且所有文件都被设为只读权限。Chroot 后，Python 进程只能看到这个目录下的文件，无法访问系统中的其他任何路径。

NodeJS 的 Chroot 策略更加精细。它不是直接 Chroot 到一个固定目录，而是每次执行代码时都创建一个临时的隔离文件系统。Runner 会创建一个带有随机 UUID 的临时目录，然后将 NodeJS 运行所需的最小文件集合拷贝进去，包括 NodeJS 项目文件、seccomp 共享库、SSL 证书、DNS 配置和 hosts 文件。拷贝完成后，进程 Chroot 到这个临时目录。代码执行完毕后，整个临时目录会被删除。这种一次性文件系统的设计确保了不同执行任务之间的文件系统隔离。

2.3 UID 池与动态降权：用户权限隔离

即使攻击者突破了 Seccomp 和 Chroot 的限制，他仍然面临权限隔离的屏障。

在早期版本中，沙箱使用一个固定的 UID 65537 作为所有代码执行的运行身份。这种设计存在一个隐患：多个并发执行任务共享同一个 UID，意味着它们对文件系统拥有相同的访问权限。一个恶意代码虽然受限于 Chroot 和 Seccomp，但在共享的文件系统空间内，仍然可能干扰其他并发执行的代码。

当前版本引入了 UID 池机制来解决这个问题。UID 池的实现在 internal/core/runner/uidpool/uid_pool.go 中，它维护了一个范围从 10000 到 11000 的 UID 池，共 1000 个可用 UID。池的底层是一个带缓冲的 channel，Acquire 操作从 channel 中取出一个 UID，Release 操作将 UID 放回 channel。当池耗尽时，Acquire 会阻塞等待直到有 UID 被释放或上下文被取消。

每次代码执行时，Runner 从 UID 池中获取一个独立的 UID。引导脚本通过 chown 被设置为该 UID 所有，确保只有对应的沙箱进程才能读取。执行完毕后，UID 被归还到池中供后续任务复用。

UID 池还在 /etc/passwd 中预创建了所有 UID 的条目。这一步看似多余，实则解决了一个实际问题：Python 解释器在清理资源时会调用 getpwuid 函数查询用户信息，如果 /etc/passwd 中没有对应的条目，getpwuid 可能会触发一些被 Seccomp 阻止的系统调用（例如尝试通过 NSS 模块查询用户），导致进程被杀。预创建 passwd 条目避免了这个问题。

当 UID 池耗尽时，Service 层会返回 -429 错误码，表示并发资源不足，而不是让请求无限等待。

2.4 权限降级的正确顺序

在 Seccomp 规则加载之后，进程需要从 root 降权到沙箱用户。这个降权过程看似简单，实则顺序至关重要。近期版本对降权顺序做了一次重要修复。

正确的降权顺序是：setgroups、setgid、setuid。

第一步是 setgroups，将进程的补充组列表清空。如果不清除补充组，进程可能通过补充组成员身份保留意外的权限。例如，如果进程属于某个特权组，即使 UID 已经降权，组权限仍然有效。

第二步是 setgid，将进程的 GID 设置为目标组。setgid 必须在 setuid 之前调用，因为一旦 UID 改变，进程可能失去设置 GID 的权限。

第三步是 setuid，将进程的 UID 设置为从 UID 池获取的沙箱用户。

早期版本的降权顺序是先 setuid 再 setgid，这是不正确的。因为 setuid 改变 UID 后，进程可能不再拥有设置 GID 的权限，导致 setgid 调用失败。虽然在实际运行中由于 Seccomp 白名单包含了这些调用，降权通常能够成功，但顺序不正确意味着在某些边界条件下可能出现权限残留。当前版本将顺序修正为 setgroups、setgid、setuid，确保了权限的彻底剥离。

Seccomp 白名单中也相应地添加了 setgroups 系统调用，使得这一步可以在 Seccomp 规则加载之后执行。

2.5 NO_NEW_PRIVS：防止提权

NO_NEW_PRIVS 是 Linux 内核从 3.5 版本开始引入的安全特性，通过 prctl 系统调用的 PR_SET_NO_NEW_PRIVS 选项设置。

设置 NO_NEW_PRIVS 后，当前进程及其所有子进程都无法通过 execve 调用获得比当前更多的权限。这意味着 SUID 位和 SGID 位不会生效，文件能力（capabilities）也不会被授予。

在 Dify-Sandbox 中，NO_NEW_PRIVS 在 Seccomp 规则加载之前设置，位于 Chroot 之后。这个顺序确保了：即使攻击者通过某种方式执行了一个设置了 SUID 位的程序（虽然 Seccomp 已经禁止了 execve），也无法通过 SUID 机制提权。NO_NEW_PRIVS 是一个不可逆的操作，一旦设置就无法撤销。

2.6 管道传输代码：消除磁盘窥探风险

用户代码如何安全地传递给沙箱进程，是沙箱设计中的一个关键问题。

在早期版本中，Python Runner 采用 XOR 加密方案：生成随机密钥，将用户代码加密后写入临时文件，密钥通过命令行参数传递。NodeJS Runner 则使用 Base64 编码加 eval 的方式，将编码后的代码直接拼接到脚本中。这两种方案都存在一个共同的问题：用户代码的某种形式（即使是加密或编码后的）会出现在磁盘上的临时文件中。

当前版本用管道传输方案彻底解决了这个问题。Runner 在创建子进程时，通过 os.Pipe() 创建一对匿名管道，将读端作为子进程的额外文件描述符（fd 3）传入。子进程启动后，Runner 在一个独立的 Goroutine 中将用户代码明文写入管道的写端，写完后关闭写端。子进程从 fd 3 读取代码并执行。

管道传输的优势在于：用户代码的明文只存在于父进程的内存和内核的管道缓冲区中，从不写入磁盘。即使攻击者能够读取文件系统，也无法获取用户代码。同时，管道是一个一次性的数据通道，读完后数据就消失了，不存在残留风险。

这个改动也影响了 Seccomp 的白名单配置。因为 Python 需要通过 fd 读取代码，而读取管道需要 fstat 和 fcntl 等系统调用来检查文件描述符的状态，所以这两个调用从网络专属白名单被提升到了基础白名单中。

2.7 环境变量清空：防止敏感信息泄露

当 Runner 创建子进程时，它会将子进程的环境变量设为空数组。这意味着子进程不会继承父进程的任何环境变量，包括可能包含的数据库密码、API Key、路径信息等敏感数据。

只有在特定条件下，才会向环境变量中添加必要的配置：当配置了代理时，会添加 HTTP_PROXY 和 HTTPS_PROXY 变量；当配置了自定义系统调用白名单时，会添加 ALLOWED_SYSCALLS 变量。除此之外，不添加任何其他环境变量。

2.8 超时与资源控制：防止资源耗尽

每个代码执行任务都有一个超时时间，默认为 5 秒。Runner 在启动子进程的同时会设置一个定时器，超时后直接向进程发送 Kill 信号。

在输出捕获方面，Runner 通过管道分别捕获子进程的标准输出和标准错误，使用独立的 Goroutine 异步读取。当进程退出后，如果退出码非零且包含 “bad system call” 字样（这是 Seccomp 拦截系统调用时的典型错误信息），会将错误信息替换为 “operation not permitted”，避免向用户暴露内核层面的细节。

Service 层在收集输出时采用了 drain 模式：当收到 done 信号后，会继续从 stdout 和 stderr 通道中读取所有剩余数据，确保不会因为通道缓冲而丢失输出。

2.9 API Key 认证：防止未授权访问

沙箱服务的所有业务接口都位于 /v1/sandbox/ 路径下，需要通过 Auth 中间件校验 API Key。请求头中必须包含 X-Api-Key 字段，且值必须与配置文件中的 key 一致，否则返回 401 状态码。

这个机制确保了只有 Dify 主服务才能调用沙箱执行代码，防止外部攻击者直接向沙箱提交恶意代码。

2.10 Preload 安全控制

预加载脚本（preload）允许在用户代码执行前运行一段初始化代码。这个功能看似方便，实则暗藏风险：preload 脚本在 Seccomp 激活之前执行，此时进程仍拥有完整权限，如果 preload 中包含恶意代码，可能绕过安全限制。

因此，Dify-Sandbox 默认将 EnablePreload 设为 False。当该选项为 False 时，Service 层会将 preload 参数强制清空，即使调用方传入了 preload 内容也不会执行。管理员只有在充分了解风险的情况下才应启用此功能。

三、安全策略的执行顺序

理解各层安全机制的执行顺序对于评估沙箱的整体安全性至关重要。在 InitSeccomp 函数中，各步骤的执行顺序如下：

第一步，Chroot 切换根目录。这一步需要特权，必须在 Seccomp 之前完成。

第二步，设置 NO_NEW_PRIVS。这一步同样需要特权，且必须在 setuid 之前完成，否则 setuid 后可能无法成功设置。

第三步，加载 Seccomp-BPF 规则。一旦加载，进程的系统调用空间被锁定，后续只能执行白名单中的系统调用。

第四步，setgroups 清除补充组。这是降权的第一步，确保进程不会通过补充组成员身份保留意外权限。

第五步，setgid 设置组 ID。必须在 setuid 之前执行，因为 UID 改变后可能失去设置 GID 的权限。

第六步，setuid 设置用户 ID。这是降权的最后一步，执行后进程完全失去 root 权限。

这个顺序形成了一个单向的安全递进链：每一步都依赖于前一步的完成，且每一步完成后都缩小了后续步骤的权限空间。一旦 Seccomp 加载，进程就被锁死在安全边界内，再也无法回头。而降权顺序从 setgroups 到 setgid 再到 setuid，确保了权限被彻底、干净地剥离，不留任何残留。

四、近期版本的安全演进

Dify-Sandbox 的安全设计并非一蹴而就，而是在持续迭代中不断加固。0.2.15 版本中的几项修复尤其值得关注，它们代表了沙箱安全设计的重要演进。

4.1 从磁盘写入到管道传输

早期版本将用户代码写入临时文件，虽然 Python 通过 XOR 加密提供了一定程度的保护，但代码的某种形式仍然存在于磁盘上。管道传输方案从根本上消除了这一风险，用户代码的明文只存在于内存和内核管道缓冲区中，从不触碰磁盘。这是一个从"降低风险"到"消除风险"的质变。

同时，管道传输也简化了实现。不再需要生成随机密钥、进行 XOR 加密、通过命令行传递密钥、在脚本中解密这一系列复杂步骤。代码直接通过管道发送，子进程直接从 fd 读取，逻辑更清晰，攻击面更小。

4.2 从固定 UID 到 UID 池

固定 UID 意味着所有并发执行任务共享同一个用户身份。虽然 Chroot 和 Seccomp 已经提供了很强的隔离，但在共享的文件系统空间内，相同 UID 的进程仍然拥有相同的文件访问权限。UID 池为每次执行分配独立的 UID，配合 chown 将引导脚本设为该 UID 所有，实现了并发任务之间的用户级隔离。

UID 池还带来了一个额外的好处：通过限制池的大小（默认 1000 个 UID），自然地限制了最大并发执行数。当池耗尽时，新的执行请求会收到 429 错误，而不是无限制地排队。

4.3 降权顺序的修正

从 setuid-setgid 到 setgroups-setgid-setuid 的修正，看似只是调整了三行代码的顺序，实则修复了一个潜在的安全隐患。在 Linux 的权限模型中，降权顺序至关重要：先清组、再设组、最后设用户。任何顺序颠倒都可能导致权限残留。这个修复体现了对 Linux 权限模型更深入的理解。

4.4 Seccomp 白名单的调整

管道传输代码需要从 fd 读取数据，这要求 fstat 和 fcntl 系统调用在基础白名单中可用。同时，setgroups 的引入也要求将其加入白名单。这些调整展示了 Seccomp 白名单配置与功能实现之间的紧密耦合：每一个新功能都需要仔细评估其对系统调用的需求，并在白名单中做出最小化的调整。

五、架构设计的思考

Dify-Sandbox 的架构设计有几个值得学习的点：

将安全策略编译为 C 共享库是一个精妙的设计。安全策略的核心逻辑用 Go 语言编写，编译为机器码形式的 .so 文件，脚本语言只通过 FFI 调用。这意味着用户代码运行在脚本语言的解释器中，而安全策略以机器码的形式存在于进程的地址空间中，用户代码无法通过脚本语言层面的手段篡改安全策略的实现。

管道传输代码彻底消除了磁盘窥探的风险。用户代码的明文只存在于内存中，从不写入磁盘。相比早期的 XOR 加密方案，管道传输不仅更安全，也更简洁，减少了攻击面。

以及Seccomp 策略，ActKillProcess 作为默认动作意味着任何不在白名单中的系统调用都会导致进程被杀，不给攻击者任何容错空间。这种设计虽然可能导致某些合法但未预料到的系统调用被拦截，但从安全角度看，宁可误杀也不可漏放。

UID 池实现了并发任务之间的用户级隔离。每次执行使用独立的 UID，配合 chown 和 Chroot，构建了从用户身份到文件系统的双重隔离。

六、结语

Dify-Sandbox 展示了一个生产级代码沙箱应该如何设计和演进。它没有依赖单一的安全机制，而是通过 Seccomp、Chroot、UID 池与动态降权、NO_NEW_PRIVS、管道传输代码、环境变量清空、超时控制、API 认证和 Preload 限制多层防御，构建了一个纵深安全体系。其中 Seccomp-BPF 是最核心的防线，它在 Linux 内核层面以默认拒绝的策略过滤系统调用，确保即使其他防线被突破，恶意代码也无法做出越权行为。

从版本演进中可以看到，安全设计是一个持续加固的过程。从磁盘写入到管道传输、从固定 UID 到 UID 池、从错误的降权顺序到正确的 setgroups-setgid-setuid，每一项修复都代表了对安全模型更深入的理解。这种多层防御，通过多层互补的防御策略和持续的安全审计，在多租户环境以及Linux系统，应该是除了使用VM之外最安全的机制了。