在Fedora Linux上使用微虛擬機沙盒化AI編程代理

AI編程代理（如Claude Code或Codex）每月都在變得更加強大，這無疑提升了生產力。然而，批准每一個命令很快變得令人厭煩。另一方面，允許代理在工作機器上隨意運行任何命令並非明智之舉——它們非常擅長使用kubectl探索你的生產集羣，或通過SSH在生產服務器上遠程執行命令。

幸運的是，Linux發行版提供了豐富的進程隔離選項。你可以將代理作為完全不同的用户運行，放在容器中，或部署在虛擬機裏。本文展示瞭如何使用微虛擬機（microVM）來沙盒化編程代理。

安全擔憂

以無人值守模式運行AI代理類似於運行不可信代碼。儘管Anthropic或Google等公司並不試圖竊取憑據，但人們不斷提出新的攻擊向量，例如Slopsquatting或幾乎無處不在的提示注入。

編程代理本身帶有內置緩解措施，試圖拒絕提示注入。例如，輕量級沙盒技術（如Linux上的bwrap）是另一層防禦。但這仍然存在沙盒逃逸的問題，例如CVE-2026-39861就展示了跨平台沙盒逃逸。

容器可以將代理隔離在自己的命名空間中，但它們仍共享宿主內核。最近的內核漏洞導致了權限提升（從普通用户切換到root），表明容器作為安全邊界並不足夠。

探索微虛擬機

首先，讓我們瞭解什麼是微虛擬機。與任何虛擬機一樣，它們擁有自己的內核，每個微虛擬機一個。與傳統虛擬機相比，它們啓動時間極短（數百毫秒），但缺乏完整虛擬機的所有功能。

本文介紹了Podman的krun運行時用法。該方法提供了與容器相同的工作流程，但將每個容器作為微虛擬機運行。首先安裝運行時：

dnf install crun-krun

要運行微虛擬機，只需在終端中執行帶--runtime=krun的Podman命令：

podman run --runtime=krun --rm -it fedora:44 /bin/bash

注意事項

微虛擬機不是普通容器，因此一些行為可能不同。首先，使用krun註解分配足夠的CPU和RAM；默認值過小可能導致OOM（內存不足）殺死。其次，確保libkrun版本≥1.8；舊版本有阻止編程代理中按Enter鍵的bug。第三，微虛擬機忽略Dockerfile中的USER指令，始終以root身份啓動。需要手動切換用户或在入口腳本中設置。

案例研究：為Python項目沙盒化Claude Code

本節概述了一個使用uv管理的Python項目的簡單設置。它使用podman-compose將項目掛載到微虛擬機中。與容器相比，此podman-compose需要額外的UID/GID轉換、SELinux標籤和硬件資源註解。最終設置與容器所需的非常相似。

安裝podman-compose：

dnf install podman-compose

設置包含三部分：Dockerfile、docker-compose.yaml和entrypoint.sh。

Dockerfile：基於Fedora:44，創建與宿主UID/GID匹配的非特權用户，安裝uv和Claude Code，複製入口腳本。注意將USER appuser放在最後，但krun會忽略它，因此入口腳本會處理用户切換。

docker-compose.yaml：定義服務claude，註解選擇krun運行時並指定硬件資源，設置user: "${HOST_UID}:${HOST_GID}"和userns_mode: keep-id實現UID/GID映射。卷標籤U,z分別處理遞歸chown和SELinux重新標記。

entrypoint.sh：檢查當前用户，若不是appuser則先運行uv sync然後切換到appuser執行命令；若是appuser則直接執行。

運行設置

構建容器：

$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml build

創建外部卷並交互運行：

$ podman volume create claude-config
$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml run --rm claude

進入微虛擬機後，可通過uname -a檢查內核差異。

自動化腳本

可通過簡單腳本將上述設置封裝為sandbox命令，支持init、build和run三個子命令。

警告：微虛擬機並非絕對安全

微虛擬機顯著提高了門檻，但並非完美隔離。請查閲libkrun安全模型文檔。對於可能危險的軟件，建議使用完整虛擬機或雲虛擬機。

結論

微虛擬機似乎是運行AI代理的“甜點”。它們提供了熟悉的容器工作流，但代理運行在超管理器背後的獨立內核上。本文基於Fedora Linux原生支持的Podman和krun運行時，但其他平台也有眾多選項（例如dockersandbox）。

注意：本文由作者親自撰寫，使用Claude（Anthropic）優化語法和措辭，技術內容和所有聲明均為作者本人所有並經過測試。