判题沙箱的安全隔离方案：Docker 容器 vs 系统调用限制的对比

判题沙箱的安全隔离方案：Docker 容器 vs 系统调用限制的对比

一、深度引言与场景痛点：当用户的代码在你的服务器上运行时

在线判题系统的核心风险只有一个：你无法信任用户提交的代码。一段看似正常的算法解法，可能包含 Runtime.getRuntime().exec("rm -rf /")，可能在循环中疯狂申请内存直到 OOM，也可能通过反向 Shell 尝试突破网络隔离。

作为一个实习生，当 mentor 把判题沙箱的设计任务交给我时，我第一反应是"这有什么难的，起个 Docker 容器跑一下不就行了"。但真正动手之后才发现，沙箱设计的核心矛盾在于：安全性越高，启动开销越大，用户体验越差。在线判题的场景要求秒级甚至毫秒级的反馈，而完整容器启动动辄数百毫秒——这个延迟差是不可接受的。

本文将对比两种主流沙箱方案：Docker 容器隔离与 Linux 系统调用级限制，结合实验数据分析各自的适用场景。

二、底层机制与原理深度剖析

Docker 容器隔离的核心机制

Docker 的隔离不是魔法，它依赖 Linux 内核的以下机制：

• Namespace：提供进程、网络、挂载点、IPC、UTS、用户等资源的视图隔离。判题容器看到的 / 根目录实际上是宿主机上的一个 overlay 层。
• Cgroups：限制容器可使用的 CPU、内存、IO 和网络带宽。这是防止恶意代码耗尽宿主机资源的关键。
• Seccomp：限制容器内进程可调用的系统调用。默认的 Docker seccomp profile 禁用了约 44 个危险系统调用（如 reboot、kexec_load）。

进程级系统调用限制的核心机制

不依赖容器的方案直接在宿主机上限制子进程的行为：

• setrlimit：限制进程的资源使用上限（CPU 时间、内存、文件描述符数等）
• seccomp-bpf：通过 BPF 过滤器精确控制允许的系统调用列表
• chroot / pivot_root：改变进程的根目录视图
• cgroups 直接挂载：不经过 Docker daemon，直接操作 cgroup 文件系统

两种方案的本质区别在于：Docker 方案隔离的是整个运行时环境（包括网络、文件系统、用户空间），进程级方案隔离的是单个进程的系统资源。前者的安全边界更厚，后者的启动开销更低。

三、生产级代码实现与最佳实践

方案 A：Docker 容器判题

// Docker 容器判题 —— 隔离性强，但启动开销大
public class DockerJudge {
private final DockerClient dockerClient;

public ExecuteResult execute(String code, TestCase testCase) {
// 1. 创建临时容器 —— 这里是性能瓶颈所在
// 每个请求创建 + 销毁容器的开销约 300~800ms
String containerId = dockerClient.createContainer(
CreateContainerCmd.builder()
.image("judge-sandbox:latest") // 预装编译环境的镜像
.cmd("sh", "-c", compileAndRun(code))
.memory(256 * 1024 * 1024L) // 限制 256MB 内存
.cpuPeriod(100000L) // CFS 调度周期
.cpuQuota(50000L) // 限制使用 0.5 核 CPU
.networkDisabled(true) // 禁用网络，防止反向 Shell
.readOnlyRootfs(true) // 根文件系统只读
.tmpfs("/tmp") // /tmp 使用内存文件系统
.build()
);

dockerClient.startContainer(containerId);

// 2. 设置超时等待 —— 防止死循环一直占用容器
boolean finished = dockerClient.waitContainer(containerId, 10, TimeUnit.SECONDS);

if (!finished) {
dockerClient.killContainer(containerId); // 超时强制杀死
return ExecuteResult.timeout();
}

// 3. 收集执行结果
String output = dockerClient.getContainerLogs(containerId);
Long exitCode = dockerClient.inspectContainer(containerId).getState().getExitCode();

// 4. 清理容器 —— 不清理会导致磁盘空间被占满
dockerClient.removeContainer(containerId, RemoveContainerCmd.builder().force(true).build());

return ExecuteResult.of(exitCode, output);
}
}

方案 B：进程级系统调用限制

// 进程级隔离判题 —— 启动快，但需要精细的系统调用白名单
public class ProcessJudge {
// 允许的系统调用白名单 —— 仅保留编译执行必要的调用
// 任何不在白名单中的系统调用都会被 seccomp 拦截
private static final Set<Integer> ALLOWED_SYSCALLS = Set.of(
// 进程控制
SeccompConstants.SYS_READ, SeccompConstants.SYS_WRITE,
SeccompConstants.SYS_EXIT, SeccompConstants.SYS_EXIT_GROUP,
// 内存管理
SeccompConstants.SYS_MMAP, SeccompConstants.SYS_MUNMAP,
SeccompConstants.SYS_BRK,
// 文件操作
SeccompConstants.SYS_OPEN, SeccompConstants.SYS_CLOSE,
SeccompConstants.SYS_FSTAT, SeccompConstants.SYS_READLINK,
// 时间相关
SeccompConstants.SYS_CLOCK_GETTIME,
SeccompConstants.SYS_NANOSLEEP
);

public ExecuteResult execute(String compiledBinary, TestCase testCase) {
ProcessBuilder pb = new ProcessBuilder(compiledBinary);
pb.redirectErrorStream(true); // 合并 stderr 到 stdout

Process process = pb.start();

// 通过 stdin 传入测试用例输入
try (OutputStream stdin = process.getOutputStream()) {
stdin.write(testCase.getInput().getBytes());
stdin.flush();
}

// 设置截止时间 —— 单次判题的硬性时间上限
CompletableFuture<ExecuteResult> future = CompletableFuture.supplyAsync(() -> {
try {
String output = new String(process.getInputStream().readAllBytes());
int exitCode = process.waitFor();
return ExecuteResult.of(exitCode, output);
} catch (Exception e) {
return ExecuteResult.error(e.getMessage());
}
});

try {
// get(timeout) 是这里的核心保障：即使代码死循环，也会被强制中断
return future.get(5, TimeUnit.SECONDS);
} catch (TimeoutException e) {
process.destroyForcibly(); // SIGKILL 强制终止
return ExecuteResult.timeout();
}
}
}

// seccomp-bpf 规则的底层配置 —— 使用 libseccomp 库
// 编译方式：gcc -lseccomp sandbox.c -o sandbox
#include <seccomp.h>
#include <stdio.h>

void setup_seccomp_filter() {
scmp_filter_ctx ctx;

// 1. 创建 seccomp 上下文，默认动作为杀死进程
ctx = seccomp_init(SCMP_ACT_KILL);

// 2. 逐个添加允许的系统调用
// 每个系统调用都需要显式允许，遵循最小权限原则
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(mmap), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(munmap), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(openat), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(close), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(fstat), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(clock_gettime), 0);

// 3. 加载规则到当前进程
seccomp_load(ctx);
seccomp_release(ctx);
}
// 说明：这份规则设置在当前进程中生效，子进程 fork 后会继承这些限制
// 对于 C/C++ 判题，需要在 execve 之前调用此函数

四、边界分析与架构权衡

性能对比数据

什么时候选 Docker？

• 系统需要对外开放，用户群体不可信
• 需要支持多种运行时环境（Python 3.8/3.9/3.10 并行）
• 运维团队有 Docker/K8s 经验，能快速排查容器问题

什么时候选进程级？

• 内部系统或小范围使用，恶意代码风险可控
• 对判题延迟有严格要求（<100ms）
• 需要精细控制每个判题进程的资源占用
• 判题服务需要频繁扩缩容（容器启动慢影响弹性）

不推荐的方案

有些初版实现会直接把用户代码在宿主机 eval 或 exec 执行——这是绝对禁止的。即使是内部系统，也不应该有任何不做隔离直接执行用户代码的环节。安全不是"先上线，有空再修"的事情。

五、总结

判题沙箱的设计本质上是在安全性与性能之间做取舍。Docker 提供的是"重隔离"，用几百毫秒的启动开销换取高安全边界；进程级方案提供的是"轻隔离"，用更复杂的实现换取更低的延迟。

从实践角度看，建议的路线是：

最重要的是：永远不要相信用户提交的代码。哪怕是一行 print("hello")，也要当作潜在的恶意代码来对待。