Security on Fenglai

CubeSandbox 安全机制清单

Mon, 06 Jul 2026 23:21:04 +0800

调研时间: 2026/07/03

T5 CubeProxy inbound — Internet → Sandbox

Mon, 06 Jul 2026 23:20:49 +0800

一句话定位: 公网用户通过 *.cube.app 通配域名进入 CubeProxy,再反向代理到 sandbox 暴露端口的入站面。

T4 Egress — Guest → Internet

Mon, 06 Jul 2026 23:20:09 +0800

一句话定位: Guest 内 sandbox 通过 host 网络栈出到互联网 (LLM API / 第三方服务 / 模型下载) 的强制审计面。

T3 KVM CORE BOUNDARY — Host ↔ Guest

Mon, 06 Jul 2026 23:19:20 +0800

一句话定位: 整个 CubeSandbox 安全模型的基石 —— 宿主进程与 Guest OS kernel 之间的硬件级隔离面。

T2 Operator Trust — 运维 → 配置 / 镜像

Mon, 06 Jul 2026 23:18:21 +0800

一句话定位: 运维人员将可信根 (配置、镜像、模板、二进制) 注入 host 信任域的入口。

T1 CubeAPI ingress — 外部 → CubeAPI

Mon, 06 Jul 2026 23:17:46 +0800

一句话定位: 公网用户 / LLM API / 第三方服务进入 CubeSandbox 的唯一访问入口。

5.3 CVE 修复链

Sat, 04 Jul 2026 14:35:12 +0800

CubeSandbox 依赖许多 Rust crate、Linux 内核、seccomp filter、cloud-hypervisor,这些依赖项自身会有 CVE。项目通过:

5.2 日志与诊断

Sat, 04 Jul 2026 14:34:50 +0800

CubeSandbox 把日志分成:

5.1 部署前预检 (Preflight)

Sat, 04 Jul 2026 14:34:29 +0800

预检(preflight check)是部署脚本在真正安装前对 host 环境的硬约束检查。CubeSandbox 在 deploy/one-click/online-install.sh:50-180 的 checkearlyprefli

4.8 端口与服务拓扑

Sat, 04 Jul 2026 14:34:09 +0800

CubeSandbox 各组件在 host 上分配明确端口,互不冲突:

4.7 跨服务凭据

Sat, 04 Jul 2026 14:33:47 +0800

CubeSandbox 部署依赖多个组件:

4.6 WebUI 数字助理 (DB-backed session)

Sat, 04 Jul 2026 14:33:28 +0800

CubeSandbox 自带 WebUI 控制台,登入后由后端数据库(mysql/postgres)管理 session,不发 cookie,而是用 x-session-token header 携带不透明 token。

4.5 多租户隔离

Sat, 04 Jul 2026 14:33:05 +0800

CubeSandbox 的多租户基于 containerd namespaces(namespaces.WithNamespace(ctx, ns))+ tenant label + Redis keyspace 三层组合。

4.4 /health 豁免

Sat, 04 Jul 2026 14:32:46 +0800

Every request (except /health) must carry an Authorization: Bearer <token> or X-API-Key: <key> header

4.3 共享 HTTP 客户端(连接池上限)

Sat, 04 Jul 2026 14:32:26 +0800

CubeAPI 启动时创建一个全局共享的 reqwest::Client 实例,所有外部 HTTP 调用(auth callback、webhook、镜像拉取)都通过它发出。

4.2 per-API-key 速率限制

Sat, 04 Jul 2026 14:32:07 +0800

CubeSandbox 在 API 层用了 token bucket 限流,按 API key 维度分配独立配额。每条请求到来:

4.1 外部 auth callback

Sat, 04 Jul 2026 14:31:49 +0800

CubeSandbox 自身不实现 OAuth/JWT 之类的内嵌认证,而是把"是否放行"的决定委托给一个外部 HTTP 服务。每次接收请求,CubeAPI 都会把请求转发给外部 authcallbackurl,由 callback 返回

3.8 no_reaper / no_sub_reaper

Sat, 04 Jul 2026 14:31:29 +0800

Linux 进程树的"reaper"机制决定:谁负责回收"孤儿进程"(parent 死掉但子进程还活着)。在 Linux 中:

3.7 vsock 主机-客机通信

Sat, 04 Jul 2026 14:31:07 +0800

vsock 是 Linux 内核内嵌的 VM 主机-客机通信机制。它有一个独立地址族(AFVSOCK),使用 CID(contiguous identifier) 标识 host / guest:

3.6 OCI 容器兼容 (containerd-shim v2)

Sat, 04 Jul 2026 14:30:43 +0800

CubeShim 是 containerd shim v2 的实现,注册到 containerd 时 runtime type 是:

3.5 文件系统隔离 (overlayfs / virtiofs)

Sat, 04 Jul 2026 14:30:15 +0800

CubeSandbox 的文件系统层级是两层:

3.4.3 网络隔离 - TAP 设备隔离 + sysctl

Sat, 04 Jul 2026 14:29:52 +0800

这层包含两个相辅相成的组件:TAP 设备的命名/地址惯例与支持 TPROXY 的 sysctl。

3.4.2 网络隔离 - L7 透明代理 (CubeEgress)

Sat, 04 Jul 2026 14:29:28 +0800

CubeEgress 是 L7 透明代理 / HTTPS MITM,在 host 上拦截 sandbox 的 80/443 出站:

3.4.1 网络隔离 - 主机侧 eBPF (CubeVS)

Sat, 04 Jul 2026 14:29:05 +0800

CubeVS 是 CubeSandbox 的内核态 L3/L4 网络安全层。三个 eBPF 程序挂在 TC (traffic control) 钩子点,在内核态直接做策略执行,不必到 user space:

3.3 快照 / 克隆安全

Sat, 04 Jul 2026 14:28:44 +0800

CubeSandbox 的 snapshot / clone / rollback 是核心差异化特性。它基于 CubeCoW 引擎(docs/blog/posts/2026-06-03-cubesandbox-v0.3.0-snapshot

3.2 jailer / 进程隔离

Sat, 04 Jul 2026 14:28:24 +0800

Jailer 模式起源于 AWS Firecracker:把 VMM 进程(chroot 进空目录 + 切到非 root 用户 + 给新 cgroup + 加 seccomp filter + drop all caps)。这样,即使 VM

3.1 rootless / 非特权运行

Sat, 04 Jul 2026 14:28:01 +0800

Rootless 模式指 sandbox 的"模板导出"或"镜像拉取"过程不需要以 root 用户运行。CubeSandbox 通过 umoci –rootless 来导出 OCI 镜像,不需要 root 创建文件系统。

2.7 未启用的内核机制(重要!)

Sat, 04 Jul 2026 14:27:44 +0800

不是所有"听起来该用"的安全机制 CubeSandbox 都启用了。这篇列了 4 个经过调研确认未使用 / 默认 permissive 的内核机制,以及 CubeSandbox 选/不选它的原因。

2.6 审计 (Audit)

Sat, 04 Jul 2026 14:27:06 +0800

Linux Audit(CONFIGAUDIT=y)是一个内核子系统,记录系统调用、文件访问、安全决策等关键事件到 audit log(/var/log/audit/audit.log 或 netlink 转发)。CubeSandbox 内

2.5 host 启动参数硬化 (grub cmdline)

Sat, 04 Jul 2026 14:26:45 +0800

Host kernel 引导参数(grub cmdline)是内核启动时的关键开关。CubeSandbox 在 deploy/pvm/grub/hostgrubconfig.sh:18-22 中合并下列项:

2.4 Namespaces (PID/Net/Mount/UTS/IPC/User/Cgroup)

Sat, 04 Jul 2026 14:26:25 +0800

Linux namespace 把"全局唯一资源"切成多个互不可见的实例。CubeSandbox 用到的共有 7 类:

2.3 cgroups (资源限制)

Sat, 04 Jul 2026 14:26:05 +0800

cgroups(control groups)是 Linux 内核的资源计数与限制机制。把同一个 hierarchy 下的进程归到一个 cgroup,该 cgroup 的所有进程共享一套配额。典型可限制的资源:

2.2 Linux Capabilities(细粒度)

Sat, 04 Jul 2026 14:25:41 +0800

Linux 把传统 root 权限切成 40+ 个细粒度 capability(CAPCHOWN、CAPNETADMIN、CAPSYSADMIN 等)。每个进程同时持 5 个 capability set:

2.1 seccomp / seccomp-bpf (三层部署)

Sat, 04 Jul 2026 14:25:22 +0800

seccomp 是 Linux 内核的 syscall 过滤机制:

1.7 virtio Rate Limiter (TokenBucket)

Sat, 04 Jul 2026 14:24:56 +0800

TokenBucket (令牌桶) 是一种经典流量整形算法:

1.6 启动流程安全配置

Sat, 04 Jul 2026 14:24:39 +0800

Cloud-hypervisor 拉起一个 microVM 时,会把命令行参数(-append)注入到 guest kernel 的 cmdline。这些 cmdline 设置不是简单的版本号,而是一组对 guest kernel 行为的安

1.5 设备透传 (IOMMU / VFIO)

Sat, 04 Jul 2026 14:24:19 +0800

设备透传 (device passthrough) 把宿主机上的物理 PCI 设备(nic / disk)直接挂给某个 VM,VM 内能看到这块设备的真实 PCI BAR 与寄存器,而无需 hypervisor 的全设备模拟。

1.4 virtio 设备隔离

Sat, 04 Jul 2026 14:21:54 +0800

virtio 是虚拟机内最常见的"半虚拟化"IO 设备协议,CubeSandbox 中所有 guest ↔ host 数据通路(网络、磁盘、文件系统)都走 virtio。每个 virtio 设备的隔离由 3 个层面共同保证:

1.3 vCPU / 内存隔离

Sat, 04 Jul 2026 14:21:41 +0800

每个 sandbox 实例的 vCPU 数、内存大小、CPU 拓扑结构都通过 annotation cube.vmmres 显式声明,由 CubeShim 注入到 cloud-hypervisor 的 VM 配置里。三个核心要素:

1.2 独立 Guest Kernel(消除共享内核风险)

Sat, 04 Jul 2026 14:21:30 +0800

“独立 Guest Kernel” 指每个 sandbox 启动一台 microVM,VM 内运行的是专属的内核镜像(cube-guest-image-cpu.img),而不是像传统 Linux 容器那样 host kernel 通过 na

1.1 cloud-hypervisor (KVM microVM) 作主 VMM

Sat, 04 Jul 2026 14:21:19 +0800

cloud-hypervisor 是 RustVMM 基金会下的一个 KVM hypervisor,针对 microVM 场景(单租户、启动快、内存极小、安全)做了专门优化。腾讯在 CubeSandbox 中将其内部命名为 cube-hyp

CubeSandbox 安全机制详解

Sat, 04 Jul 2026 14:21:03 +0800

基于《CubeSandbox 安全机制清单.md》(2026/07/03 调研)