Codex沙盒方案

作者：Administrator 发布时间： 2026-06-16 阅读量：3 评论数：0
杂谈 AI开发专题 Linux
#AI #Docker #Linux运维

MaxKB 沙箱替换方案调研报告

结论

推荐选择 Daytona 作为 MaxKB 的主沙箱方案，并通过一个独立的 maxkb-sandbox-adapter 服务让 MaxKB 远程调用 Daytona Sandbox。原因是：

  1. MaxKB 当前对外部 MCP 已经限定为 sse / streamable_http，天然更适合接入远程沙箱服务，而不是在 MaxKB Web 进程里直接启动本地进程。
  2. Daytona 提供 Sandbox 生命周期、文件系统、进程/代码执行、会话、MCP Server、REST API 和 Python SDK，能覆盖 MaxKB 的 skill、Python 工具、Agent 文件/命令工具这几类执行需求。
  3. Daytona 的隔离边界是完整 sandbox，具备独立 kernel、filesystem、network stack、vCPU/RAM/disk 配额和网络限制能力，比 MaxKB 当前的 LD_PRELOAD + sandbox 用户 + 黑名单网络 + resource limit 更强。
  4. 改造路径最小：保留 MaxKB 当前的 ToolExecutor、MCP 配置、Agent 调用主流程，在执行层增加一个远程 sandbox 后端即可；不需要一次性重写 workflow、tool、chat pipeline。

备选方案是 Microsandbox：它更轻量，可以作为本地 POC 或单机私有化部署方案，但目前 README 明确标注 beta，且需要 KVM 或 Apple Silicon，生产稳定性和平台治理能力不如 Daytona。Firecracker / firecracker-containerd 更适合作为底层基础设施，不建议 MaxKB 直接对接。E2B 接入很轻，但自托管复杂且托管服务依赖外部云。clampdown 更偏“AI 编码代理保护宿主项目”的容器沙箱，不适合直接替代 MaxKB 的通用 skill/MCP 执行层。

MaxKB 当前沙箱实现

1. Python 工具 / workflow 工具执行

当前核心执行入口是 MaxKB/apps/common/utils/tool_code.py 中的 ToolExecutor.exec_code()。

执行流程：

  1. 动态生成一段 Python 包装代码，把用户代码 exec(...) 到局部变量。
  2. 取最后一个函数或指定函数名，传入工具参数执行。
  3. 通过 tempfile.NamedTemporaryFile 写入临时 .py 文件。
  4. 调 subprocess.run([sys.executable, execute_file], ...) 执行。
  5. 通过 _ID 标记从 stdout 解析 JSON 结果。

启用沙箱时：

  1. MAXKB_SANDBOX=1 后 _run_user = "sandbox"。
  2. 生成的 Python 包装代码会先 setgid/setuid 到 sandbox 用户。
  3. 子进程环境设置 LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so。
  4. _exec() 使用 RLIMIT_AS 限制内存，sched_setaffinity 限制 CPU 核数，subprocess.run(timeout=...) 限制执行时间。

默认配置来自 MaxKB/installer/Dockerfile-base：

  • MAXKB_SANDBOX=1
  • MAXKB_SANDBOX_HOME=/opt/maxkb-app/sandbox
  • MAXKB_SANDBOX_PYTHON_PACKAGE_PATHS=/opt/py3/lib/python3.11/site-packages,/opt/maxkb-app/sandbox/python-packages,/opt/maxkb/python-packages
  • MAXKB_SANDBOX_PYTHON_BANNED_HOSTS=127.0.0.0/8,localhost,host.docker.internal,172.17.0.0/16,maxkb,pgsql,redis,172.31.250.192/26,0.0.0.0/32,::/0

MaxKB/installer/Dockerfile 会把 MaxKB/installer/sandbox.c 编译成 ${MAXKB_SANDBOX_HOME}/lib/sandbox.so，并额外给 sandbox 目录安装 requests、pymysql、psycopg2-binary。

2. sandbox.c 的限制方式

MaxKB/installer/sandbox.c 使用 LD_PRELOAD hook libc 调用。主要限制包括：

  1. 网络：hook getaddrinfo、connect、sendto、sendmsg，按 .sandbox.conf 的 banned hosts 拦截内网、localhost、数据库、redis 等目标。
  2. 子进程：hook execv、execve、execveat、fork、clone、posix_spawn 等，默认禁止 sandbox 用户创建子进程。
  3. syscall：hook syscall()，对 socket、mount、ptrace、setuid/setgid、mprotect、memfd、io_uring 等调用做黑名单拦截。
  4. 动态库：hook dlopen / dlmopen，只允许从配置的 Python 包路径加载动态库。
  5. 可执行内存：限制匿名 PROT_EXEC mmap 和 mprotect(PROT_EXEC)。

这套方案比裸跑 Python 强，但不是完整虚拟化/容器隔离。它依赖动态链接和 LD_PRELOAD，对静态二进制、解释器漏洞、内核面隔离、文件系统命名空间、网络命名空间、per-run rootfs 等能力都比较有限。

3. Agent / skill / MCP 执行链路

MaxKB 有两种 MCP 相关路径：

  1. 外部 MCP 工具：ToolExecutor.validate_mcp_transport()、ApplicationOperateSerializer.get_mcp_servers()、BaseMcpNode.execute() 都只允许 transport in ["sse", "streamable_http"]。也就是说用户配置的 MCP 服务只能是远程 HTTP/SSE 形态，不能直接配置 stdio 本地进程。
  2. 内部自定义工具转 MCP：在 AI Chat 节点和 chat pipeline 中，普通 CUSTOM 工具会通过 ToolExecutor.get_tool_mcp_config() 动态生成一个 FastMCP stdio server，再交给 langchain_mcp_adapters.MultiServerMCPClient 调用。这个 stdio server 同样使用 LD_PRELOAD=sandbox.so 和 sandbox 目录。

skill 文件执行链路在 MaxKB/apps/application/flow/tools.py：

  1. skill_tool_ids 被收集成 {"tool_id", "file_id", "params"}。
  2. _initialize_skills() 从 File 表取 zip，解压到 /tmp/<chat_id>/skills。
  3. 初始化参数写入每个 skill 顶级目录的 .env。
  4. create_deep_agent(..., backend=SandboxShellBackend(root_dir=temp_dir, virtual_mode=True), skills=["/skills"], tools=tools, ...) 启动 DeepAgents。
  5. SandboxShellBackend 继承 deepagents.backends.LocalShellBackend，执行 shell 命令时如果启用 sandbox，会拼接：
    env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so PATH="${PATH}" PYTHONPATH="${PYTHONPATH}" gosu sandbox <command>。

因此，MaxKB 当前的 skill 和本地工具执行本质上仍是 MaxKB 容器内本地进程执行，只是通过 LD_PRELOAD 和 sandbox 用户做限制；外部 MCP 则是远程 HTTP/SSE 调用。

当前方案的主要问题

  1. 不是强隔离边界：没有每次执行独立 kernel、rootfs、network namespace、mount namespace。
  2. 依赖 LD_PRELOAD：对动态链接路径有效，但不是内核强制的完整隔离策略。
  3. 文件系统隔离弱：主要靠权限和工作目录约束，没有 per-run overlay/rootfs。
  4. 网络策略粗粒度：按 banned host 黑名单拦截，缺少基于 sandbox 实例的默认拒绝、allowlist、审计和动态策略。
  5. 依赖 MaxKB 进程所在容器：用户代码和 MaxKB 主服务共享宿主容器资源边界，逃逸或绕过后的影响面较大。
  6. 扩展依赖困难：只能预装少量 Python 包；复杂依赖、apt、node、浏览器、二进制工具不适合在当前方案里开放。
  7. 本地 MCP 被禁用：MaxKB 自己校验外部 MCP 只允许 sse/streamable_http，说明项目已经意识到本地 stdio MCP 对服务端风险较高。

候选方案评估

方案适配度隔离能力接入复杂度结论
Daytona高高，完整 sandbox，独立 kernel/filesystem/network，支持资源和网络限制中等，需要部署 Daytona 或使用托管服务，再写 adapter推荐主方案
Microsandbox中高高，microVM，本地 SDK，OCI 镜像中等，MaxKB 容器需要 KVM/Apple Silicon 或单独 runner；项目仍 beta推荐 POC/备选
E2B中高，云端安全 VM，SDK 成熟低到中；但自托管依赖 Terraform、云账号、Nomad/Firecracker 等可作为云托管备选
Firecracker中低很高，microVM VMM高，需要自己构建 rootfs、网络、生命周期、API、镜像缓存不建议直接接
firecracker-containerd中高，containerd 管理 Firecracker microVM高，需要特制 containerd、agent、CNI、镜像构建适合作为平台底座，不适合 MaxKB 直接接
clampdown中低容器 + Landlock + seccomp + 网络策略，适合编码代理中到高，场景偏保护项目目录和 agent tool containers不建议作为主方案

Daytona

Daytona README 和官方文档显示，它提供面向 AI-generated code execution 和 agent workflows 的 sandboxes，支持 SDK、API、CLI、MCP Server、进程/代码执行、文件系统、会话、快照和网络限制。官方文档说明每个 sandbox 有独立 kernel、filesystem、network stack 和资源配额，并可限制 egress。

优点：

  1. 和 MaxKB 远程调用模型匹配，能通过 REST 或自建 MCP SSE/Streamable HTTP adapter 接入。
  2. 能运行 Python/TypeScript/JavaScript，也可以基于镜像/快照预装依赖。
  3. 支持长会话、后台进程、文件系统操作，适合 DeepAgents skill 场景。
  4. 有 Python SDK，MaxKB 后端是 Python/Django，集成成本可控。
  5. 后续可演进到统一“沙箱池”：按 workspace、tool、chat session 复用或销毁 sandbox。

缺点：

  1. 比本地 LD_PRELOAD 方案重，需要部署控制面和 runner，或使用 Daytona 托管服务。
  2. 若使用 Daytona MCP 官方 server，它默认是 stdio 配置，MaxKB 当前外部 MCP 不接受 stdio；需要 adapter 转成 HTTP/SSE，或直接用 Daytona SDK/REST。
  3. 私有化部署需要运维 Daytona 组件，需评估资源配额、镜像缓存、并发和计费。

Microsandbox

Microsandbox README 显示它通过 SDK 在本地启动 microVM，可运行 OCI 镜像，支持 Python/TypeScript/Go/Rust SDK，支持 detached long-running sandbox，也提供 MCP server。它强调无需长驻 daemon，直接在代码中 spawn VM。

优点：

  1. 本地化程度高，适合私有部署或 POC。
  2. microVM 硬件隔离强于容器和 LD_PRELOAD。
  3. Python SDK 可直接对接 MaxKB。
  4. 不需要完整控制面，启动链路比 Daytona 更轻。

缺点：

  1. README 明确标注 beta，生产稳定性需要验证。
  2. 需要 Linux KVM 或 Apple Silicon；MaxKB 如果跑在普通 Docker 容器里，通常不能直接访问 KVM，最好还是外置 runner 服务。
  3. 缺少 Daytona 这种平台级治理能力，例如组织、审计、快照管理、远程 API 控制面等。

E2B

E2B 是面向 AI-generated code 的云端 sandbox，Python/JS SDK 简单，Code Interpreter 能力成熟。其自托管文档显示需要 Packer、Terraform、Go、Docker、NPM、Cloudflare、PostgreSQL、AWS/GCP 等，且 AWS 部署涉及 Nomad/Consul、Firecracker client 节点等。

结论：如果可以接受云服务和外部依赖，E2B 接入成本最低；但本任务偏向用 sanbox 目录里的开源方案替换 MaxKB 沙箱，自托管 E2B 的复杂度不适合作为首选。

Firecracker / firecracker-containerd

Firecracker 本身是 VMM，提供 microVM API、jailer、seccomp 等基础能力。firecracker-containerd 则把 containerd 和 Firecracker 结合起来，允许用 OCI 镜像跑在 microVM 中。

结论：两者安全基础很好，但离 MaxKB 需要的“提交一段代码/文件/命令，拿回 stdout/stderr/结构化结果”的产品 API 还很远。若直接接入，需要自研 sandbox manager，包括镜像构建、rootfs、网络、生命周期、并发调度、日志、文件同步、超时、资源回收、API 鉴权等，不建议当前阶段选择。

clampdown

clampdown 面向“在本机/项目目录里安全运行 AI coding agent”。它使用 hardened containers、Landlock、seccomp、iptables、OCI hooks、auth proxy 等，设计目标是限制 agent 访问宿主文件、网络和密钥。

结论：安全设计不错，但它的模型是“保护一个 coding agent 和它启动的工具容器”，不是 MaxKB 这种多租户 Web 服务的通用代码执行平台。作为 MaxKB 主沙箱需要大量适配，收益不如 Daytona / Microsandbox。

推荐架构

总体形态

新增一个独立服务：

MaxKB -> maxkb-sandbox-adapter -> Daytona API/SDK -> Daytona Sandbox

adapter 对 MaxKB 提供两类接口：

  1. HTTP 执行 API：供 ToolExecutor.exec_code()、workflow 工具、知识库 workflow 工具调用。
  2. MCP over Streamable HTTP/SSE：供 MaxKB 当前 MCP 节点和 AI Chat 节点直接以现有 MCP 客户端调用。

建议先实现 HTTP 执行 API，再实现 MCP adapter。原因是 exec_code() 替换后能先解决最危险的“用户 Python 代码本地执行”问题，改造面小，验证也简单。

adapter 核心接口建议

1. 执行 Python 函数

POST /v1/execute/python-function

请求：

{
  "workspace_id": "default",
  "trace_id": "uuid",
  "code": "def foo(a): return a + 1",
  "function_name": "foo",
  "params": {"a": 1},
  "image": "python:3.11",
  "timeout_seconds": 60,
  "resources": {"cpu": 1, "memory_mb": 512},
  "network_policy": {"mode": "deny", "allow": []}
}

响应：

{
  "code": 200,
  "data": 2,
  "stdout": "",
  "stderr": "",
  "duration_ms": 1234,
  "sandbox_id": "..."
}

adapter 内部做的事情：

  1. 创建或复用 Daytona sandbox。
  2. 写入包装脚本和用户代码。
  3. 在 sandbox 内执行 python wrapper.py。
  4. 从 stdout 或结果文件读取结构化 JSON。
  5. 回收 sandbox 或放回池。

2. 执行 shell 命令

POST /v1/execute/command

用于替换 SandboxShellBackend.execute()：

{
  "session_id": "chat_id",
  "command": "python /skills/foo/main.py",
  "cwd": "/workspace",
  "timeout_seconds": 60,
  "env": {},
  "files": [
    {"path": "/skills/xxx.zip", "content_base64": "..."}
  ]
}

3. MCP 服务

/mcp/{workspace_id}/{session_id} 暴露 Streamable HTTP 或 SSE transport。

这个 MCP server 不直接运行工具，而是把 call_tool 转成 Daytona sandbox 内的命令/代码执行。这样 MaxKB 现有 MultiServerMCPClient 可以继续使用，并且符合当前 validate_mcp_transport() 的限制。

MaxKB 改造方案

阶段 1：加远程 Sandbox 执行后端

新增配置：

MAXKB_TOOL_EXECUTOR_BACKEND=local|remote
MAXKB_SANDBOX_ADAPTER_URL=http://maxkb-sandbox-adapter:9000
MAXKB_SANDBOX_ADAPTER_TOKEN=...
MAXKB_SANDBOX_DEFAULT_IMAGE=python:3.11
MAXKB_SANDBOX_TIMEOUT_SECONDS=60
MAXKB_SANDBOX_MEMORY_MB=512
MAXKB_SANDBOX_CPU=1

改造点：

  1. 在 ToolExecutor.exec_code() 中根据 MAXKB_TOOL_EXECUTOR_BACKEND 分流。
  2. local 保留当前逻辑，作为回滚路径。
  3. remote 把 code_str、keywords、function_name 发给 adapter。
  4. 保持返回值和异常语义不变，避免影响上层 workflow。

建议抽象：

class CodeExecutionBackend:
    def exec_code(self, code_str, keywords, function_name=None):
        ...

class LocalPreloadBackend(CodeExecutionBackend):
    ...

class RemoteSandboxBackend(CodeExecutionBackend):
    ...

阶段 2：替换 Agent skill shell backend

当前 SandboxShellBackend 继承 LocalShellBackend，仍然在 MaxKB 容器内执行 shell。建议新增 RemoteSandboxShellBackend：

  1. execute(command, timeout) 调 adapter /v1/execute/command。
  2. root_dir=temp_dir 的技能文件在调用前上传到 sandbox，或由 adapter 从 MaxKB 文件下载接口拉取。
  3. 虚拟路径翻译仍由 MaxKB 保留，但真实路径变成 sandbox 内路径，例如 /workspace/skills/...。
  4. chat session 使用固定 session_id=chat_id，让 Daytona sandbox 可在一次对话中复用文件系统状态。

skill 也应该走这条远程 sandbox 链路。也就是说，替换方案不是只处理 ToolExecutor.exec_code() 里的 Python 函数工具，还要把当前 DeepAgents skill 的 shell/file 执行从 MaxKB 容器内迁移到 Daytona sandbox 内。否则 skill 仍会受 LD_PRELOAD=sandbox.so、gosu sandbox、动态库加载限制、子进程限制和可执行内存限制影响，无法解决原版 MaxKB 对复杂 skill 的限制。

如果 skill 包里包含二进制可执行文件，换成 Daytona / Microsandbox 这类完整 sandbox 后，目标能力上可以支持运行。原因是执行边界从“MaxKB 容器内的进程级 hook”变成“隔离 sandbox/microVM 内执行”，不再依赖 MaxKB 原版的 sandbox.c 去拦截 execve、dlopen、mmap(PROT_EXEC)、mprotect(PROT_EXEC) 等调用。需要注意的是，这不是任意二进制无条件可运行，仍然需要满足以下条件：

  1. 二进制格式和 sandbox 环境匹配，例如 Linux x86_64 ELF 需要跑在 Linux x86_64 sandbox 里。
  2. skill zip 解压后要保留可执行权限；如果上传/解压过程丢失权限，adapter 需要在 sandbox 内按白名单或 manifest 显式执行 chmod +x。
  3. 二进制依赖的动态库、系统工具、字体、浏览器、ffmpeg、glibc/libstdc++ 等必须存在于 sandbox image/snapshot 中。
  4. sandbox 安全策略要允许执行 skill 目录内的文件，但仍要限制 CPU、内存、磁盘、超时、网络和可访问文件范围。
  5. 对需要启动子进程的二进制，不能再套用 MaxKB 原版 SANDBOX_PYTHON_ALLOW_SUBPROCESS=0 这类进程内拦截策略；应改由 sandbox 资源限制和网络策略兜底。

因此，包含二进制的 skill 建议增加一个 skill.json 或类似 manifest，声明入口命令、目标平台、需要的 image/snapshot、环境变量、是否需要可执行权限修复和网络策略。MaxKB 上传 skill 时只做基础校验，adapter 在创建 sandbox 时根据 manifest 选择合适环境。

阶段 3：将内部 CUSTOM 工具转 MCP 的 stdio server 改成远程 MCP

当前 ToolExecutor.get_tool_mcp_config() 返回：

{
  "command": "python",
  "args": ["-c", "..."],
  "cwd": "...",
  "env": {"LD_PRELOAD": "..."},
  "transport": "stdio"
}

这适合内部调用，但仍是本地进程。建议新增：

def get_remote_tool_mcp_config(self, tool, params):
    return {
        "url": f"{ADAPTER_URL}/mcp/tools/{tool.id}",
        "transport": "streamable_http",
        "headers": {"Authorization": f"Bearer {TOKEN}"}
    }

这样 AI Chat 节点里合并 mcp_servers_config 时，不再启动本地 stdio MCP，而是指向 adapter。

阶段 4：MCP 节点和外部 MCP 统一治理

当前 MaxKB 外部 MCP 只能是用户填入的 sse/streamable_http。建议增加两类内置 MCP source：

  1. daytona-sandbox：由 MaxKB 自动生成 adapter MCP 配置。
  2. external：保持用户自定义远程 MCP。

同时增强校验：

  1. URL 只允许管理员配置的 adapter host 或显式 allowlist。
  2. 禁止访问 MaxKB 内网、数据库、Redis、metadata IP。
  3. 所有 MCP call 增加 workspace/user/tool 维度审计。

Daytona adapter 实现建议

沙箱生命周期

建议策略：

  1. 短任务：每次工具调用创建 ephemeral sandbox，执行后销毁。安全最好，成本最高。
  2. 会话任务：按 chat_id 复用 sandbox，空闲 10-30 分钟自动销毁。适合 Agent skill。
  3. 预热池：按 image/snapshot 维护 warm pool。适合高并发场景。

第一阶段可以用短任务；第二阶段引入按会话复用；第三阶段再做预热池。

文件与依赖

  1. Python 工具：把 code 和 wrapper 写入 sandbox 临时目录即可。
  2. skill zip：上传 zip 后在 sandbox 内解压到 /workspace/skills。
  3. 依赖：优先通过 Daytona snapshot/base image 固化，避免每次 pip install。
  4. 允许 workspace 自定义 image/snapshot，但需要管理员审核。
  5. 二进制 skill：保留或修复可执行权限，入口命令只允许指向 skill 工作目录内文件；动态库和系统依赖必须放入 image/snapshot，不建议运行时开放无约束安装。
  6. 平台约束：为 skill 增加 linux/amd64、linux/arm64 等运行平台声明，adapter 根据声明调度到匹配的 Daytona runner 或 Microsandbox runner。
  7. 依赖诊断：adapter 可以在执行失败时返回 file、ldd、退出码、stderr 摘要，帮助判断是格式不匹配、权限缺失还是动态库缺失。

安全策略

adapter 必须做集中控制，不要把 Daytona API key 暴露给 MaxKB 用户代码：

  1. MaxKB 到 adapter 使用服务 token。
  2. adapter 到 Daytona 使用平台级 token。
  3. 每次执行带上 workspace_id、user_id、tool_id、chat_id。
  4. 默认网络策略为 deny 或只允许公网必要域名；禁止访问 MaxKB、Postgres、Redis、metadata、内网 CIDR。
  5. 限制 CPU、内存、磁盘、超时、stdout/stderr 大小。
  6. 禁止把 MaxKB 主服务环境变量转发进 sandbox。
  7. 所有执行记录入库或写审计日志：输入 hash、image、sandbox id、耗时、退出码、错误、网络策略。

风险与验证清单

  1. Daytona 私有化部署复杂度：先用托管 Daytona 或最小 OSS 部署验证 API，再决定生产部署方式。
  2. 执行延迟：对比当前 LD_PRELOAD 本地执行、Daytona cold start、Daytona warm pool 三组 P95。
  3. 兼容性：至少验证普通 Python 工具、带 init_params 的工具、skill zip、AI Chat 工具调用、workflow tool node、mcp-node。
  4. 结果兼容：adapter 返回错误时要和 ToolExecutor.exec_code() 当前异常行为一致，避免前端和 workflow 状态异常。
  5. 资源回收：必须有后台任务清理超时 sandbox，防止 chat session 泄漏。
  6. 网络隔离：测试 sandbox 内访问 127.0.0.1、MaxKB 服务名、Postgres、Redis、云 metadata、内网网段都应失败。
  7. 文件隔离：测试 sandbox 内不能读取 MaxKB 容器文件系统、宿主目录和其他会话文件。
  8. 二进制 skill：测试 Linux ELF 可执行文件、动态链接二进制、需要子进程的二进制、缺少动态库的失败场景、无执行权限的失败/修复场景。
  9. 架构匹配：分别验证 linux/amd64 和 linux/arm64 调度策略，避免在错误架构 sandbox 中执行二进制。

推荐落地计划

POC，1-2 周

  1. 部署 Daytona 或使用 Daytona 托管服务。
  2. 写最小 maxkb-sandbox-adapter，只实现 /v1/execute/python-function。
  3. 给 ToolExecutor.exec_code() 增加 remote backend。
  4. 跑通普通工具调试、workflow 工具节点、知识库 workflow 工具。
  5. 输出延迟、并发、失败率和兼容性报告。

Beta，2-4 周

  1. 实现 /v1/execute/command。
  2. 新增 RemoteSandboxShellBackend，替换 DeepAgents skill shell 执行。
  3. 支持 skill zip 上传/解压、session sandbox 复用、空闲回收。
  4. 加审计日志和资源限制。
  5. 小范围 workspace 灰度。

Production，4-8 周

  1. 实现 MCP over Streamable HTTP/SSE adapter。
  2. get_tool_mcp_config() 支持返回 remote MCP config。
  3. 引入 image/snapshot 管理、warm pool、配额、指标告警。
  4. 默认切 remote backend，保留 local backend 作为短期回滚。
  5. 移除或弱化 MaxKB 容器内 LD_PRELOAD 沙箱承担的安全职责，仅作为兼容后备。

参考资料

本地代码：

  1. MaxKB/apps/common/utils/tool_code.py
  2. MaxKB/apps/application/flow/backend/sandbox_shell.py
  3. MaxKB/apps/application/flow/tools.py
  4. MaxKB/apps/application/flow/step_node/mcp_node/impl/base_mcp_node.py
  5. MaxKB/apps/application/serializers/application.py
  6. MaxKB/apps/tools/serializers/tool.py
  7. MaxKB/installer/sandbox.c
  8. MaxKB/installer/Dockerfile-base
  9. MaxKB/installer/Dockerfile

候选方案资料：

  1. Daytona README：sanbox/daytona/README.md
  2. Daytona Sandboxes 文档：https://www.daytona.io/docs/sandboxes/
  3. Daytona Process & Code Execution 文档：https://www.daytona.io/docs/process-code-execution/
  4. Daytona MCP Server 文档：https://www.daytona.io/docs/mcp/
  5. Microsandbox README：sanbox/microsandbox/README.md
  6. Microsandbox GitHub README：https://github.com/superradcompany/microsandbox
  7. E2B README：sanbox/E2B/README.md
  8. E2B 文档：https://e2b.dev/docs
  9. E2B Self-hosting：https://github.com/e2b-dev/infra/blob/main/self-host.md
  10. Firecracker README：sanbox/firecracker/README.md
  11. firecracker-containerd README：sanbox/firecracker-containerd/README.md
  12. clampdown README：sanbox/clampdown/README.md
上一篇：debian从DVD源切换到网络源
下一篇：GLM-5.2沙盒方案

评论