147 lines
7.1 KiB
Markdown
147 lines
7.1 KiB
Markdown
---
|
||
tags: [test/review, ai, agent-design, sandbox]
|
||
create time: 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 个要点即可得满分；完全正确需覆盖全部要点。
|
||
|
||
## 关联笔记
|
||
- [[Eino DAG 工作流设计]]
|
||
- [[循环状态机在Agent中的应用]]
|