容器逃逸的五类真实路径与 eBPF 检测工程

容器逃逸不再是安全会议的演示素材，而是生产环境中真实发生的入侵路径。2024 至 2026 年间，从 runc 的 "Leaky Vessels" 系列到 2025 年末的三个竞态条件漏洞，从 Gitea CI Runner 的参数注入到 NVIDIA Container Toolkit 的 OCI Hook 劫持，容器逃逸的利用面已经从"内核零日"扩展到"配置缺陷 + 竞态条件 + 供应链污染"的组合拳。攻击者的核心策略并未改变：以最低成本突破隔离边界，然后在宿主机或集群层面横向移动。

本文的核心问题是：**当容器逃逸的手段已经如此多样化，检测工程应该如何设计才能覆盖真实攻击路径？**

答案是：依靠 eBPF 将监控下沉到内核系统调用层，在容器内进程尚未完成逃逸动作之前捕获异常行为。传统基于用户空间 Agent 的方案存在结构性弱点——Agent 与被监控对象处于同一权限层级，容器内 root 权限可直接 kill 掉 Agent 或篡改日志。eBPF 探针运行在内核上下文，攻击者必须先完成容器逃逸才能触及探针，这构成了检测工程的根本优势。

本文先按五类真实路径拆解逃逸原理与关键 CVE，再给出基于 Falco 和 Tetragon 的检测规则设计与落地策略，最后讨论检测误报治理与工程化部署边界。

## 一、五类真实逃逸路径：从配置错误到内核漏洞

容器逃逸的攻击面可按"利用难度从低到高、发生频率从高到低"划分为五类。以下表格给出路径特征、必要条件与代表性 CVE：

| 路径类别 | 核心机制 | 必要条件 | 代表性 CVE / 案例 | 检测难度 |
|---------|---------|---------|------------------|---------|
| 配置缺陷 | 危险挂载、特权模式、命名空间共享 | 管理员配置错误 | CVE-2026-58053 (act_runner 参数注入)、Docker socket 挂载 | 中——行为明显但需基线 |
| 运行时竞态 | 符号链接欺骗、文件描述符泄漏、挂载竞态 | root 权限 + 自定义镜像 | CVE-2025-31133/52565/52881 (runc 三漏洞)、CVE-2024-21626 (Leaky Vessels) | 高——时间窗口极短 |
| 内核漏洞 | 内存竞争、UAF、越界写 | 特定内核版本 + 触发条件 | CVE-2024-1086 (netfilter UAF)、CVE-2022-0847 (Dirty Pipe) | 中——可利用特征有限 |
| 供应链污染 | 恶意镜像、OCI Hook 劫持、LD_PRELOAD | 镜像来源不可信 | CVE-2025-23266 (NVIDIAScape)、TeamPCP APT 案例 | 高——行为与正常业务混淆 |
| 凭证与 API 滥用 | ServiceAccount Token、Kubelet API、Docker API | Token 泄露或过度授权 | CVE-2025-9074 (Docker Desktop API)、K8s RBAC 滥用 | 低——API 审计可覆盖 |

### 1.1 配置缺陷：最容易被忽视的高频入口

配置缺陷占容器逃逸事件的 90% 以上。其核心逻辑不是"漏洞"，而是"管理员主动打开了隔离门"。

**高危配置组合**（任一组合都可能导致逃逸）：

- `privileged: true`：授予全部 Linux capabilities 和宿主机设备访问权
- `hostPath` 挂载 `/`、`/proc`、`/sys`、`/var/run/docker.sock`
- `hostPID: true` / `hostNetwork: true` / `hostIPC: true`
- `capabilities.add: [SYS_ADMIN, SYS_MODULE, SYS_PTRACE, NET_ADMIN]`
- `security-opt seccomp=unconfined` 或 `apparmor=unconfined`

一个典型的多阶段逃逸示例：攻击者先通过 Web 漏洞进入容器，发现容器配置了 `hostPID: true` 和 `CAP_SYS_PTRACE`，于是对宿主机进程执行 `ptrace` 注入，从内存中提取出 Kubernetes ServiceAccount Token，随后通过 API Server 创建一个 `privileged: true` 的新 Pod，完成集群级权限提升。

CVE-2026-58053 则展示了配置缺陷在 CI/CD 场景中的变种：Gitea act_runner 强制 `privileged: false`，但未过滤 `container.options` 参数。攻击者通过 `--pid=host --ipc=host --cap-add=ALL --security-opt seccomp=unconfined` 的组合，在不触发 privileged 拦截的情况下完成 nsenter 逃逸。

### 1.2 运行时竞态：符号链接与文件描述符的暗战

运行时竞态漏洞利用的是容器启动阶段的"黄金窗口"——安全控制尚未完全生效，攻击者通过符号链接或 fd 替换改变运行时行为。

**CVE-2024-21626 (Leaky Vessels)** 的根本原因是 runc 在 `setcwd(2)` 前未关闭内部文件描述符。攻击者将容器工作目录设为 `/proc/self/fd/7`（指向宿主机 cgroup 目录），容器进程启动后实际落在宿主机文件系统中，通过 `../../` 遍历即可访问整个宿主机。

**CVE-2025-31133/52565/52881** 则是 2025 年 11 月披露的三个竞态条件漏洞，核心机制均为符号链接欺骗：

- **CVE-2025-31133**：runc 使用 bind mount `/dev/null` 来"屏蔽"敏感 procfs 文件（如 `/proc/sys/kernel/core_pattern`）。攻击者在容器创建期间将 `/dev/null` 替换为指向宿主机任意文件的符号链接，导致该文件被挂载到容器内并可写。
- **CVE-2025-52565**：runc 将 `/dev/pts/$n` bind mount 到容器内的 `/dev/console`。攻击者通过竞态将 `/dev/pts/$n` 替换为符号链接，在 maskedPaths/readonlyPaths 生效前获得敏感 procfs 文件的写权限。
- **CVE-2025-52881**：runc 在设置 LSM（AppArmor/SELinux）标签时向 `/proc/self/attr/current` 写入策略。攻击者通过共享挂载点竞态将写入重定向到 `/proc/sysrq-trigger` 等危险文件，导致 LSM 策略未被应用或触发 DoS。

这三个漏洞的共同点是：**攻击者无需内核漏洞，仅需 root 权限和自定义镜像，在容器启动的毫秒级窗口内完成竞态触发。**

### 1.3 内核漏洞：共享内核的结构性风险

容器与宿主机共享同一个内核，这是容器轻量的根源，也是安全的结构性弱点。一旦内核存在可被触发的漏洞，容器内的攻击者可直接提权并突破命名空间隔离。

**CVE-2024-1086**（Linux 内核 netfilter nf_tables UAF）是一个典型例子：位于 nftables 子系统的 use-after-free 漏洞，攻击者通过精心构造的系统调用序列将双释放转化为内存覆盖，进而修改当前进程的安全凭证（uid/gid）。CISA 在 2025 年 10 月确认该漏洞已被 RansomHub、Akira 等勒索软件组织在野外利用。

**CVE-2022-0847 (Dirty Pipe)** 则展示了另一类内核机制滥用：Linux 管道缓冲区未正确初始化 `flags` 成员，导致任意文件覆写。攻击者在容器内覆盖 `/etc/passwd` 或 `/etc/crontab` 即可实现提权和持久化。

内核漏洞的检测难点在于：触发条件往往高度依赖特定内核版本和精确的系统调用序列，传统基于签名的检测规则难以覆盖。

### 1.4 供应链污染：从镜像构建到 OCI Hook

供应链攻击将逃逸前置到容器尚未运行的阶段。攻击者不需要等待容器启动，而是在镜像或运行时组件中预埋恶意逻辑。

**CVE-2025-23266 (NVIDIAScape)** 是最具代表性的案例：NVIDIA Container Toolkit 的 `enable-cuda-compat` OCI Hook 在容器创建阶段以 root 权限在宿主机执行，且继承了容器镜像中的环境变量。攻击者仅需在 Dockerfile 中设置 `ENV LD_PRELOAD=/proc/self/cwd/poc.so`，即可让 Hook 加载容器内的恶意共享库，在宿主机 root 上下文中执行任意代码。

攻击流程极简：

```dockerfile
FROM busybox
ENV LD_PRELOAD=/proc/self/cwd/poc.so
ADD poc.so /
```

整个过程中，容器本身甚至不需要 GPU 需求。Wiz Research 评估，37% 的使用 NVIDIA GPU 的云环境存在此漏洞风险。

### 1.5 凭证与 API 滥用：逃逸之后的权限放大器

即使攻击者仅获得容器内的低权限 shell，集群中的凭证泄露和 API 滥用仍可使其完成逃逸后的权限放大。

- **ServiceAccount Token**：默认自动挂载到 `/var/run/secrets/kubernetes.io/serviceaccount/token`，若 RBAC 配置宽松，攻击者可直接调用 API Server 创建特权 Pod
- **Kubelet API**：若 `--anonymous-auth=true` 或 `--read-only-port=10255` 未关闭，攻击者可读取节点上所有 Pod 信息，甚至在某些配置下执行命令
- **Docker API**：Docker Desktop CVE-2025-9074 在内部网络暴露 TCP 2375 端口且无需认证，容器内可直接调用 API 创建特权容器并挂载宿主机根目录

凭证滥用路径的检测相对容易——API 审计日志记录了"谁做了什么"，难点在于Token 的自动挂载和 RBAC 的最小权限设计需要前置治理。

## 二、eBPF 检测工程：从"看得见"到"拦得住"

传统容器安全方案依赖用户空间 Agent（DaemonSet 或 Sidecar），但这些 Agent 与被监控进程共享同一权限边界。攻击者一旦在容器内获得 root 权限，第一步往往是 `kill -9` 干掉 Agent，或对日志执行 `truncate`，此后发生的一切彻底不可见。

eBPF 的核心优势在于**权限层级隔离**：探针挂接在 Linux 内核的系统调用接口上，容器内进程无法直接触及。攻击者要禁用 eBPF 探针，必须先完成容器逃逸、拿到宿主机内核控制权——这与 kill 一个用户空间进程的难度完全不在一个量级。

### 2.1 三层检测架构

基于 eBPF 的容器逃逸检测应构建三层架构：

```mermaid
graph TD
    subgraph L1["L1: 系统调用层 — eBPF kprobes/tracepoints"]
        A1["execve / clone / fork"]
        A2["mount / umount / pivot_root"]
        A3["setns / unshare"]
        A4["openat / write 敏感路径"]
        A5["connect / socket 异常网络"]
    end
    subgraph L2["L2: 行为规则层 — Falco / Tetragon 策略引擎"]
        B1["规则匹配: 特权提升 / 命名空间切换"]
        B2["规则匹配: 敏感文件写入 / 设备访问"]
        B3["规则匹配: 异常进程树 / shell 启动"]
    end
    subgraph L3["L3: 响应执行层"]
        C1["Falco: 告警输出 → SIEM / Webhook"]
        C2["Tetragon: 内核级 kill / 网络隔离"]
        C3["自动化: 隔离 Pod / 阻断流量 / 通知值班"]
    end
    L1 --> L2 --> L3
```

- **L1 系统调用层**：eBPF 程序挂载到 `sys_enter_execve`、`sys_enter_mount`、`sys_enter_setns` 等 tracepoint，或 `do_mount`、`pivot_root` 等 kprobe。采集的数据包含进程上下文（PID、Namespace、Capability、容器元数据）。
- **L2 行为规则层**：Falco 和 Tetragon 在这一层提供策略引擎。Falco 侧重"检测+告警"，Tetragon 支持"检测+实时阻断"。
- **L3 响应执行层**：告警通过 falcosidekick 转发到 Slack/PagerDuty/SIEM；Tetragon 则可在内核同步执行 `SIGKILL` 或网络丢弃，响应时间是微秒级。

### 2.2 Falco 规则设计：覆盖五类逃逸路径

Falco 的规则语法基于 YAML，通过 `condition` 字段匹配系统调用事件。以下规则覆盖五类逃逸路径的核心行为。

**规则 1：检测特权容器启动（配置缺陷）**

```yaml
- rule: Privileged Container Started
  desc: "检测以 privileged 模式启动的容器"
  condition: >
    spawned_process and container and
    (proc.args contains "--privileged" or
     proc.args contains "privileged=true" or
     proc.args contains "Privileged=true")
  output: >
    Privileged container started
    (user=%user.name command=%proc.cmdline
     container=%container.id image=%container.image.repository)
  priority: CRITICAL
```

**规则 2：检测 hostPath 挂载敏感目录（配置缺陷）**

```yaml
- rule: Sensitive HostPath Mounted
  desc: "检测挂载宿主机敏感路径到容器"
  condition: >
    spawned_process and container and
    (proc.args contains "/var/run/docker.sock" or
     proc.args contains "hostPath" and
     (proc.args contains "path: /" or
      proc.args contains "path: /proc" or
      proc.args contains "path: /sys"))
  output: >
    Sensitive hostPath mount detected
    (user=%user.name command=%proc.cmdline
     container=%container.id)
  priority: CRITICAL
```

**规则 3：检测容器内 nsenter / setns 调用（逃逸执行）**

```yaml
- rule: Namespace Escape Attempt
  desc: "检测容器内尝试切换到宿主机命名空间"
  condition: >
    spawned_process and container and
    (proc.name = "nsenter" or proc.name = "setns") and
    (proc.args contains "-t 1" or
     proc.args contains "--target 1" or
     proc.args contains "--mount=/proc/1/ns")
  output: >
    Namespace escape attempt detected
    (user=%user.name command=%proc.cmdline
     container=%container.id image=%container.image.repository)
  priority: CRITICAL
```

**规则 4：检测 /proc/self/fd 工作目录（CVE-2024-21626）**

```yaml
- rule: CVE-2024-21626 Exploitation
  desc: "检测利用 runc fd 泄漏的逃逸尝试"
  condition: >
    spawned_process and container and
    (proc.cwd startswith "/proc/self/fd" or
     proc.args contains "/proc/self/fd/")
  output: >
    Potential CVE-2024-21626 exploitation
    (user=%user.name cwd=%proc.cwd
     command=%proc.cmdline container=%container.id)
  priority: CRITICAL
```

**规则 5：检测可疑内核模块加载（内核漏洞利用）**

```yaml
- rule: Kernel Module Load from Container
  desc: "检测容器内尝试加载内核模块"
  condition: >
    spawned_process and container and
    (proc.name = "insmod" or proc.name = "modprobe") and
    not proc.args contains "/lib/modules"
  output: >
    Kernel module load from container
    (user=%user.name command=%proc.cmdline
     container=%container.id image=%container.image.repository)
  priority: CRITICAL
```

**规则 6：检测容器内反弹 shell（逃逸后横向移动）**

```yaml
- rule: Reverse Shell in Container
  desc: "检测容器内启动反向 shell"
  condition: >
    spawned_process and container and
    (proc.name in (bash, sh, zsh, python, python3, perl, ruby)) and
    (proc.args contains "/dev/tcp/" or
     proc.args contains "socket" or
     proc.args contains "nc -e" or
     proc.args contains "bash -i")
  output: >
    Potential reverse shell in container
    (user=%user.name command=%proc.cmdline
     container=%container.id image=%container.image.repository)
  priority: CRITICAL
```

### 2.3 Tetragon 实时阻断：从"告警"到"kill"

Falco 的局限是只能检测和告警，无法实时阻断。Tetragon 作为 Cilium 的子项目，可在内核同步执行策略，在恶意系统调用完成前发送 `SIGKILL`。

**TracePolicy 示例：阻断特权提升和命名空间切换**

```yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-container-escape
spec:
  kprobes:
    - call: "__x64_sys_setns"
      syscall: true
      args:
        - index: 0
          type: "int"
      selectors:
        - matchNamespaces:
            - namespace: pid
              operator: NotIn
              values:
                - "host"
          matchActions:
            - action: Sigkill
    - call: "__x64_sys_mount"
      syscall: true
      selectors:
        - matchCapabilities:
            - type: Permitted
              operator: In
              values:
                - "CAP_SYS_ADMIN"
          matchActions:
            - action: Sigkill
```

该策略的逻辑是：

1. **阻断 setns**：当容器内进程尝试调用 `setns` 切换到非当前 PID namespace 时（即试图进入宿主机命名空间），Tetragon 在内核层直接发送 `SIGKILL`
2. **阻断 mount**：当进程持有 `CAP_SYS_ADMIN` 并执行 `mount` 系统调用时，直接终止进程

Tetragon 的响应时间是**微秒级**——传统 EDR 的响应链是"事件→用户空间 Agent→规则引擎→响应动作"，延迟在毫秒到秒级；Tetragon 将规则引擎下沉到内核，在系统调用返回前完成判定和阻断。

### 2.4 检测覆盖矩阵

将五类逃逸路径映射到 Falco 规则和 Tetragon 策略：

| 逃逸路径 | Falco 规则 | Tetragon 策略 | 检测时机 |
|---------|-----------|--------------|---------|
| 配置缺陷（privileged/hostPath） | Privileged Container Started / Sensitive HostPath Mounted | — | 容器启动 |
| 运行时竞态（runc 符号链接欺骗） | CVE-2024-21626 Exploitation / Namespace Escape Attempt | 阻断 setns + mount | 容器启动/运行时 |
| 内核漏洞（Dirty Pipe / UAF） | Kernel Module Load from Container | 阻断 init_module | 漏洞触发时 |
| 供应链污染（LD_PRELOAD Hook） | —（需镜像扫描前置） | 阻断 execve 异常库加载 | Hook 执行时 |
| 凭证/API 滥用（Token 窃取） | —（需 K8s Audit Log） | — | API 调用时 |

该矩阵揭示了一个重要边界：**eBPF 系统调用监控无法覆盖凭证/API 滥用路径**。ServiceAccount Token 的滥用发生在 Kubernetes API 层面，需通过 K8s Audit Log 和 OPA/Gatekeeper 准入控制来检测和阻断。供应链污染的前置检测则需要镜像扫描（Trivy/Grype）和镜像签名（Cosign）在 CI/CD 阶段拦截。

## 三、误报治理：别让检测变成噪音

eBPF 探针捕获的是系统调用级别的原始事件，任何容器内的正常操作（如 CI/CD 构建、调试工具启动、初始化脚本执行）都可能触发规则。未经调优的检测规则在生产环境中会产生海量告警，最终淹没真正的攻击信号。

### 3.1 三类典型误报来源

| 误报类型 | 典型场景 | 调优策略 |
|---------|---------|---------|
| 合法管理操作 | `kubectl exec` 进入容器调试、运维脚本执行 `mount` 或 `nsenter` | 建立"维护窗口"白名单，按时间段 + 服务账号 + 容器镜像哈希排除 |
| 构建/CI 行为 | Jenkins/GitLab Runner 在容器内执行 `docker build`、临时挂载 `/var/run/docker.sock` | CI 节点与生产节点分离，CI 专用节点降低检测优先级或走独立规则集 |
| 基础镜像共性 | 镜像初始化脚本调用 `setns`、`unshare` 或加载内核模块 | 按镜像仓库 + tag 签名建立白名单，只检测白名单外的异常 |

### 3.2 调优方法论

**基线建立阶段（2-4 周）**：

1. 新规则上线时 `priority` 设为 `WARNING` 而非 `CRITICAL`，只收集不阻断
2. 每日分析告警 TOP-10，识别重复误报模式
3. 将高频误报写入 `falco_rules.local.yaml` 的 `exceptions` 或 `macros` 排除

**生产强制执行阶段**：

1. 规则误报率 <1% 时，提升为 `CRITICAL` 并接入告警通道
2. Tetragon `Sigkill` 策略优先部署在非生产环境验证至少 1 个月
3. 建立 "逃生舱" 机制——规则误杀时可快速回退到 `Log` 模式而不重启集群

**Tetragon 的 "观察→告警→阻断" 分阶段策略**：

| 阶段 | action 值 | 目的 | 持续时间 |
|-----|----------|------|---------|
| 观察 | `Log` | 记录事件，无阻断，建立基线 | 2-4 周 |
| 告警 | `Sigkill` + 告警通道 | 实时阻断 + 通知 | 稳定后 |
| 强制执行 | `Sigkill` + 无告警（或仅 SIEM） | 静默阻断，减少噪音 | 成熟环境 |

### 3.3 与 MITRE ATT&CK 的对齐

MITRE ATT&CK 容器矩阵的 [T1611: Escape to Host](https://attack.mitre.org/techniques/T1611/) 提供了检测策略的框架参考。以下是本文规则与 ATT&CK 数据源的映射：

| ATT&CK 数据源 | 本文覆盖方式 | 检测层级 |
|-------------|-----------|---------|
| DS0017: Command | Falco 规则捕获 `execve` 参数和进程树 | 系统调用 |
| DS0022: File | Falco 规则捕获敏感文件 `openat`/`write` | 系统调用 |
| DS0029: Network Traffic | Falco 规则捕获异常 `connect` 和反弹 shell | 系统调用 |
| DS0038: Group | Falco 规则检测 `setuid`/`setgid` 异常 | 系统调用 |
| DS0041: Container | Falco/Tetragon 容器元数据关联 | 容器运行时 |

这种对齐不仅有助于 SOC 团队理解告警的技术上下文，也为合规审计提供了可追溯的框架依据。

## 四、工程化部署边界：什么 eBPF 能做什么不能做

### 4.1 能做的事

- **实时阻断容器逃逸行为**：Tetragon 在内核同步执行 `Sigkill`，阻断响应延迟在微秒级
- **低开销的持续监控**：eBPF 程序 JIT 编译后执行在内核态，安全相关 CPU 消耗较用户空间 Agent 下降 60%-80%
- **不可绕过的监控层**：容器内 root 权限无法直接禁用 eBPF 探针，必须先完成逃逸
- **细粒度的容器上下文关联**：eBPF 程序可读取 cgroup、namespace、容器 ID 等元数据，实现"哪个容器里的哪个进程做了什么"的精确归因

### 4.2 不能做的事

- **无法覆盖 API 层攻击**：ServiceAccount Token 滥用、Kubernetes API Server 未授权访问需依赖 Audit Log 和准入控制
- **无法替代镜像安全**：供应链污染（恶意镜像、OCI Hook 劫持）需在 CI/CD 阶段通过镜像扫描和签名拦截
- **无法防御内核漏洞直接利用**：如果攻击者持有内核零日并在 eBPF 探针挂载前完成提权，探针本身也可能被绕过或禁用
- **无法解决配置治理问题**：`privileged: true` 和 `hostPath` 的滥用根源是配置管理，eBPF 只能检测和阻断，不能防止配置被写入

### 4.3 部署拓扑建议

生产环境中，eBPF 安全能力应与现有安全栈形成互补而非替代关系：

```mermaid
graph LR
    subgraph CI["CI/CD 阶段"]
        D1["Trivy/Grype 镜像扫描"]
        D2["Cosign 镜像签名"]
        D3["OPA/Gatekeeper 准入控制"]
    end
    subgraph Runtime["运行时阶段"]
        R1["Falco eBPF 检测+告警"]
        R2["Tetragon 实时阻断"]
        R3["K8s Audit Log"]
    end
    subgraph Response["响应阶段"]
        S1["SIEM/Splunk/Elastic"]
        S2["PagerDuty/Slack 告警"]
        S3["自动化隔离 Pod"]
    end
    CI --> Runtime --> Response
```

- **CI/CD 阶段**：镜像扫描 + 签名 + 准入控制，拦截供应链污染和配置缺陷
- **运行时阶段**：Falco 负责广覆盖检测，Tetragon 负责高置信度实时阻断，K8s Audit Log 覆盖 API 层
- **响应阶段**：告警聚合到 SIEM，高优先级事件触发值班通知和自动化响应（隔离 Pod、阻断网络）

## 五、结论

容器逃逸已从"理论可能"演变为"实战常态"。2024 至 2026 年的漏洞时间线表明，攻击面已从内核零日扩展到配置缺陷、运行时竞态和供应链污染的组合拳。任何单一安全控制都无法覆盖全部路径。

eBPF 检测工程的价值在于**将监控下沉到攻击者无法直接触及的内核层**，在容器进程完成逃逸动作之前捕获异常行为。Falco 提供广覆盖的规则检测和告警能力，Tetragon 提供微秒级的实时阻断能力，两者结合可覆盖五类逃逸路径中的三类（配置缺陷、运行时竞态、内核漏洞利用），但无法替代 API 审计和镜像安全。

工程化落地的关键在于**分阶段上线、持续调优误报、与现有安全栈互补**。将 eBPF 安全能力视为基础设施而非外挂 Agent，是容器安全从"事后响应"走向"实时防御"的必经之路。