什么是 ‘Sandbox Isolation for Nodes’：在执行生成的代码节点时，如何通过容器化实现物理断网？

各位同仁，下午好！今天，我们将深入探讨一个在现代软件开发和安全领域至关重要的主题：’Sandbox Isolation for Nodes’，特别是当这些节点被设计用来执行我们无法完全信任的、甚至是动态生成的代码时。我们将聚焦于如何利用容器化技术，实现一种接近“物理断网”的网络隔离效果，从而最大限度地保障宿主环境的安全。

在当今高度动态和交互式的应用环境中，我们经常会遇到这样的场景：用户提交的代码片段（例如在线编程平台、低代码/无代码平台的自定义逻辑、机器学习模型的自定义训练脚本），或者是系统根据特定规则自动生成的代码。这些代码的来源、质量和意图都可能是不可控的。执行这些未知或半知代码，无异于在你的核心系统上打开了一个潜在的潘多拉魔盒。

1. 为什么需要沙箱隔离？——不可信任代码的威胁

想象一下，一个在线编程竞赛平台，选手提交的Python代码如果可以直接访问宿主机的网络，那么他可能尝试：

• 数据窃取： 尝试连接到平台数据库，窃取其他用户的数据。
• 资源滥用： 发起大量的外部网络请求，对外部服务进行DDoS攻击，或者消耗宿主机的带宽资源。
• 系统探测： 扫描宿主机的本地网络端口，发现其他正在运行的服务。
• 恶意通信： 与外部的命令与控制（C2）服务器通信，接收进一步的恶意指令。
• 绕过认证： 尝试利用宿主机可能存在的网络信任关系，绕过防火墙或认证机制。

除了恶意行为，即使是无意的代码错误也可能导致严重后果：

• 无限循环的网络请求： 导致宿主机网络栈过载，影响其他服务的正常运行。
• DNS解析失败： 如果代码依赖外部服务，但由于网络配置问题无法解析域名，会导致程序行为异常。

这些风险都指向一个核心需求：我们必须为这些执行代码的“节点”构建一个高度隔离的运行环境，就像一个沙箱，将它们与宿主系统以及外部世界隔离开来。

2. 沙箱隔离的核心概念

沙箱（Sandbox）在计算机安全中是一个隔离运行程序的机制，它限制了程序对系统资源（如文件系统、网络、内存、CPU等）的访问。其主要目标是：

• 限制范围： 确保不受信任的代码只能在预定义的、受限的环境中运行。
• 资源控制： 防止代码消耗过多的系统资源，导致服务不稳定或拒绝服务。
• 安全防护： 阻止代码对宿主系统或其他敏感数据造成损害或未经授权的访问。

实现沙箱隔离有多种技术途径，从轻量级到重量级不等：

• 进程隔离： 最基本的隔离，通过操作系统提供的进程间通信（IPC）机制，限制不同进程的交互。但同一用户下的进程共享很多资源，隔离性较弱。
• 虚拟机（VM）： 提供硬件级别的虚拟化，每个VM拥有独立的操作系统内核和硬件资源。隔离性最强，但资源开销大，启动慢。
• 容器（Container）： 介于进程隔离和VM之间。它利用操作系统内核提供的命名空间（Namespaces）和控制组（Cgroups）技术，实现了进程、文件系统、网络等资源的隔离和限制。相比VM，容器更轻量、启动更快，资源开销更小，是当前实现沙箱隔离的主流技术。

对于执行生成代码的“节点”场景，容器化技术因其出色的性能、资源效率和强大的隔离能力，成为了理想的选择。

3. 容器化技术：构建隔离的基石

容器化技术，以Docker和Podman为代表，彻底改变了我们部署和管理应用的方式。其核心在于利用Linux内核的两个强大特性：

• Linux Namespaces（命名空间）： 提供了隔离视图的能力。每个命名空间都拥有自己独立的一套系统资源。
  • PID Namespace： 隔离进程ID。容器内看到的PID 1是容器自身的初始化进程，与宿主机PID空间无关。
  • Net Namespace： 隔离网络接口、IP地址、路由表、防火墙规则等网络资源。这是我们实现“物理断网”的关键。
  • Mnt Namespace： 隔离文件系统挂载点。每个容器有自己的根文件系统视图。
  • UTS Namespace： 隔离主机名和域名。
  • IPC Namespace： 隔离进程间通信资源。
  • User Namespace： 隔离用户和组ID。允许容器内的root用户映射到宿主机上的非root用户，增强安全性。
• Cgroups (Control Groups，控制组)： 提供了资源限制和配额管理的能力。
  • CPU Cgroup： 限制容器可用的CPU时间。
  • Memory Cgroup： 限制容器可用的内存量。
  • Block I/O Cgroup： 限制容器的磁盘I/O带宽。
  • PID Cgroup： 限制容器内可以创建的进程数量。

通过这些机制，容器能够在逻辑上为应用程序提供一个独立的运行环境，使其仿佛运行在一个全新的操作系统实例中，而实际上它们共享宿主机的内核。

4. 核心议题：通过容器化实现“物理断网”

“物理断网”这个词在这里需要精确理解。容器化无法真正切断物理网线，但它通过网络命名空间（Net Namespace）在逻辑层面实现了极高强度的网络隔离，其效果等同于该容器内的应用程序无法访问任何外部网络资源，也无法被外部网络访问，除了其自身的回环接口（lo）。

4.1 网络命名空间的魔力

每个Linux进程都属于一个网络命名空间。默认情况下，所有进程都在宿主机的初始网络命名空间中。当创建一个新的容器时，系统会为它创建一个全新的、独立的网络命名空间。

这个新的网络命名空间是“空”的：

• 它只有回环接口（lo）。
• 没有其他网络接口（如eth0）。
• 没有IP地址。
• 没有路由表。
• 没有ARP缓存。
• 没有DNS配置。

这意味着，默认情况下，容器内的进程无法与宿主机或其他容器通信，更无法访问外部网络。这正是我们追求的“物理断网”效果。

4.2 Docker/Podman 中的实现机制

Docker和Podman等容器运行时，提供了一个明确的选项来控制容器的网络模式，以实现这种极致的隔离。

4.2.1 --network none 模式

这是实现“物理断网”最直接、最推荐的方式。当使用--network none参数启动容器时，容器运行时会为容器创建一个独立的网络命名空间，但不会在这个命名空间中配置任何除了回环接口之外的网络设备（如veth对）。

示例代码：启动一个完全隔离网络的Nginx容器

# 1. 尝试在宿主机上ping一个外部地址，确认网络正常
ping -c 3 google.com

# 2. 启动一个Nginx容器，并将其网络模式设置为'none'
# --rm: 容器退出时自动删除
# -d: 后台运行
docker run --rm -d --name isolated_nginx --network none nginx:latest

# 3. 进入容器内部，检查网络接口和尝试网络访问
# docker exec -it isolated_nginx sh: 进入容器的shell环境
# ip a: 查看网络接口
# ping google.com: 尝试ping外部地址
docker exec -it isolated_nginx sh -c "ip a && echo '--- Trying to ping google.com ---' && ping -c 3 google.com || echo 'Ping failed as expected.'"

# 预期输出：
# 容器内部只有lo接口，没有eth0或其他接口
# ping google.com 会失败，提示 'Network is unreachable' 或 'Temporary failure in name resolution'

# 4. 停止并删除容器
docker stop isolated_nginx

ip a 命令在isolated_nginx容器内的预期输出示例：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

可以看到，容器内只有lo回环接口，没有任何连接到外部网络的接口。随后的ping google.com命令将毫无疑问地失败。

4.2.2 默认网络模式（bridge）的对比

作为对比，如果一个容器不指定网络模式，Docker默认会使用bridge模式。在这种模式下：

1. Docker会在宿主机上创建一个名为docker0的虚拟网桥。
2. 为每个容器创建一个veth（虚拟以太网对）。veth对的两端，一端连接到容器的独立网络命名空间作为eth0，另一端连接到docker0网桥。
3. Docker会为容器分配一个IP地址（通常是172.17.0.x）。
4. Docker会在宿主机上配置NAT规则，允许容器通过docker0网桥访问宿主机的外部网络。

示例代码：启动一个默认网络模式的Nginx容器

# 1. 启动一个Nginx容器，使用默认的bridge网络模式
docker run --rm -d --name default_nginx nginx:latest

# 2. 进入容器内部，检查网络接口和尝试网络访问
docker exec -it default_nginx sh -c "ip a && echo '--- Trying to ping google.com ---' && ping -c 3 google.com"

# 预期输出：
# 容器内部除了lo接口，还会有一个eth0接口，并被分配一个IP地址
# ping google.com 会成功

# 3. 停止并删除容器
docker stop default_nginx

ip a 命令在default_nginx容器内的预期输出示例：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
33: eth0@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:2/64 scope link
       valid_lft forever preferred_lft forever

显然，eth0接口的存在以及分配的IP地址，使得容器能够进行网络通信。这与我们所需的“物理断网”效果背道而驰。

4.3 深入理解：Linux网络命名空间的原生操作

为了更深入地理解--network none背后的原理，我们可以手动使用Linux的ip netns命令来创建和管理网络命名空间。

手动创建网络命名空间并验证隔离性：

# 1. 创建一个新的网络命名空间
sudo ip netns add my_isolated_netns

# 2. 查看当前所有网络命名空间
sudo ip netns list
# 应该会看到 my_isolated_netns

# 3. 在新的命名空间中执行命令，查看网络接口
# 此时，新的命名空间中只有lo接口，并且是DOWN状态
sudo ip netns exec my_isolated_netns ip a

# 4. 激活lo接口
sudo ip netns exec my_isolated_netns ip link set lo up

# 5. 再次查看网络接口，lo接口应该处于UP状态
sudo ip netns exec my_isolated_netns ip a

# 6. 在新的命名空间中尝试ping外部地址
# 这将失败，因为没有任何外部网络连接
sudo ip netns exec my_isolated_netns ping -c 3 google.com

# 7. 清理：删除网络命名空间
sudo ip netns del my_isolated_netns

通过这些手动操作，我们可以清楚地看到，容器运行时（如Docker）在内部就是通过类似的Linux内核原语来实现网络隔离的。--network none选项本质上就是告诉容器运行时：创建一个新的网络命名空间，但不要在其中配置任何veth接口或进行任何网络桥接/NAT操作。

4.4 验证“物理断网”效果

要确认一个执行生成代码的节点是否真正实现了网络隔离，我们可以：

1. 尝试DNS解析： 在沙箱内执行nslookup example.com或dig example.com。如果无法解析，说明无法访问DNS服务器。
2. 尝试Ping外部IP： 在沙箱内执行ping 8.8.8.8 (Google DNS)。如果失败，说明无法进行IP层通信。
3. 尝试HTTP/HTTPS请求： 在沙箱内使用curl或wget尝试访问外部网站。如果失败，说明无法进行应用层通信。
4. 查看网络接口： 在沙箱内执行ip a，确认除了lo接口外，没有其他网络接口。
5. 查看路由表： 在沙箱内执行ip r，确认路由表是空的或只包含lo接口相关的路由。

如果以上验证均符合预期（即无法进行外部网络通信，且网络接口和路由表干净），那么我们可以认为该节点已经实现了有效的“物理断网”效果。

5. 超越网络：节点沙箱的全面策略

虽然网络隔离至关重要，但一个健壮的沙箱环境远不止于此。为了执行生成代码的节点提供全面的安全性，我们还需要考虑其他方面的隔离和资源限制。

5.1 文件系统隔离与限制

• 根文件系统只读（Read-Only Root Filesystem）： 使用--read-only参数启动容器。这将使容器的根文件系统（/）变为只读。程序只能在内存中或临时文件系统（如/tmp，如果被配置为tmpfs）中创建文件。这可以防止恶意代码修改或破坏容器镜像，并限制其写入宿主机文件系统的能力。

  docker run --rm --network none --read-only --name restricted_node alpine sh -c "echo 'hello' > /test.txt"
  # 预期输出：/test.txt: Read-only file system

• 精细化卷挂载（Volume Mounting Restrictions）： 仅挂载必要的目录，并且以只读模式挂载代码本身。

  # 假设你的代码在 /tmp/my_code 目录下
  docker run --rm --network none --read-only 
             -v /tmp/my_code:/app:ro   # 将代码目录以只读方式挂载到容器的/app
             -w /app                  # 设置工作目录
             python:3.9-slim python your_script.py

• 临时文件系统（tmpfs）： 为需要临时存储的目录（如/tmp）配置tmpfs。tmpfs是一种内存文件系统，数据不会写入磁盘，在容器停止后会自动消失，进一步增强了数据的瞬时性和隔离性。

  docker run --rm --network none --read-only --tmpfs /tmp:rw,size=64m 
             alpine sh -c "echo 'temp data' > /tmp/data.txt && cat /tmp/data.txt"

5.2 资源限制（Cgroups）

防止无限循环、内存泄漏或CPU密集型操作耗尽宿主机资源。

• CPU限制：
  • --cpus <float>：限制容器可以使用的CPU核心数（例如0.5表示半个核心）。
  • --cpu-shares <int>：CPU份额，用于相对权重分配。
  • --cpu-period <int>和--cpu-quota <int>：更精细的CPU时间限制。

    docker run --rm --network none --cpus 0.5 alpine sh -c "while true; do :; done"
    # 这个命令将无限循环，但其CPU使用率将被限制在宿主机的一个核心的50%

• 内存限制：
  • --memory <bytes>：限制容器可用的内存量（例如256m）。
  • --memory-swap <bytes>：限制内存和交换空间的合计量。

    docker run --rm --network none --memory 256m alpine sh -c "python -c 'a = [0]*int(1e9)'"
    # 尝试分配1GB内存，但容器只有256MB，会因OOM被终止

• 进程数量限制：
  • --pids-limit <int>：限制容器内可以创建的进程/线程数量。

    docker run --rm --network none --pids-limit 64 alpine sh -c "for i in $(seq 100); do sleep 100 & done"
    # 尝试创建100个后台进程，但会被限制在64个

• I/O限制：
  • --blkio-weight <int>：块I/O权重。
  • --device-read-bps <path>:<rate> / --device-write-bps <path>:<rate>：限制特定设备的读写速率。

5.3 用户和权限隔离

• 非Root用户运行： 在容器内以非Root用户身份运行应用程序。这可以通过Dockerfile中的USER指令或docker run命令的--user <user>:<group>参数实现。即使攻击者成功逃逸容器，其在宿主机上获得的权限也是受限的非Root权限。

  docker run --rm --network none --user 1000:1000 alpine sh -c "whoami"
  # 预期输出：1000 (或对应的用户名，如果已在镜像中创建)

• 丢弃特权（Dropping Capabilities）： Linux Capabilities将传统的root权限细分为更小的单元。容器默认会丢弃很多不必要的特权，但为了最高安全性，可以显式丢弃所有特权：--cap-drop ALL。

  docker run --rm --network none --cap-drop ALL alpine sh -c "ping -c 1 127.0.0.1"
  # 即使在lo接口上，ping也需要NET_RAW能力，如果ALL被丢弃，ping会失败。
  # 注意：如果需要任何特定能力，可以单独添加 --cap-add <CAPABILITY>

• 阻止提权： --security-opt no-new-privileges可以防止容器内的进程获得新的特权，即使它们在容器内是root用户。
• Seccomp（Secure Computing Mode）： Seccomp允许你定义一个白名单，只允许容器内的进程调用特定的系统调用（syscall）。Docker默认使用一个预定义的Seccomp配置文件，但你可以提供自定义的配置文件，进一步收紧允许的系统调用集合。
• AppArmor/SELinux： 这些是Linux内核的安全模块，可以提供额外的强制访问控制（MAC），限制容器进程可以执行的操作，例如文件访问、网络访问等。

5.4 PID命名空间隔离

容器默认就拥有独立的PID命名空间，这意味着容器内的进程ID与宿主机上的进程ID是隔离的。容器内的PID 1通常是它的主进程，而不是宿主机的init系统。这防止了容器内的进程直接影响宿主机上的其他进程。

6. 执行生成代码节点的架构与实现

现在，我们将这些沙箱策略整合到一个实际的执行生成代码节点的架构中。

6.1 典型架构概述

一个通用的执行生成代码的系统可能包含以下组件：

1. API Gateway / Frontend： 接收用户提交的代码请求。
2. Queue (e.g., RabbitMQ, Kafka)： 缓冲代码执行请求，解耦前端和执行器。
3. Code Executor Service (Worker Pool)： 核心组件，负责从队列中取出请求，并在沙箱中执行代码。
4. Container Runtime (e.g., Docker Engine, containerd)： 提供容器管理能力。
5. Result Storage (e.g., Database, Object Storage)： 存储代码执行结果（stdout, stderr, 状态码, 资源使用）。

6.2 Code Executor Service 的核心逻辑

Code Executor Service 是我们关注的重点，它将负责创建和管理沙箱。

工作流程：

1. 接收请求： 从队列中获取一个包含用户代码、语言类型、超时时间等信息的请求。
2. 准备环境：
   • 为当前执行任务创建一个唯一的临时工作目录。
   • 将用户代码写入到该临时目录下的一个文件（例如main.py）。
   • 如果需要，还可以准备一些输入数据文件。
3. 构建容器执行命令： 根据请求的语言类型，选择合适的预构建容器镜像（例如python:3.9-slim, node:16-alpine, openjdk:17-jre-slim）。
   • 关键是包含所有沙箱参数： --network none, --read-only, --memory, --cpus, --pids-limit, --cap-drop ALL, --security-opt no-new-privileges, --user。
   • 将临时工作目录以只读方式挂载到容器内部的特定路径（例如/app）。
   • 设置容器的工作目录为/app。
   • 构建容器内要执行的命令（例如python main.py）。
4. 执行容器： 使用subprocess模块或其他编程语言的进程管理工具来启动Docker/Podman命令。
   • 设置一个外部的执行超时机制，以防止容器内的代码无限运行。
   • 捕获容器的stdout和stderr。
5. 结果收集与清理：
   • 等待容器执行完成或超时。
   • 获取容器的退出码。
   • 收集stdout、stderr和执行状态。
   • 非常重要： 确保容器在执行结束后被停止并删除（--rm参数）。
   • 清理临时工作目录。
6. 存储结果： 将执行结果发送到结果存储系统。

Python 伪代码示例：

import subprocess
import os
import shutil
import tempfile
import json
import time

def get_language_image_and_command(language):
    """
    根据语言获取对应的Docker镜像和容器内执行命令
    """
    if language == "python":
        return "python:3.9-slim", ["python", "main.py"]
    elif language == "node":
        return "node:16-alpine", ["node", "main.js"]
    elif language == "java":
        # 假设Java代码编译后生成Main.class
        return "openjdk:17-jre-slim", ["java", "Main"]
    else:
        raise ValueError(f"Unsupported language: {language}")

def execute_code_in_sandbox(code_str: str, language: str, timeout_seconds: int = 30):
    """
    在沙箱容器中执行用户生成的代码。
    实现网络隔离、资源限制和文件系统只读。
    """
    temp_dir = None
    container_name = f"code_executor_{os.urandom(4).hex()}_{int(time.time())}"

    try:
        # 1. 创建临时工作目录
        temp_dir = tempfile.mkdtemp(prefix="code_sandbox_")

        # 2. 将代码写入文件
        if language == "python":
            code_filename = "main.py"
        elif language == "node":
            code_filename = "main.js"
        elif language == "java":
            # 对于Java，我们假设用户提交的是可编译的源代码
            # 实际生产中可能需要一个编译步骤，或者直接接收编译后的字节码
            code_filename = "Main.java"
            # 这里为了简化，我们假设直接运行Java文件，实际需要javac编译
            # 复杂的Java编译和运行流程可能需要更定制化的镜像或多阶段构建
        else:
            raise ValueError(f"Unsupported language for file creation: {language}")

        code_file_path = os.path.join(temp_dir, code_filename)
        with open(code_file_path, "w") as f:
            f.write(code_str)

        # 3. 获取语言对应的镜像和执行命令
        image_name, container_exec_command = get_language_image_and_command(language)

        # 如果是Java，需要先编译
        if language == "java":
            # 假设在容器内部编译
            compile_command = ["javac", code_filename]
            # 确保编译命令在执行命令之前运行
            container_exec_command = ["sh", "-c", " ".join(compile_command) + " && " + " ".join(container_exec_command)]

        # 4. 构建Docker命令，包含所有沙箱参数
        docker_cmd = [
            "docker", "run",
            "--rm",                                     # 容器退出时自动删除
            "--name", container_name,                   # 为容器指定一个唯一名称
            "--network", "none",                        # *** 关键：网络隔离 ***
            "--read-only",                              # 根文件系统只读
            "--memory", "256m",                         # 内存限制 256MB
            "--cpus", "0.5",                            # CPU 限制 0.5个核心
            "--pids-limit", "64",                       # 进程数量限制 64
            "--cap-drop", "ALL",                        # 丢弃所有Linux Capabilities
            "--security-opt", "no-new-privileges",      # 阻止提权
            "--user", "1000:1000",                      # 以非root用户运行 (假设镜像内有UID 1000)
            "-v", f"{temp_dir}:/app:ro",                # 将代码目录以只读方式挂载到容器的/app
            "-w", "/app",                               # 设置容器工作目录为/app
            image_name,                                 # 使用指定语言的镜像
        ] + container_exec_command                      # 容器内要执行的命令

        print(f"Executing Docker command: {' '.join(docker_cmd)}")

        # 5. 执行Docker命令并设置超时
        start_time = time.monotonic()
        process = subprocess.run(
            docker_cmd,
            capture_output=True,
            text=True,
            timeout=timeout_seconds,
            check=False # 不抛出异常，而是检查returncode
        )
        end_time = time.monotonic()

        stdout = process.stdout.strip()
        stderr = process.stderr.strip()
        exit_code = process.returncode
        execution_time = round(end_time - start_time, 3)

        # 6. 处理可能的超时
        if process.returncode is None: # 表示进程被timeout杀死
            exit_code = -1
            stderr = f"Execution timed out after {timeout_seconds} seconds. {stderr}"
            print(f"Container {container_name} timed out. Trying to stop...")
            subprocess.run(["docker", "kill", container_name], capture_output=True) # 强制停止容器

        return {
            "stdout": stdout,
            "stderr": stderr,
            "exit_code": exit_code,
            "execution_time_seconds": execution_time,
            "status": "Success" if exit_code == 0 else "Failed" if exit_code != -1 else "Timeout"
        }

    except subprocess.TimeoutExpired:
        # subprocess.run(timeout=...) 会抛出 TimeoutExpired 异常
        # 如果捕获到，说明Docker命令本身超时了，这意味着容器可能还在运行
        # 需要尝试停止并删除它
        print(f"Docker command execution timed out (Outer timeout). Trying to stop container {container_name}...")
        try:
            subprocess.run(["docker", "kill", container_name], capture_output=True)
            subprocess.run(["docker", "rm", container_name], capture_output=True)
        except Exception as e:
            print(f"Error stopping/removing container {container_name}: {e}")
        return {
            "stdout": "",
            "stderr": f"System timeout (Docker command itself took too long or container didn't respond). Max allowed was {timeout_seconds} seconds.",
            "exit_code": -2,
            "execution_time_seconds": timeout_seconds,
            "status": "System Timeout"
        }
    except Exception as e:
        return {
            "stdout": "",
            "stderr": f"Executor internal error: {e}",
            "exit_code": -3,
            "execution_time_seconds": 0,
            "status": "Executor Error"
        }
    finally:
        # 7. 清理临时目录
        if temp_dir and os.path.exists(temp_dir):
            shutil.rmtree(temp_dir)
            print(f"Cleaned up temporary directory: {temp_dir}")

# --- 演示调用 ---
if __name__ == "__main__":
    print("--- Testing Python Code (Success) ---")
    python_code_success = """
import requests
print("Hello from Python sandbox!")
try:
    response = requests.get("http://www.google.com")
    print(f"Requests to Google: {response.status_code}")
except Exception as e:
    print(f"Requests failed as expected: {e}")

with open('/tmp/test.txt', 'w') as f:
    f.write('Temporary file content')
print(f"Content of /tmp/test.txt: {open('/tmp/test.txt').read()}")
    """
    result = execute_code_in_sandbox(python_code_success, "python", timeout_seconds=10)
    print(json.dumps(result, indent=2))
    print("n" + "="*50 + "n")

    print("--- Testing Node.js Code (Network Failure) ---")
    nodejs_code_network_fail = """
const http = require('http');
console.log("Hello from Node.js sandbox!");
http.get('http://www.google.com', (res) => {
  console.log(`Status Code: ${res.statusCode}`);
}).on('error', (e) => {
  console.error(`Network request failed as expected: ${e.message}`);
});
"""
    result = execute_code_in_sandbox(nodejs_code_network_fail, "node", timeout_seconds=10)
    print(json.dumps(result, indent=2))
    print("n" + "="*50 + "n")

    print("--- Testing Python Code (Memory Limit Exceeded) ---")
    python_code_mem_leak = """
a = [0] * int(1024 * 1024 * 1024 / 4) # Allocate 1GB of integers
print("Allocated 1GB memory")
"""
    result = execute_code_in_sandbox(python_code_mem_leak, "python", timeout_seconds=10)
    print(json.dumps(result, indent=2))
    print("n" + "="*50 + "n")

    print("--- Testing Python Code (Timeout) ---")
    python_code_timeout = """
import time
print("Starting long operation...")
time.sleep(15) # Sleep for 15 seconds
print("Operation finished.")
"""
    result = execute_code_in_sandbox(python_code_timeout, "python", timeout_seconds=5)
    print(json.dumps(result, indent=2))
    print("n" + "="*50 + "n")

关键点：

• --network none：确保网络隔离。
• --read-only和-v ...:ro：确保文件系统隔离和只读。
• --memory、--cpus、--pids-limit：确保资源限制。
• --user和--cap-drop ALL：确保权限最小化。
• --rm：确保容器用完即焚，不留下痕迹。
• subprocess.run(timeout=...)：防止代码长时间运行。
• 完善的错误处理和资源清理。

6.3 容器镜像管理

为不同语言和运行时环境维护一组预构建的、最小化的、安全加固的Docker镜像至关重要。

示例 Dockerfile (Python):

# Dockerfile for a sandboxed Python execution environment
FROM python:3.9-slim-buster

# Create a non-root user
RUN adduser --system --uid 1000 --group 1000 appuser

# Set working directory
WORKDIR /app

# Ensure /tmp is available for temporary files (will be tmpfs if configured by docker run)
RUN mkdir -p /tmp && chown appuser:appuser /tmp && chmod 1777 /tmp

# Switch to non-root user
USER appuser

# Entrypoint (optional, can be overridden by docker run command)
# ENTRYPOINT ["python"]
# CMD ["main.py"]

# Note: We don't install any network tools like curl, wget, ping here
# to minimize attack surface, as --network none will prevent their use anyway.

这个Dockerfile创建了一个包含非root用户的最小化Python环境。在docker run时，我们会将宿主机的代码目录挂载到容器的/app，并以appuser身份执行。

6.4 考虑事项

• 性能开销： 容器启动有一定的开销，对于QPS极高的场景，可能需要维护一个预热的容器池。
• 宿主机安全： 即使容器提供了强大的隔离，宿主机的安全性仍然是最终防线。保持宿主机系统和Docker引擎的最新，配置严格的防火墙规则，限制对Docker守护进程的访问。
• 日志和监控： 捕获容器的日志和资源使用情况，以便调试和审计。
• 复杂依赖： 如果生成的代码依赖复杂的外部库或数据，需要考虑如何在沙箱环境中安全地提供这些依赖。这可能涉及在镜像中预装，或者通过只读卷挂载。但任何额外挂载或配置都可能引入新的攻击面。
• 容器逃逸： 尽管不太常见，但容器逃逸漏洞仍然存在。通过及时更新内核、使用最新的Docker版本、启用Seccomp/AppArmor、以非特权模式运行容器、以及避免使用--privileged等参数来降低风险。

7. 挑战与高级考量

尽管--network none提供了最强的网络隔离，但在某些特定场景下，我们可能需要“受控的”网络访问。例如，允许代码访问一个内部的、严格受限的数据库服务，或者一个特定的API端点。

在这种情况下，--network none就不再适用。我们需要切换到其他网络模式（如自定义bridge网络），并结合严格的防火墙规则（iptables）和网络策略（Network Policies，如果使用Kubernetes）来精确控制容器的出站和入站流量。这会显著增加复杂性，因为你需要在主机层面或容器网络层面维护一套白名单机制，这与“物理断网”的简单性相悖。因此，如果需求是“物理断网”，就应坚持使用--network none。如果确实需要有限的网络访问，那就不再是纯粹的“物理断网”，而是一种受限的网络通信，需要单独设计安全策略。

8. 总结

在执行生成代码的节点时，沙箱隔离是不可或缺的安全实践。容器化技术，尤其是Docker和Podman，通过其强大的Linux命名空间和控制组特性，提供了一种高效且可靠的沙箱解决方案。--network none模式是实现“物理断网”般网络隔离的黄金标准，它确保了代码节点无法进行任何外部网络通信，极大地降低了数据窃取和恶意行为的风险。

然而，网络隔离仅仅是全面沙箱策略的一部分。结合文件系统只读、资源限制、用户和权限降级等措施，我们可以构建一个多层次、高强度的隔离环境，从而安全地执行不可信的代码，保护核心系统的完整性和可用性。在设计和实现此类系统时，务必坚持最小特权原则，并持续关注容器安全领域的最新进展。