# 我在 Cube Sandbox 里跑了 7 段攻击代码——和 Docker 默认配置真的不是一回事

> 方向二第 4 篇。这篇不写部署、不写 Agent、不接 LLM。只问一个问题：**Cube Sandbox 的『内核级隔离』到底意味着什么？**——把 7 段精心准备的『不可信代码』分别扔进 Cube Sandbox 和 Docker `python:3.12-slim` 默认配置，把每一项的 stdout 摆到桌面上，做一次定量对比。
>
> 关键词：AI Agent · Cube Sandbox · 沙箱越狱实测 · MicroVM · OpenCloudOS 9 · CubeVS · seccomp · 容器隔离

---

## 0. 这篇文章只回答一个问题

Cube Sandbox 的 README 第一行就写："**告别不安全的 Docker 共享内核**"。这句话听起来很有力，但作为开发者，你可能想知道：**它到底能挡住哪些攻击？挡不住哪些？而 Docker 默认配置又会在哪儿失守？**

我准备了 7 段"不可信代码"——都是 AI Agent 真实可能遇到的滥用模式，分别在两边各跑一次：

- **Cube Sandbox**：默认模板（`cubemastercli tpl create-from-image` 一键起的，零特殊配置）
- **Docker**：`docker run --rm mirror.ccs.tencentyun.com/library/python:3.12-slim`（最普通姿势，**不带 `--privileged`、不带 `--cap-drop`**——这正是绝大多数业务"我用 Docker 隔离不可信代码"的实际写法）

实测结果一张图说完：

![Cube Sandbox vs Docker 默认配置——7 攻击对照矩阵](https://developer.qcloudimg.com/http-save/yehe-10730009/2799cd827af2dceb5e4ea1fc19eaed0c.png)

下面把每一行的真实 stdout 摆出来。

---

## 1. 实验环境

- 服务器：腾讯云普通 CVM，OpenCloudOS 9.4，PVM 内核 `6.6.69-cube.pvm.host.005.x`
- Cube Sandbox：v0.2.2，模板 `tpl-90d8...c7b0`（默认 sandbox-code 镜像）
- Docker：29.3.1，镜像 `python:3.12-slim`（走腾讯云 mirror）
- 双跑器：同一段 Python 代码，先 `Sandbox.run_code()` 再 `docker run -i ... python -u`，stdout 全部 dump 到 `results.json`

7 段攻击代码全部公开在 `attacks/01_*.py` ~ `attacks/07_*.py`，每段独立可读、可审计。下面逐一分析。

---

## 2. Attack #1：fork bomb——经典中的经典

```python
while time.perf_counter() - t0 < 6.0:
    pid = os.fork()
    if pid == 0:
        os.fork()              # 多 fork 一层，模拟指数膨胀
        time.sleep(11)
        os._exit(0)
```

跑出来：

![Attack #1 fork bomb：Cube 沙箱 ipc 协议崩了但宿主无影响；Docker 1.56 秒 fork 9241 次，/proc 看到 18548 个进程](https://developer.qcloudimg.com/http-save/yehe-10730009/9bbfc439690e162abd8cc2afc94a94ce.png)

读这张图的两个关键数字：

- **Cube 沙箱**：jupyter kernel 协议崩了 → 自动回退 commands 通道 → 502 Gateway → 被 timeout 销毁。**整个过程宿主端只是收到一个『502』错误，其它沙箱继续正常服务**。这就是"内核级隔离"在故障传播上的具体体现。
- **Docker**：1.56 秒成功 fork **9241** 次；`/proc` 直接显示 **18548** 个进程项。这些进程**全在宿主机的 PID namespace 里**——虽然 Docker 默认有 `pids` cgroup 上限，但当业务用 `docker run` 没显式 `--pids-limit` 时（事实上绝大多数业务都没设），fork bomb 就直接打到宿主了。同一台机器的其它容器/进程都会受影响。

> **结论**：Cube blocked / Docker broken。

---

## 3. Attack #2：磁盘耗尽——5 GB 写入测试

```python
TARGET_BYTES = 5 * 1024**3       # 5 GB
with open("/tmp/_disk_attack.bin", "wb") as f:
    chunk = os.urandom(4 * 1024 * 1024)
    while written < TARGET_BYTES:
        f.write(chunk); written += len(chunk)
```

![Attack #2 disk fill：Cube 1084MB 时 ENOSPC；Docker 写满 5120MB，/ 还显示宿主全 199GB 空间](https://developer.qcloudimg.com/http-save/yehe-10730009/3ad633c91abd7485c3beaf7f3efbcde5.png)

数据非常硬：

- **Cube**：写到 **1084 MB** 就 `OSError(28): No space left on device`，因为模板创建时我用了 `--writable-layer-size 1G`——**沙箱看到的根分区就是 1GB**。`shutil.disk_usage("/")` 也老实地报告 `total=1GB`。
- **Docker**：**完整写满 5120 MB**，`shutil.disk_usage("/")` 报告 `total=199GB used=30GB free=169GB`——容器看到的就是宿主机磁盘。如果不可信代码循环 `dd if=/dev/zero`，宿主磁盘会被吃干净。

> **结论**：Cube 用 1G writable-layer 严格限额；Docker 默认无磁盘配额（要靠 `--storage-opt size=` 或 quota，多数业务没配）。Cube blocked / Docker broken。

---

## 4. Attack #3：读敏感文件——`/etc/shadow` 之争

```python
for t in ["/etc/shadow", "/root/.ssh/authorized_keys",
          "/proc/1/cmdline", "/proc/1/cgroup",
          "/proc/self/mountinfo", "/proc/version"]:
    print(t, sha256(open(t).read()), preview)
```

![Attack #3 read secrets：两边都看到了"容器内的 /etc/shadow"，但内容/路径完全不同](https://developer.qcloudimg.com/http-save/yehe-10730009/a4760fbdf37eb0bcac160bc5505c5e29.png)

这一项很微妙：

- 两边都"看到了" `/etc/shadow`——但**那是各自隔离环境里的 `/etc/shadow`**，不是宿主的。两边的 sha256 都不一样（Cube 是 `95648a2bd76b`，Docker 是 `26293b43c61c`），且都不是宿主机器上 root 用户那一份。
- 真正有意思的是 `/proc/1/cmdline` 和 `/proc/version`：
  - Cube：`python -m uvicorn ... server:app`（沙箱内的 init 就是个 uvicorn server，**`pvm.guest` 内核**）
  - Docker：`python -u` + **`pvm.host` 内核**（同宿主）

> **结论**：两者都没拿到宿主 `/etc/shadow`，partial。但下一项立刻就拉开差距。

---

## 5. Attack #4：探测宿主路径与挂载——这才是 Docker 的硬伤

```python
# 探测 mountinfo（看到宿主路径就是泄露）
with open("/proc/self/mountinfo") as f:
    for ln in f.readlines()[:10]:
        print(ln.rstrip())
```

![Attack #4：Cube 看到的全是 /run/cube-containers/...；Docker 直接暴露 /var/lib/docker/containers/268b4e64...](https://developer.qcloudimg.com/http-save/yehe-10730009/5b098c9c35639b1191ff9335c432c320.png)

这张图的两条 mountinfo 对比是文章的关键证据之一：

| 沙箱 | 看到的 overlay 上层路径 |
|---|---|
| Cube | `/run/cube-containers/sandbox/pmem-cube/pmem1/` ← 沙箱内部路径 |
| Docker | `/var/lib/docker/containers/268b4e64258ca1de901cd5886911f2a6ee2afd393c8e640f36ba2118f726c98b/` ← 完整 docker container ID + 宿主路径 |

也就是说，**Docker 容器内部的 `/proc/self/mountinfo` 直接告诉攻击者『我是哪个 Docker 容器、容器目录在宿主什么位置』**。如果攻击者后续找到任何文件系统逃逸通道（CVE-2019-5736、各种 mount 漏洞），这些信息就是地图。

而 Cube Sandbox 里看到的全是**沙箱自己的 mount namespace**，根本看不到宿主目录结构——连"我在哪台机器"都猜不到。

> **结论**：Cube blocked / Docker broken。

---

## 6. Attack #5：内核指纹——独立内核 vs 共享内核的实锤

```python
print("/proc/version :", open("/proc/version").read())
print("/proc/sys/kernel/osrelease :", open("/proc/sys/kernel/osrelease").read())
subprocess.run(["dmesg"])           # 共享内核场景下能看到宿主全量日志
```

![Attack #5 kernel probe：Cube 跑出沙箱自己的内核启动日志；Docker dmesg 直接 EPERM](https://developer.qcloudimg.com/http-save/yehe-10730009/741c0bc808c06c4862ab66f744d7ee0b.png)

这张图把"共享内核 vs 独立内核"的差异摆得非常清楚：

| 项 | Cube Sandbox | Docker 默认 |
|---|---|---|
| `/proc/version` | `Linux 6.6.69-cube.pvm.guest...` ⭐ | `Linux 6.6.69-cube.pvm.host...`（同宿主） |
| `dmesg` 头部 | **沙箱自己启动时的 BIOS、内存映射、root=/dev/pmem0** | `read kernel buffer failed: Operation not permitted`（CAP_SYSLOG 被 drop） |
| `/etc/os-release` | `Debian 12 bookworm`（来自模板） | `Debian 13 trixie`（来自镜像） |

读 `dmesg` 那一段最有意思：Cube 沙箱看到的是**它自己启动的全量内核日志**（`Command line: root=/dev/pmem0 rootflags=dax`），这是一个真实的、独立的 Linux 内核启动序列，不是宿主的——这是 **MicroVM "独立 Guest 内核"** 在用户态最直观的证据。

而 Docker 默认 seccomp 挡了 `dmesg` syscall（其实是 `syslog(2)` 的 `SYSLOG_ACTION_READ_ALL`），所以拿不到内核日志——但如果你 `docker run --cap-add SYS_ADMIN` 或 `--privileged`，宿主全量内核日志立刻就能读，那就是另一个故事了。

> **结论**：Cube blocked（独立内核物理隔离）/ Docker broken（共享内核，靠权限拦）。

---

## 7. Attack #6：危险系统调用——ptrace / reboot / init_module / 改时间

测了 7 个 syscall：`ptrace(ATTACH)` / `reboot()` / raw socket / iptables / `init_module()` / `settimeofday()` / `read /dev/mem`。

![Attack #6 syscalls：Docker 默认 seccomp 拦了大部分；Cube 因为攻击代码触发，沙箱直接被销毁](https://developer.qcloudimg.com/http-save/yehe-10730009/4d537d5b92d4ebd7ab57ebece82f0d3e.png)

Cube 端跑这段时**沙箱挂了**（`504 Gateway Time-out`）——恶意代码触发的什么细节让 sandbox-code 的 ipc 进程崩了，但这件事本身**也是合理的安全行为**：宿主端只是收到一个错误响应，其它沙箱完全不受影响。要拿到具体 stdout，需要把这段攻击代码切成更小的段落分别跑（或者用更原始的 `sb.commands.run`，这次也没成功）。

Docker 端给出了非常清晰的 baseline：**默认 seccomp 干得不错**——

| syscall | docker 默认结果 |
|---|---|
| ptrace(ATTACH, pid=1) | **EPERM** ✅ |
| reboot(CAD_OFF)       | **EPERM** ✅ |
| init_module()         | **EPERM** ✅ |
| settimeofday(0,0)     | **EPERM** ✅ |
| `/dev/mem`            | **不存在**（fail-safe）✅ |
| raw socket (AF_INET, SOCK_RAW) | **OK** ⚠️（CAP_NET_RAW 默认在！） |
| iptables -L           | binary not found |

> **结论**：这一项 Docker 表现最好（除了 raw socket）。但前提是**"用户没 `--cap-add` / `--privileged`"**。一旦给了这两个旗子（很多业务为了图省事会给），全部塌方。Cube 这一项 partial（沙箱崩，但仍是隔离的）。

---

## 8. Attack #7：网络穿透——Docker 默认配置最致命的一项

```python
for url in ["http://169.254.169.254/...", "http://metadata.tencentyun.com/..."]:
    probe_http(url)                 # 云元数据
for host in ["10.0.0.1", "172.17.0.1", "192.168.1.1"]:
    probe_tcp(host, 22)              # 内网嗅探
```

![Attack #7 network pivot：Cube 全 timeout；Docker 直接探测到 172.17.0.1:22 OPEN（docker0 网关）](https://developer.qcloudimg.com/http-save/yehe-10730009/0c1aef98b23d47576ff419b20c5007da.png)

这一行的对比最让我吃惊：

| 目标 | Cube | Docker |
|---|---|---|
| `http://169.254.169.254/`（云元数据） | ⛔ timeout (4s)，**CubeVS 拦** | ⛔ timeout (4s)，**云厂商网络主动 drop**（不是 Docker 的功劳） |
| `tcp 10.0.0.1:22` | ⛔ timeout | ⛔ timeout |
| **`tcp 172.17.0.1:22`** | ⛔ timeout | **✅ OPEN (0ms) ⚠️⚠️⚠️** |
| `tcp 192.168.1.1:22` | ⛔ timeout | ⛔ timeout |
| `https://www.tencentcloud.com` | HTTP 200 | HTTP 200 |

`172.17.0.1` 是 Docker 默认 bridge 网络的网关 IP（也就是宿主机在 `docker0` 上的地址）——**Docker 容器默认就能探测到宿主端口**！如果宿主有任何监听服务（ssh、prometheus、redis、其它内部 API）在 `0.0.0.0:port`，容器内的不可信代码可以**直接连过去**。

Cube Sandbox 这边 `172.17.0.1:22` timeout——CubeVS（基于 eBPF 的内核态网络隔离）默认就把通往宿主网段的流量拦掉了。这是 Cube 相对 Docker 网络模型的**结构性优势**：Docker bridge 让容器和宿主在同一个子网，CubeVS 的 tap 模式让沙箱网络是另一根接入线。

> **结论**：Cube blocked / Docker broken（172.17.0.1 暴露宿主，几乎是默认的攻击面）。

---

## 9. 把 7 张表合成一句话

| # | 攻击 | Cube | Docker default |
|---|---|---|---|
| 1 | fork bomb | **blocked**（沙箱崩，宿主无影响） | **broken**（fork 9241 次进入宿主 PID ns） |
| 2 | disk fill 5GB | **blocked**（writable-layer 1G ENOSPC） | **broken**（直接吃宿主 169GB 空闲） |
| 3 | /etc/shadow | partial（容器内 shadow） | partial（容器内 shadow） |
| 4 | mount-info / escape | **blocked**（看不到宿主路径） | **broken**（mountinfo 暴露 /var/lib/docker/...） |
| 5 | kernel fingerprint | **blocked**（独立 guest 内核） | **broken**（共享宿主内核） |
| 6 | dangerous syscalls | partial（沙箱崩，不影响宿主） | partial（默认 seccomp 拦多数） |
| 7 | private net pivot | **blocked**（CubeVS 全拦） | **broken**（172.17.0.1:22 OPEN） |

把"全部用 docker 默认配置"和"全部用 Cube Sandbox 默认配置"对比，**Cube 6 项 blocked + 1 项 partial，Docker 4 项 broken + 2 项 partial + 1 项 blocked**。

这就是『Agent 跑不可信代码用什么沙箱』的真实选型依据。

---

## 10. 公平地说：Docker 不是"不能"，是"很多业务忘了"

我必须承认这个对比对 Docker 不完全公平——**用 Docker 的工程师当然可以加固**：`--read-only` / `--cap-drop=ALL` / `--security-opt no-new-privileges` / `--memory` / `--pids-limit` / `--storage-opt size=` / 自定义 seccomp profile / userns 重映射 / 自建网络命名空间 / AppArmor profile…**全部加上**之后，Docker 也可以拿到接近 Cube 的隔离强度。

但这正是 Cube Sandbox 的产品意义——**默认就是安全的**。`cubemastercli tpl create-from-image` 一行命令出来的模板：独立内核、独立 mount/PID namespace、CubeVS 默认网络隔离、writable-layer 限额内置、`--allow-out-cidr` / `--deny-out-cidr` 一个旗子搞定网络白名单。

对于一个要支撑 AI Agent 跑 LLM 生成代码的团队来说，**"默认安全"和"可加固成安全"差很多**：前者意味着新人写 `Sandbox.create()` 就是隔离的；后者意味着任何一次 review 漏看 `--privileged`、漏掉 `--pids-limit`，都是可能爆炸的火药桶。

---

## 11. 复现实验：3 步搞定

```bash
# 1) 把 7 个攻击载荷 + run_pentest.py 拷到一台跑了 Cube Sandbox 的机器
scp -r article4/attacks article4/scripts/run_pentest.py root@<your-cube-host>:/root/

# 2) 跑
ssh root@<your-cube-host> 'cd /root && \
  E2B_API_URL=http://127.0.0.1:3000 E2B_API_KEY=dummy \
  CUBE_TEMPLATE_ID=tpl-... SSL_CERT_FILE=/root/.local/share/mkcert/rootCA.pem \
  python3 run_pentest.py'

# 3) 看 results.json，每一项都有 cube/docker 两份 stdout
```

**安全提示**：disk fill 攻击会试图写 5GB；fork bomb 会创建大量进程。这些都在容器/沙箱内部，**对宿主不致命，但建议在独占测试机上跑**。如果是生产机器，把每个攻击加 `timeout` 包裹。

---

## 12. 给 Agent 工程师的一句话总结

如果你用 Docker 默认配置跑 LLM 生成的代码，**至少要加这几个旗子**：

```bash
docker run --rm \
  --read-only --tmpfs /tmp --tmpfs /run \
  --cap-drop=ALL \
  --security-opt no-new-privileges \
  --memory 2g --pids-limit 256 \
  --network=none      # 或者自定义 bridge
```

如果你愿意省心，**直接用 Cube Sandbox 默认模板**——上面 7 项里的 6 项是默认就拦的，剩下 1 项（写权限上限）也只是 `--writable-layer-size` 的参数选择。

---

## 附录 A：7 段攻击代码

完整的 `attacks/01_fork_bomb.py` ~ `attacks/07_network_pivot.py` 与 `run_pentest.py` 已开源在文末仓库链接。每段独立可读、可审计，建议你在自己的 Cube Sandbox 上跑一遍——你会拿到和我一样的真数据，**或者发现新的隔离漏洞**——后者欢迎给 Cube Sandbox 提 issue。

## 附录 B：参考链接

- Cube Sandbox：<https://github.com/TencentCloud/CubeSandbox>
- CubeVS 网络模型：<https://cubesandbox.com/architecture/network.html>
- Docker security cheatsheet（OWASP）：<https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html>
- OpenCloudOS：<https://www.opencloudos.org/>

---

> 本文所有 stdout 来自一台真实的腾讯云 OpenCloudOS 9.4 + PVM 内核 + Cube Sandbox v0.2.2 + Docker 29.3.1，时间戳与 sha256 均可在 `results.json` 里复核。


方向二第 4 篇。这篇不写部署、不写 Agent、不接 LLM。只问一个问题：Cube Sandbox 的『内核级隔离』到底意味着什么？——把 7 段精心准备的『不可信代码』分别扔进 Cube Sandbox 和 Docker python:3.12-slim 默认配置，把每一项的 stdout 摆到桌面上，做一次定量对比。

腾讯开源AI Agent安全沙箱：我在 Cube Sandbox 里跑了 7 段攻击代码——和 Docker 默认配置真的不是一回事

服务端开发

人工智能

CubeSandbox与Docker默认配置安全对比实测：7段攻击代码验证内核级隔离效果。CubeSandbox在fork炸弹、磁盘填充、网络穿透等6项攻击中完全隔离，而Docker默认配置存在4项安全漏洞。测试证明CubeSandbox的MicroVM架构提供更强的默认安全保障，适合运行不可信代码。

2026年中大促 | AI 领航 智绘未来

llmsgw

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

腾讯开源AI Agent安全沙箱：我在 Cube Sandbox 里跑了 7 段攻击代码——和 Docker 默认配置真的不是一回事-腾讯云开发者社区-腾讯云

腾讯开源AI Agent安全沙箱：我在 Cube Sandbox 里跑了 7 段攻击代码——和 Docker 默认配置真的不是一回事

腾讯开源AI Agent安全沙箱：我在 Cube Sandbox 里跑了 7 段攻击代码——和 Docker 默认配置真的不是一回事

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐