Files

7.1 KiB
Raw Permalink Blame History

tags, create time
tags create time
test/review
ai
agent-design
sandbox
2026-08-09 12:00

沙箱权限治理 — 测试题

概述

本测试覆盖代码执行隔离方案(Docker/gVisor/Wasm/Firecracker)、资源限制四层架构、工具白名单设计、审计日志规范以及 Prompt Injection 纵深防御策略。共 10 道题目(6 选择 + 3 填空 + 1 简答)。


一、选择题(6道,由浅入深)

难度阶梯: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景

Q1(基础)— 考察定义层面

以下哪种代码执行隔离方案的启动速度最快?

A. Docker 容器(~2s) B. gVisor(~500ms) C. WebAssembly / Wasm(~10ms) D. Firecracker MicroVM(~125ms)

Q2(基础)→

沙箱的 Docker 核心配置中,ReadOnlyRootFilesystem: true 和 NetworkMode: "none" 的主要作用是什么?

A. 提高执行速度 B. 防止恶意代码修改宿主文件系统并切断外网访问 C. 增加内存上限 D. 自动重启异常进程

Q3(进阶)— 核心原理

工具白名单设计的核心理念是:

A. 拦截所有包含危险关键词的工具调用 B. 黑名单模式——列出禁止调用的工具 C. 白名单模式——显式声明允许的工具,其余全部拒绝 D. 让 LLM 自己判断该调用哪个工具

Q4(进阶)— 比较/辨析

关于防 Prompt Injection 的三层防御,以下哪个匹配是错误的?

A. 层级一(系统提示注入检测)— 分隔符保护、角色隔离、指令优先级 B. 层级二(用户输入净化)— 关键字过滤、长度限制、转义特殊字符 C. 层级三(行为防护)— 工具调用二次确认、输出过滤、速率限制 D. 单层分隔符保护足以完全防御所有 Prompt Injection 攻击

Q5(深入)— 场景推理

一个 Agent 需要执行用户提供的 Python 代码并返回结果。以下安全配置组合最合理的是:

A. 普通 Linux 进程 + 无网络限制 + 无限时 B. Docker 容器只读文件系统 + 无特权 + 切断网络 + 256MB 内存上限 + 10s 超时 C. Wasm + 只读文件系统 + 有完整网络访问权 + 1h 超时 D. 直接在宿主机上运行用户代码,加一个 kill -9 的兜底脚本

Q6(深入)— 源码级/边界场景

关于审计日志的设计,以下哪个字段不是必须的?

A. trace_id — 一次对话的唯一标识 B. timestamp — ISO8601 精确到毫秒 C. user_id — 发起者身份 D. model_version — LLM 的具体版本号


二、填空题(3道)

F1 — 填空1

资源限制分为四层,每层针对不同类型的 DoS 风险:时间维度用_____控制强制中断无限循环;CPU 维度用 CFS Quota 限制计算占比;内存维度用 cgroup limit 配合 OOM Killer 兜底;网络维度用 eBPF 策略做白名单域名 + 内网隔离。

提示: 第一个空对应原文时间维度的关键词。

F2 — 填空2

防 Prompt Injection 的核心原则是纵深防御:至少_____层组合形成互补。没有任何单一手段能完全防御。具体来说,层级一是系统提示注入检测(_____保护),层级二是用户输入净化(关键字过滤),层级三是行为防护(高危操作需人工审批)。

提示: 第一空填数字,第二空填一种技术名称。

F3 — 填空3

工具调用必须使用结构化 JSON 而不是自然语言的原因有三点:① 可被程序化校验;② 参数类型明确不需要_____解析;③ IDE 可提供自动补全和 schema hint 提高 LLM 出参准确率。

提示: 第二个原因中的技术缩写。


三、简答题(1道)

S1

某 AI 编程助手项目允许 Agent 执行用户的代码片段以提供实时反馈。请设计一个完整的安全治理方案,要求涵盖:

  1. 执行环境的隔离方案选型及理由
  2. 资源限制的四层设计
  3. 工具调用白名单策略
  4. 审计追踪与告警机制

答题框架提示:

  1. 各层的防护目标
  2. 方案间的依赖关系
  3. 异常场景的应急处理

参考答案与解析

选择题答案

题号 正确答案 解析
Q1 C Wasm 启动只需约 10ms,远超 Docker(~2s)和 gVisor(~500ms)。但代价是不支持文件系统操作——适合纯计算场景。Firecracker ~125ms 是最快的虚拟机方案。
Q2 B 只读文件系统防止恶意代码写入或修改文件;NetworkMode: none 切断外网阻止数据外泄。这两项是沙箱的基础安全屏障。
Q3 C 白名单设计理念:不依赖黑名单拦截(总有漏网之鱼),而是显式声明允许的工具,其余全部拒绝。这是一种零信任思路。
Q4 D D 是错误的!没有任何单一手段能完全防御 Prompt Injection。分层防御才是正道——至少三层组合形成互补。
Q5 B Docker 容器提供最全面的隔离能力:只读文件系统、无特权、断网、内存/CPU 限制、超时控制。Wasm 不支持文件系统不适合需要写文件的操作。直接宿主运行完全没有安全保障。
Q6 D 审计日志的核心字段是 trace_id、timestamp、user_id、tool_name、input_snapshot、output_snapshot、result_status、latency_ms、cost_tokens。model_version 虽有用但不是必记字段。

填空题答案

题号 答案 解析
F1 超时控制 四层资源限制的典型值:全局超时≤30s,子任务超时≤10s,单步超时≤5s。外层自动取消内层上下文。
F2 三;分隔符 纵深防御至少三层:分隔符保护阻止指令混淆,关键字过滤拦截已知 injection patterns,行为防护限制实际损害。
F3 NLP 结构化 JSON 避免了自然语言的歧义性。LLM 输出的 tool_call JSON 可以被 Schema Validator 和 Policy Engine 程序化检查参数格式、工具名是否在白名单、用户是否有权限。

简答题参考答案

S1:参考答案要点:

  1. 隔离方案:选 Docker 容器而非 Wasm(需要文件系统操作支持),也非 gVisor(Google Cloud 专属)。核心配置:只读根文件系统、Privileged=false、NetworkMode=none、内存/CPU 限制、10s 超时。
  2. 四层限制:超时控制(全局30s/子任务10s/单步5s)+ CFS Quota(0.5 CPU)+ cgroup 内存上限(256MB)+ eBPF 网络白名单。
  3. 白名单策略:预注册 8 个 Tool(代码生成、Git 操作、文档搜索等),Tool Calling Schema 通过 JSON Schema validator 校验参数格式,Policy Engine 检查工具名和权限。
  4. 审计与告警:每次工具调用记录 trace_id/timestamp/user_id/tool_name/input/output/result/latency/cost。写入 Elasticsearch 支持按 trace_id 回溯。设置 RateLimit/SecurityAlert/PerformanceAlert 三类告警。
  5. 应急处理:检测到异常时立即终止容器、冻结该用户的所有 token、通知安全团队介入。

评分标准:答出任意 2 个要点即可得满分;完全正确需覆盖全部要点。

关联笔记