Harness API、Worker 与 Sandbox 应暴露什么：Linux Permission、Network 与 Port

前置：进程怎样启动、退出并留下可观测输出：Linux Process、Signal 与 stdout/stderr
核心问题：API、Worker、Sandbox 各自到底需要哪些文件、网络和端口权限，怎样把攻击面缩到实际能力范围？

Harness 不是一个同权限进程

至少可以区分：

API service
- 接收用户命令
- 不需要写 Workspace

Runtime/Worker
- 访问 DB / Provider / approved Tool endpoints
- 不应该任意读宿主文件

Sandbox executor
- 需要 /workspace
- egress 更严格
- 不应拿 Control Plane credential

如果三者都以 root、共享同一 HOME、同一 secret 和开放 egress 运行，前面的 capability/security 设计会在部署层失效。

File Permission：从“进程真正需要什么”倒推

典型原则：

• 服务使用非 root UID/GID；
• application image 尽量只读；
• /workspace 只挂给需要的 sandbox/session；
• secret/config mount 分开且只读；
• artifact output 目录与 source workspace 权限区分；
• 不把 Docker socket、宿主根目录、SSH home 随意 mount 给 Agent。

Linux permission 不是完整 sandbox，但它决定了一个进程最直接的 blast radius。

Network / Port：入口和出口都要限制

入口：

public API       → 经 ingress/gateway
internal metrics → internal network
admin/debug port → localhost / protected network
worker           → 通常不需要 public listen

出口同样重要。Sandbox 如果能任意访问 metadata endpoint、内部 DB、secret service，Prompt Injection 最终可以变成真实数据外泄。

0.0.0.0 表示监听所有接口，127.0.0.1 只在本机可见；Docker EXPOSE 也不是授权机制。

Deployment Concern 必须服从 Capability Model

例如 Tool capability 只允许：

https://api.github.com/repos/x/*

但容器网络却允许访问整个内网，这仍然扩大故障/攻击面。更稳妥是 capability policy 与 egress policy 至少大方向一致：软件层拒绝 + 网络层限制形成 defense in depth。

Failure Modes

API、Worker、Sandbox 共用同一高权限账号

后果： 任一 Tool/Workspace compromise 都可能读取控制面 secret。

处理： 分角色 service account / UID / secret mount / network policy。

Debug/Admin Port 直接公开

处理： 明确 bind address，通过认证后的管理面访问，不把开发端口暴露公网。

自测

1. API 只需监听内部网卡却绑定 0.0.0.0 并开放所有端口，会扩大什么攻击面？
2. Worker、API、Sandbox 为什么不应该默认使用同一 Linux 用户和相同网络权限？

Sources

• Docker Documentation
• Docker — Networking