在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）优化语法和措辞，技术内容和所有声明均为作者本人所有并经过测试。