Kiro Crew的OS沙箱实战Linux命名空间与macOS Seatbelt详解以及Windows为什么失败即关闭【免费下载链接】KiroCrewA persistent workspace for development work that self-improves and continues beyond one session.项目地址: https://gitcode.com/gh_mirrors/ki/KiroCrewKiro Crew 是一个持久化的开发工作区AI 智能体agent可以在其中读写文件、执行 Shell 命令。为了让智能体放得开、管得住Kiro Crew 为每一次 agent 子进程启动套上一层OS 级沙箱Linux 上靠用户命名空间 挂载命名空间macOS 上靠 Seatbeltsandbox-exec而 Windows 因为缺少对等的内核机制采取了失败即关闭的保守策略。本文带你一次看懂这三套机制的工作原理以及背后的默认配置agent.sandbox: auto到底在做什么。为什么需要 OS 级沙箱agent 能碰到什么先明确威胁模型Kiro Crew 最大的风险是提示词注入——智能体读到的网页、仓库文件、Slack 消息可能是攻击者写的内容。攻击者最想要的两样东西是偷凭证~/.aws云密钥、~/.sshSSH 私钥、~/.gnupg等搞破坏删除文件、覆盖配置、外传数据。Kiro Crew 的安全体系分 6 层OS 沙箱、文件系统门、命令门、输入校验、输出脱敏、审计日志OS 沙箱是唯一的可选层——因为它依赖操作系统原生能力。其余各层始终开启。各层的组合关系见 docs/architecture/security-deep-dive.md。OS 沙箱要解决一个特殊问题agent 不是通过工具 API读文件而是直接跑open()、cat这类系统调用。工具级的路径检查拦不住一条裸 Shell 命令只有操作系统才能拦。核心实现在 src/kiro_crew/sandbox.py每个平台各有一套原生机制三大平台的沙箱机制Linux用户命名空间 挂载命名空间遮眼法Linux 上的做法很巧妙不靠权限剥夺而是靠视觉欺骗详见 sandbox.py 模块头注释fork出子进程后调用unshare(CLONE_NEWUSER)创建用户命名空间父进程写入 UID/GID 映射——子进程保留真实 UID所以 git、AWS CLI、kubectl 等工具链照常工作unshare(CLONE_NEWNS)创建挂载命名空间把~/.aws、~/.ssh、~/.gnupg等敏感目录绑定挂载成空目录。效果是agent 在沙箱里ls ~/.ssh看到的是空的——不是读被拒绝而是文件根本不存在。同时~/.ssh/known_hosts会被特意保留可见git over SSH 需要它SSH 私钥则被隐藏。启动器脚本会在子进程退出后被自动清理。这种bind-mount 遮眼比直接拒绝读取更彻底基于路径的读取拒绝可以被硬链接绕过在/tmp建一个指向密钥的硬链接inode 相同照样读而挂载遮蔽直接改变了子进程看到的整个目录树。macOSSeatbelt 档案逐条禁止读取macOS 没有用户命名空间Kiro Crew 使用系统自带的Seatbelt框架sandbox-exec命令动态生成一份沙箱档案sandbox.py 的_build_seatbelt_profile核心规则包括对每个敏感目录生成(deny file-read* (subpath ~/.aws))之类的读取拒绝规则同时禁止file-write*防止 agent 伪造凭证文件——覆写token_signing.key甚至不需要先读到它和file-link封堵硬链接绕过Seatbelt 的读取拒绝基于路径在别的路径建硬链接就能绕过所以连创建指向敏感目录的硬链接这个动作本身也被禁止~/.ssh/known_hosts通过require-not (literal ...)例外规则从拒绝范围中精确挖出。macOS 还有一个有趣的内核限制Seatbelt 不能嵌套。如果 kiro-cli 自带沙箱已经启用Kiro Crew 会主动把隔离权移交给它这个决定是配置驱动并全程审计的保证每次启动恰好只有一层沙箱拥有隔离权——否则内核会直接返回 EPERM。Windows没有原生后端所以失败即关闭Windows 上既没有用户命名空间也没有sandbox-exec而且不存在任何可安装的等价物。面对这个现实Kiro Crew 的策略可以概括为三句话1. 官方 kiro-cli 启动 → 委托给 CLI 内置沙箱。只有被代码审查过的调用点、且显式标记为官方 kiro-cli 的启动is_kiro_cliTrue才委托给 Kiro CLI 自带的沙箱父进程会在启动前清洗环境变量。文件名长得像 kiro-cli 不够格第三方 ACP 后端、脚本、钩子一律不享受此待遇。2. 其他一切子进程 → 走无后端路径默认拒绝。沙箱的核心原则是失败即拒绝而不是降级Failure is refusal, not degradation当检测不到任何沙箱后端、且模式不是off时wrap_argv会抛出SandboxUnavailableError拒绝启动而不是放任无限制运行wrap_argv 实现。3. 无限制运行需要显式选择且全程留痕。agent.sandbox_allow_unsandboxed_exectrue可以让子进程无限制运行——这个开关的平台默认值因平台而异Windows 因永远没有后端而默认放行其他平台默认关闭。但每一次无限制启动都会写入 SEL 安全事件日志outcomeunconfined记录是操作者声明还是平台默认并伴随醒目警告。委托决策同样如此审计写不进去委托本身也会被拒绝。这就是标题里失败即关闭的含义Windows 不假装自己拥有内核级隔离。没有后端就不 wrap没被明确放行就不启动每一次例外都留下可验证的审计痕迹。一行配置搞定agent.sandbox沙箱由配置项agent.sandbox控制默认值是auto启用 OS 隔离唯一的手动选项是off配置文档Linuxauto 命名空间沙箱标准档保留.aws/.ssh可见git over SSH、AWS CLI 照常可用macOSauto Seatbelt 档案Windows无 Kiro Crew 自研 OS 包装层按上文三句话处理。值得注意的是off只是关掉 Kiro Crew 这一层并不等于裸奔——上面提到的工具路径门、敏感命令检测、输出脱敏三层防线始终在位。常见问题容器里为什么启动失败Linux 容器Docker/K8s中运行时默认的 seccomp 或 AppArmor 策略可能拦截命名空间握手。Kiro Crew 的报错信息会精确诊断是哪一步被拦并给出对应方案使用随仓库分发的自定义 seccomp 档案 docker/seccomp/kirocrew-seccomp.json比seccompunconfined更收紧或者显式声明放弃沙箱。完整排查步骤见 docs/guides/docker.md。另外提醒一点如果容器里启用了 cgroup 委托Linux 还会额外提供子树级的进程数/内存上限资源保护层见 docs/architecture/resource-protection.mdWindows 上则对应 Job Object 限制。小结平台机制无后端时Linux用户 挂载命名空间bind-mount 遮蔽凭证目录拒绝启动fail-closedmacOSSeatbelt /sandbox-exec动态档案拒绝读/写/硬链接拒绝启动fail-closedWindows无原生后端官方 kiro-cli 委托其内置沙箱默认拒绝显式放行才运行且全量审计一句话总结能隔离的地方就坚决隔离不能隔离的地方绝不假装隔离——这就是 Kiro Crew 的 OS 沙箱哲学。想深入机制细节每档隐藏路径清单、探测流程、审计规则可以继续读 docs/architecture/security-deep-dive.md 和 src/kiro_crew/sandbox.py。【免费下载链接】KiroCrewA persistent workspace for development work that self-improves and continues beyond one session.项目地址: https://gitcode.com/gh_mirrors/ki/KiroCrew创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考