ATLAS沙箱如何保护你的机器?多语言隔离执行、只读根文件系统与资源上限原理详解
ATLAS沙箱如何保护你的机器多语言隔离执行、只读根文件系统与资源上限原理详解【免费下载链接】ATLASAdaptive Test-time Learning and Autonomous Specialization项目地址: https://gitcode.com/gh_mirrors/atlas112/ATLASATLAS 沙箱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对外提供三个核心能力端点用途工作区/execute执行 AI 生成的代码含语法检查、lint、跑测试/tmp/sandbox下的一次性临时目录/shell执行代理的run_command等 shell 命令绑定挂载的项目目录/workspace/jobs/*后台任务启动 / 查看输出 / 停止长驻进程同上镜像 sandbox/Dockerfile 把常用工具链一次性烤进镜像支持 12 种语言语言版本语法检查方式Python3.13py_compile pytestJavaScript / TypeScriptNode 20 LTS / tscnode --check/tsc --noEmitGo1.22gofmt -ego buildJava / Kotlin21 / 2.4.0javac/kotlinc全量编译RuststablerustcC / Cgcc/g (C17/C17)-fsyntax-onlyRuby / PHP发行版自带ruby -c/php -lBash—bash -n这里有个值得注意的设计取舍因为容器是只读 非 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配合挂载策略沙箱内部的世界是这样的根文件系统只读——AI 无法安装软件、改系统配置、替换二进制/workspace是唯一可写的主机挂载点指向你的项目目录ATLAS_PROJECT_DIR所以任何命令的爆炸半径blast radius就是项目文件夹本身所有需要写的地方用 tmpfs 临时内存盘/tmp2G、pip 的.local1G、npm/cargo/go/maven/gradle 等各类缓存目录各 256M–512Mdocker-compose.yml。这些盘随容器重启即清空——依赖可以临时装进来用但不会在磁盘上留任何痕迹pip install也能正常工作API 端口只绑定127.0.0.1且请求需要内部服务令牌Bearer tokenatlas init生成才能调用/shell和/executeexecutor_server.py沙箱不对外网暴露。简单说AI 拿到的是一台装好了所有语言工具、但除你的项目外什么都写不了的一次性电脑。资源上限内存、CPU、进程数三重封锁即使代码合法也可能耗尽资源。ATLAS 在容器层面设置了硬性配额上限默认值作用mem_limit4 GBATLAS_SANDBOX_MEM内存耗尽时容器被 OOM 杀死不会拖垮主机cpus2 核ATLAS_SANDBOX_CPUSCPU 占用封顶防止占满全部核心pids_limit1024ATLAS_SANDBOX_PIDS内核级 fork 炸弹拦截正常构建用不到这么多进程炸弹到 1024 个进程就被内核掐死单次执行墙钟300 秒MAX_EXECUTION_TIME超时立即终止整个进程组其中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。设计哲学是容器是真正的边界正则只做体验补充即便模型找到了正则的漏洞也只会在只读、配额受限的容器里折腾伤不到主机。安全模型速查清单威胁拦截机制生效层级修改系统文件 / 安装后门只读 rootfs 非 root 零 capabilities容器硬边界提权sudo 等no-new-privileges容器删除/格式化磁盘毁灭级命令拦截 唯一可写挂载是/workspace代理层 容器fork 炸弹pids_limit: 1024内核内存/CPU 耗尽mem_limit/cpus容器死循环 / 卡死构建300s 墙钟 整进程组 SIGKILL沙箱服务依赖安装留痕全部走 tmpfs重启即焚容器外部直接调用沙箱 API仅127.0.0.1暴露 Bearer 服务令牌网络/认证小结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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考