沙箱:OS 级隔离

沙箱:OS 级隔离

本节摘要:前三道防线(hooks、权限规则、白名单)都在「框架级」——它们由 Grok Build 自己判断,理论上可以被绕过(配置失误、bug、被恶意代码篡改)。最后一道防线是沙箱——它在操作系统内核级实现隔离,即便 Grok Build 自己出错,内核也不会让越权操作发生。Grok Build 在 Linux 用 Landlock、在 macOS 用 Seatbelt 做文件系统隔离,用 seccomp 做网络限制。本节会讲清这些机制是什么、沙箱的 profile 体系、为何沙箱是「一次性不可逆」,以及它与权限管线的关系。理解沙箱,你就理解了 Grok Build 安全设计的终极兜底。

一、为什么需要 OS 级隔离

回顾权限管线,它管「框架级」的允许/拒绝。但框架级有几个固有局限:

局限一:依赖框架正确性

权限管线是 Grok Build 自己的代码。如果有 bug(比如命令分段鉴权漏了某个分隔符),恶意命令可能绕过。框架级不是 100% 可靠。

局限二:工具内部的越权

权限管线检查「这次调用是否被允许」,但不深入「工具内部具体做了什么」。比如允许了 bash 执行 cargo build,但 cargo 内部可能读/写一些文件——这些 IO 不受权限管线管控。

局限三:外部进程

bash 工具派生的子进程,以及子进程的子进程,理论上能访问父进程能访问的一切。权限管线管不到「子进程跑了什么」。

OS 级隔离的价值

OS 级隔离(沙箱)在内核层面限制进程能访问什么。它的特点是:

• 不可绕过:内核强制,进程无法逃脱(除非内核本身有漏洞)
• 覆盖所有 IO:文件、网络、进程间通信,都受约束
• 继承到子进程:子进程继承沙箱限制,无法通过派生子进程逃脱
• 与框架无关:即便框架代码有 bug,内核仍拦

这种「内核兜底」让安全防线从「尽量拦」升级为「绝对拦」。

二、Linux:Landlock

Grok Build 在 Linux 上用 Landlock 实现文件系统隔离。

Landlock 是什么

Landlock 是 Linux 内核(5.13+)提供的一种无需 root 的沙箱机制。它让进程能自我限制对文件系统的访问——进程主动声明「我只访问这些路径」,内核之后强制执行。

关键特性:

• 无需 root:普通进程就能启用(老式沙箱如 chroot 需要 root)
• 不可逆:一旦应用,不能撤销(进程不能「解锁」更多权限)
• 继承:子进程继承限制
• 细粒度:可针对路径设读/写/执行等不同权限

Grok Build 怎么用 Landlock

会话启动时(在沙箱启用的情况下),Grok Build 向内核声明一组访问规则:

规则示例(伪代码):
    允许读:/(默认,只读基础)
    允许读写:工作区目录
    拒绝:/etc(除必要)、/root、其他敏感路径
​

声明后,内核强制执行。后续所有文件 IO——无论是 Grok Build 自己、bash 工具、还是 bash 派生的子进程——都受这些规则约束。

bash 工具尝试写 /etc/passwd
    ↓
内核(Landlock)检查:/etc 不在可写路径
    ↓
写失败(EPERM),即便权限管线放行了
​

要求:Linux 内核 5.13+(主流发行版已普遍支持)。

三、macOS:Seatbelt

Grok Build 在 macOS 上用 Seatbelt 实现类似隔离。

Seatbelt 是什么

Seatbelt 是 macOS 内置的沙箱机制(就是 sandbox-exec 命令背后的技术)。它用一种声明式的「沙箱描述语言」(sbpl)定义进程能做什么。

关键特性(与 Landlock 类似):

• 无需 root
• 不可逆(profile 应用后不能撤销)
• 细粒度(文件、网络、进程等)
• 内核强制

Grok Build 怎么用 Seatbelt

类似 Landlock——会话启动时应用一个 profile,定义文件系统访问规则。之后所有 IO 受约束。

Windows 的情况

Windows 没有与 Landlock/Seatbelt 直接等价的、无需管理员的沙箱机制。因此 Grok Build 在 Windows 上:

• 沙箱功能受限或不生效
• 安全更多依赖权限管线
• 推荐用 WSL(在 WSL 里跑相当于 Linux 环境,Landlock 可用)

这是第 2 章讲的「Windows 是 best-effort」的一个具体体现。

四、网络限制:seccomp

除了文件系统,Grok Build 还能限制网络访问。这通过 seccomp(Linux)实现。

seccomp 是什么

seccomp(secure computing mode)是 Linux 内核提供的「系统调用过滤」机制。进程可以声明「我允许哪些系统调用」,内核强制——不允许的系统调用直接失败。

Grok Build 用 seccomp 限制网络

通过过滤网络相关的系统调用(如 socket、connect、sendto 等),可以让进程(或其子进程)无法发起网络连接。

重要约束:

• 仅 Linux:seccomp 是 Linux 机制
• 仅子进程:Grok Build 主进程仍能联网(它要调模型 API),限制只对派生的子进程生效
• 特定 profile:只在某些 profile(如 ReadOnly、Strict)默认开启

为什么只限子进程

主进程需要联网(调模型 API、连 MCP server),不能被限制。但 bash 工具派生的子进程(用户命令)通常不需要联网,限制它们能防止「命令偷偷外发数据」。

五、沙箱 Profile 体系

Grok Build 把沙箱配置组织成 profile(在 xai-grok-sandbox/src/profiles.rs):

ProfileName:
├── Workspace   # 默认:仅工作区可写
├── Devbox      # 开发箱:更宽松
├── ReadOnly    # 全只读 + 限制网络
├── Strict      # 严格
├── Off         # 关闭沙箱
└── Custom(String)  # 自定义 profile 名
​

各 profile 的特点:

Workspace(默认)

• 工作区目录:可读可写
• 其他位置:只读
• 网络:允许
• 适合:正常开发,Agent 能改项目代码,但不能动系统文件

Devbox

• 更宽松,可能允许写更多路径(如 /tmp、缓存目录)
• 网络:允许
• 适合:开发箱/容器环境,需要更多写权限

ReadOnly

• 全部只读(除必要临时目录)
• 网络:限制(seccomp 启用)
• 适合:只读分析、审查代码、不希望任何修改的场景

Strict

• 最严格,读写都限制
• 网络:限制
• 适合:不可信场景、敏感环境

Off

• 关闭沙箱(不应用 Landlock/Seatbelt)
• 适合:不需要沙箱,或沙箱导致问题的场景

Custom

用户在 ~/.grok/sandbox.toml 自定义的 profile:

[profile.my-strict]
extends = "Workspace"           # 继承 Workspace
deny = ["**/.env", "**/secrets/**"]   # 额外拒绝
restrict_network = true
​

可继承现有 profile,叠加自定义规则。

六、SandboxProfile 的结构

一个 profile 的内部结构:

SandboxProfile {
    name: "Workspace",
    read_only: Vec<Glob>,     # 只读路径
    read_write: Vec<Glob>,    # 读写路径
    deny: Vec<Glob>,          # 显式拒绝
    default_read: bool,       # 默认是否可读
    restrict_network: bool,   # 是否限制网络
}
​

Glob 匹配:路径用 glob 模式(** 任意层级、* 单层),灵活描述路径集合。

deny 的意义:即便路径在 read_only 或 read_write 里,deny 命中仍拒绝。这让你能「允许工作区可写,但工作区里的 .env 不可写」。

七、为何「一次性不可逆」

沙箱有一个关键特性:profile 在进程启动时一次性应用,之后不可撤销。

不可逆的来源

这不是 Grok Build 的选择,而是 Landlock/Seatbelt 内核机制本身的特性。一旦进程声明了「我接受这些限制」,内核就锁定,进程无法「解锁」更多权限。

为什么内核这样设计

这是安全的根本:如果可逆,沙箱就没意义了。恶意代码可以「先解沙箱再作恶」。不可逆保证:无论进程里跑什么代码(哪怕被攻破),它都逃不出沙箱。

对 Grok Build 的影响

• 整个会话用同一 profile:不能中途换(不能「这个命令用 Strict,下个用 Off」)
• 启动时决定:profile 在 Grok Build 启动时(由配置或 CLI)决定
• 会话内一致:无论多少工具调用、子进程,都受同一沙箱约束

实际取舍

不可逆带来一个权衡:profile 不能设得太严(否则 Agent 干不了活),也不能太松(否则失去保护)。Grok Build 默认 Workspace profile,在「保护系统文件」与「允许 Agent 工作」之间取平衡。

八、沙箱与权限管线的关系

把沙箱与上一节的权限管线放在一起,它们是互补的两层:

工具执行请求
    ↓
权限管线(框架级)
    ├── hooks(用户)
    ├── 规则(框架)
    ├── remembered
    ├── 白名单
    └── 模式
    ↓ 放行
工具执行
    ↓
沙箱(OS 级)            ← 即便权限放行,这里仍拦
    ├── Landlock/Seatbelt:文件系统
    └── seccomp:网络(Linux,子进程)
    ↓
实际 IO
​

对比:

互补:权限管线做精细的、可配的策略;沙箱做粗粒度的、可靠的兜底。两者协作,既灵活又安全。

例子:

配置:权限规则允许 Edit(/etc/passwd)
    ↓ 权限管线放行
工具尝试写 /etc/passwd
    ↓
沙箱(Landlock):/etc 不在工作区,不可写
    ↓ 写失败
​

权限管线「误放行」,但沙箱「兜底拦」。这是双层防线的价值。

九、沙箱的启用与配置

启用方式

• 环境变量 GROK_SANDBOX=<profile>:启动时指定 profile
• CLI --sandbox <profile>:命令行指定
• 配置文件:在 config.toml 设默认 profile

默认行为

默认启用 Workspace profile(在支持的平台上)。如果你发现 Grok Build 报「权限不足」类错误,可能是沙箱拦了——可以:

• 调整 profile(放宽到 Devbox)
• 在 sandbox.toml 加自定义规则
• 极端情况用 Off(失去保护,不推荐)

诊断

沙箱问题排查较难(错误可能表现为普通的「权限拒绝」)。可以:

• 用 grok inspect 看当前沙箱配置
• 临时关沙箱(--sandbox Off)确认是不是沙箱问题
• 看日志里的 Landlock/Seatbelt 相关信息

十、沙箱的局限

沙箱强大,但也有局限:

局限一:平台限制

只在 Linux(5.13+)与 macOS 完整可用。Windows 受限。

局限二:粒度粗

profile 是路径级的,无法做「允许写这个文件但不允许写那个文件」的细粒度(除了 deny glob)。

局限三:一次性

不能中途换 profile,灵活性受限。

局限四:可能误伤

某些合法操作可能被沙箱拦(如 Agent 需要写工作区外的某个配置文件)。需要调整 profile 或 deny 规则。

局限五:不防逻辑错误

沙箱防「越权 IO」,不防「合法但错误」的操作(如 Agent 在工作区内误删重要文件)。后者要靠权限管线与 git/检查点。

十一、沙箱的工程价值

把沙箱放回设计层面,它的工程价值在于:

价值一:深度防御

不依赖单一防线。权限管线 + 沙箱 + 检查点(第 7 章),多层防御,任一层失误都有兜底。

价值二:可信计算基础

沙箱让 Grok Build 在「不可信代码」(如用户跑的 bash 命令、第三方 MCP server 派生的进程)面前仍可控。这是 Agent 能放心执行外部代码的根本保障。

价值三:符合企业安全要求

企业部署往往要求沙箱化(防止数据泄露、限制破坏范围)。Grok Build 的沙箱能力让它能满足这类合规要求。

关键概念:沙箱是 Grok Build 安全设计的「最后一公里」。它把安全从「框架承诺」升级为「内核保证」。即便所有上层防线失效,沙箱仍能防止最严重的越权。这种「深度防御 + 内核兜底」是工业级 Agent 安全的标志。

本节要点回顾

1. OS 级隔离解决框架级局限:不依赖框架正确性、覆盖工具内部 IO、约束子进程、内核强制不可绕过。
2. Linux 用 Landlock:内核 5.13+,无需 root,不可逆,继承子进程,细粒度路径权限。
3. macOS 用 Seatbelt:sandbox-exec 背后机制,声明式 sbpl 描述,特性类似 Landlock。
4. Windows 受限:无直接等价物,沙箱功能受限,推荐 WSL。
5. 网络用 seccomp(Linux):系统调用过滤,仅限子进程,仅特定 profile 启用。
6. Profile 体系:Workspace(默认)、Devbox、ReadOnly、Strict、Off、Custom。
7. SandboxProfile 结构:read_only/read_write/deny 路径 glob + default_read + restrict_network。
8. deny 优先:即便在 read_write 里,deny 命中仍拒。
9. 一次性不可逆:Landlock/Seatbelt 内核特性,启动时应用,不能撤销,整个会话同一 profile。
10. 与权限管线互补:权限管线细而灵活(框架级),沙箱粗而可靠(OS 级),双层防线。
11. 启用:GROK_SANDBOX 环境变量、--sandbox CLI、config.toml;默认 Workspace。
12. 局限:平台限制、粒度粗、一次性、可能误伤、不防逻辑错误。
13. 工程价值:深度防御、可信计算基础、符合企业安全要求。

至此,第六章全部完成。你已经从 MCP、Skills、插件、Hooks、权限管线到沙箱,完整理解了 Grok Build 的扩展生态与三层安全防线。下一章,我们转向 Agent 的「记忆」——会话持久化、上下文压缩、回滚、跨会话记忆,看清 Agent 如何「记得过去」。