企业官网建设流程全解析

ATLAS沙箱如何保护你的机器？多语言隔离执行、只读根文件系统与资源上限原理详解

【免费下载链接】ATLASAdaptive Test-time Learning and Autonomous Specialization项目地址: https://gitcode.com/gh_mirrors/atlas112/ATLAS

ATLAS 沙箱（sandbox）是这套本地 AI 编程助手中专门负责"执行 AI 生成的代码"的隔离容器。当 AI 代理（agent）帮你写代码后想运行、测试、验证时，所有代码都发生在沙箱容器内部，而不是你的本机——这意味着即使 AI 写出了危险代码，最坏的影响也只限于你自己的项目文件夹。本文用尽量少的技术细节，讲清楚 ATLAS 沙箱是如何通过多语言隔离执行、只读根文件系统（read-only rootfs）和资源上限这三道防线保护你的机器的。

为什么 AI 编程助手需要一个代码沙箱？

让 AI "自己验证自己写的代码"是提升正确率的关键手段：写完代码 → 运行测试 → 看报错 → 修复 → 再运行。但这也意味着机器上会执行由模型生成的代码和 shell 命令。如果不加隔离，一个失控的循环、一次rm -rf、一个无限 fork 的进程都可能伤及你的系统文件。

ATLAS 的思路很直接：

• 不信任任何来自模型的代码，一律放进独立容器执行；
• 容器内部按"最小权限"加固：只读系统盘、非 root 用户、零能力（capabilities）、资源配额；
• 真正想让 AI 改的文件，只有你的项目目录一个可写挂载点。

用项目源码注释里的一句话概括："这个服务本身就是信任边界（trust boundary）"——隔离不是靠应用层代码层层过滤实现的，而是靠容器本身强制执行的（见 sandbox/executor_server.py 文件头的安全模型说明）。

多语言隔离执行：12 种语言，统一入口

ATLAS 沙箱内置了一个 FastAPI 服务 executor_server.py，对外提供三个核心能力：

镜像 sandbox/Dockerfile 把常用工具链一次性烤进镜像，支持 12 种语言：

这里有个值得注意的设计取舍：因为容器是只读 + 非 root的，运行时根本无法apt install任何东西。所以所有"编码任务里常见的命令"（git、sqlite3、jq、patch、zip、7z等）都必须预先装进镜像——宁可镜像大一点，也不留"运行时安装"的口子。

另外，沙箱还做了两件"防泄漏"的小事：

• 超时即整组杀掉：每次执行都在独立进程会话中启动，超时后对整个进程组发SIGKILL，命令派生的子进程一个都逃不掉（_run_cmd）；
• 输出截断：stdout 最多保留 4000 字符、stderr 2000 字符，防止一段失控输出撑爆上下文；后台任务则用环形缓冲（每流 500 行）+ 32 个任务硬上限 + 2 小时废弃强杀（executor_server.py）。

只读根文件系统 + 非 root：改动只能落在项目里

这是 ATLAS 沙箱最核心的一道防线，配置就在 docker-compose.yml 的sandbox服务里（第 254-275 行）：

read_only: true # 整个容器文件系统只读 security_opt: - no-new-privileges:true # 禁止进程提权 user: "${ATLAS_SANDBOX_UID:-1000}:..." # 非 root 用户运行 cap_drop: - ALL # 丢弃全部 Linux capabilities

配合挂载策略，沙箱内部的世界是这样的：

1. 根文件系统只读——AI 无法安装软件、改系统配置、替换二进制；
2. /workspace是唯一可写的主机挂载点，指向你的项目目录（ATLAS_PROJECT_DIR），所以任何命令的"爆炸半径（blast radius）"就是项目文件夹本身；
3. 所有需要写的地方用 tmpfs 临时内存盘：/tmp（2G）、pip 的.local（1G）、npm/cargo/go/maven/gradle 等各类缓存目录各 256M–512M（docker-compose.yml）。这些盘随容器重启即清空——依赖可以临时装进来用，但不会在磁盘上留任何痕迹，pip install也能正常工作；
4. API 端口只绑定127.0.0.1，且请求需要内部服务令牌（Bearer token，atlas init生成）才能调用/shell和/execute（executor_server.py），沙箱不对外网暴露。

简单说：AI 拿到的是一台"装好了所有语言工具、但除你的项目外什么都写不了"的一次性电脑。

资源上限：内存、CPU、进程数三重封锁

即使代码"合法"，也可能耗尽资源。ATLAS 在容器层面设置了硬性配额：

其中pids_limit值得单独强调：fork 炸弹（while :; do : &; done一类）不消耗多少内存，靠内存限制是拦不住的，必须由内核的进程数上限来兜底。运行atlas init时，向导会自动探测主机配置，把约 75% 的内存和核心数写入.env，让配额既够用又不失控（详见 docs/CONFIGURATION.md）。

Shell 命令守护：只拦"毁灭级"操作

除了容器这道硬边界，代理层 proxy/guardrails.go 还有一个前置检查validateShellCommand，在命令到达沙箱之前拦截少数几类毁灭性命令：

• 清空根/整个项目的删除：rm -rf /、rm -rf .、rm -rf *（但rm -rf build、rm -rf node_modules这类针对具体子目录的删除是允许的）；
• fork 炸弹模式；
• 块设备破坏：dd of=/dev/sdX、mkfs、wipefs、重定向到/dev/*磁盘设备（guardrails.go）；
• 用bash -c "…"/eval/env/sudo包装来绕过的命令会被逐层拆包后再检查，最多拆 16 层，拆不动就直接拒绝（proxy/shell_wrapper.go）。

设计哲学是"容器是真正的边界，正则只做体验补充"：即便模型找到了正则的漏洞，也只会在只读、配额受限的容器里折腾，伤不到主机。

安全模型速查清单

小结

ATLAS 沙箱的安全设计可以浓缩成一句话：用容器强制执行的最小权限边界，替代对"AI 会写什么"的猜测——12 种语言工具链开箱即用，但系统盘只读、非 root 运行、进程/内存/CPU 全部封顶，唯一能碰到的主机文件就是你的项目目录。对于想放心让 AI 代理"边写边跑"的用户来说，这套机制的意义在于：你可以大胆让模型自己验证代码，而最坏情况只是项目文件夹里多了一个奇怪的文件。

更多细节可查阅 docs/ARCHITECTURE.md 第 6 章（Sandbox）与 docs/CONFIGURATION.md 中的ATLAS_SANDBOX_*配置项。

【免费下载链接】ATLASAdaptive Test-time Learning and Autonomous Specialization项目地址: https://gitcode.com/gh_mirrors/atlas112/ATLAS