// 2. 通过 Unix Domain Socket 将 token 传递给低特权进程
struct msghdr msg = {0};
struct cmsghdr *cmsg;
char buf[CMSG_SPACE(sizeof(int))];
// ... 标准 SCM_RIGHTS 发送逻辑 ...
CMSG_FIRSTHDR(&msg);
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type = SCM_RIGHTS;
cmsg->cmsg_len = CMSG_LEN(sizeof(int));
memcpy(CMSG_DATA(cmsg), &token_fd, sizeof(int));
sendmsg(socket_fd, &msg, 0);

// 3. 在低特权进程中，使用 token 委托执行 BPF 操作
union bpf_attr prog_attr = {
    .prog_load = {
        .prog_type = BPF_PROG_TYPE_KPROBE,
        .expected_attach_type = BPF_TRACE_KPROBE,
        .prog_token_fd = received_token_fd,  // 关键：附加 token
        // ... 其他字段 ...
    }
};
int prog_fd = syscall(__NR_bpf, BPF_PROG_LOAD, &prog_attr, sizeof(prog_attr));

3.3 libbpf 集成路径

libbpf 从 1.4+ 版本开始支持 BPF Token 透传：

// libbpf 方式加载带 token 的程序
struct bpf_object *obj = bpf_object__open_file("monitor.bpf.o", NULL);

// 设置 token（bpf_object 级别的委托）
struct bpf_token *token = bpf_token__create(token_fd);
bpf_prog__set_token(prog, token);

// 或者设置全局默认 token
bpf_object__set_token(obj, token_fd, "/proc/self/ns/user");

// 之后所有加载/attach 操作都使用 token 委托权限
bpf_object__load(obj);

四、生产级容器安全架构设计

4.1 场景：零 CAP BPF 的容器监控

典型的场景是：你有一个业务容器，它运行着 Java/Node.js 应用，但你需要在宿主机上部署 observability agent（如 eBPF-based tracing）来监控这个容器。传统方案需要把监控 agent 部署到容器内并授予 CAP_BPF，或者让宿主机上的 daemon 直接监控——两种方案都有安全边界问题。

BPF Token 方案:

# Kubernetes Pod 配置示例
apiVersion: v1
kind: Pod
metadata:
  annotations:
    # 自定义 CRI 扩展：请求 BPF token
    security.alpha.kubernetes.io/bpf-token: "kprobe-trace-only"
spec:
  containers:
  - name: app
    image: my-app:v1
    securityContext:
      capabilities:
        drop: [ALL]
        # 完全不授予 CAP_BPF / CAP_SYS_ADMIN
  initContainers:
  - name: bpf-token-delegator
    image: bpf-delegator:v1
    securityContext:
      capabilities:
        add: [CAP_BPF, CAP_SYS_ADMIN]  # 仅 init 容器有特权
    volumeMounts:
    - name: bpf-token-sock
      mountPath: /var/run/bpf-token
  volumes:
  - name: bpf-token-sock
    emptyDir: {}

// BPF Token 委托守护进程（init 容器内运行）
int main(int argc, char **argv) {
    // 1. 打开容器运行时的 user namespace fd
    int userns_fd = open("/proc/1/ns/user", O_RDONLY);

    // 2. 创建受限的 BPF token
    union bpf_attr attr = {.token_create = {
.usernsfd = userns_fd,
        .allowed_cmds = BPF_TRACING_CMD_MASK,
        .allowed_progs = BPF_TRACING_PROG_MASK,
        .allowed_maps = BPF_TRACING_MAP_MASK,
    }};
    int token_fd = bpf(BPF_TOKEN_CREATE, &attr, sizeof(attr));

    // 3. 等待业务容器的监控进程连接
    int sock = create_unix_socket("/var/run/bpf-token/token.sock");

    while (1) {
        int client = accept(sock, NULL, NULL);
        // 4. 通过 SCM_RIGHTS 发送 token
        send_token_fd(client, token_fd);
        close(client);
    }
}

4.2 与 Landlock 的组合：深度纵深防御

BPF Token 解决的是"谁能做什么"的问题，而 Landlock 解决的是"能访问什么文件系统资源"的问题。二者组合构成强大的纵深防御体系：

// 第一层：Landlock 沙箱
struct landlock_ruleset_attr ruleset_attr = {
    .handled_access_fs = LANDLOCK_ACCESS_FS_READ_FILE |
                         LANDLOCK_ACCESS_FS_WRITE_FILE |
                         LANDLOCK_ACCESS_FS_READ_DIR |
LANDLANDLOCK_ACCESS_FS_MAKE_REG |
LANDLOCK_ACCESS_FS_REFER,
};
int ruleset_fd = landlock_create_ruleset(&ruleset_attr, sizeof(ruleset_attr), 0);

// 规则：只允许读写特定目录
struct landlock_path_beneath_attr path_attr = {
    .allowed_access = LANDLOCK_ACCESS_FS_READ_FILE | LANDLOCK_ACCESS_FS_WRITE_FILE,
    .parent_fd = open("/app/data", O_PATH),
};
landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH, &path_attr, 0);

// 第二层：应用沙箱限制
landlock_restrict_self(ruleset_fd, 0);

// 第三层：创建受限 BP Token 给监控进程
// 监控进程获得 BPF Token，被允许加载追踪程序
// 但无法通过 BPF 程序直接访问文件系统

4.3 与 Linux v6.10+ Namespace Token 扩展

Linux 6.10 进一步引入了将 BPF token 与 mount namespace 和 PID namespace 的绑定机制。这意味着：

• BPF token 现在可以限制在特定的 mount namespace 内有效
• BPF 程序通过 bpf_get_current_pid_tgid() 看到的进程只限于 token 绑定的 PID namespace 内
• 容器逃逸后，即便获得了 BPF token，也无法跨 namespace 使用

// 绑定到特定 mount namespace
union bpf_attr tok_attr = {
    .token_create = {
        .userns_fd = target_userns_fd,
        .mntns_fd = target_mntns_fd,    // Linux 6.10+
        .netns_fd = target_netns_fd,     // Linux 6.10+
        // token 在这些命名空间外完全无效
    },
};

五、内核实现关键路径分析

5.1 Token 验证流程

当用户附加 token_fd 时，内核执行以下验证链：

// kernel/bpf/syscall.c 简化逻辑
static int bpf_token_check(union bpf_attr *attr, enum bpf_cmd cmd)
{
    struct bpf_token *token = bpf_token_get_from_fd(attr->token_fd);

    // 1. 用户命名空间检查：调用者的 user ns 必须与 token 绑定的一致
    if (token->userns != current_user_ns())
        return -EINVAL;

    // 2. 命令白名单检查
    if (!test_bit(cmd, token->enabled_cmds))
        return -EPERM;

    // 3. 命令特定的子限制
    switch (cmd) {
    case BPF_PROG_LOAD:
        // 检查程序类型是否在允许范围内
        if (!test_bit(attr->prog_load.prog_type, token->enabled_progs))
            return -EPERM;
        // 检查 attach type
        if (!test_bit(attr->prog_load.expected_attach_type, token->enabled_attach))
return -EPERM;
        break;
    case BPF_MAP_CREATE:
        // 检查 map 类型
        if (!test_bit(attr->map_create.map_type, token->enabled_maps));
            return -EPERM;
        break;    }

    return 0; // 检查通过，使用此 token 对应的权限集
}

5.2 权限穿透模型

与传统的 capability 检查不同，BPF token 采用了"委托替换"模型而非"权限叠加"模型：

传统模型：
  进程 (cap_eff) ∈ [检查 bpf() 权限需要 CAP_BPF]

Token 模型：
  进程 (cap_eff = ∅，但有 token_fd)
  → bpf() 调用时使用 token 中记录的权限集
  → 调用者的 caps 完全不参与

这意味着：持有 token 的进程即便被攻击代码执行了 execve，只要新的进程镜像不继承 token fd（不受 O_CLOEXEC 保护），攻击就能继续使用时，然而 token 本身的权限粒度已大幅收窄。

5.3 性能开销

BPF token 的引入对 bpf() 系统调用的性能影响微乎其微：

损失主要来自额外的 fget() 和位图检查，相比 verifier 的复杂性（可达数十毫秒量级），这些开销在生产环境完全可以忽略。

六、生产级三大工程陷阱

陷阱一：Token fd 的生命周期泄露

现象: 特权守护进程创建了 token，通过 Unix socket 发送给容器内进程，但 token fd 本身因为没有设置 O_CLOEXEC，在容器内执行 execve 时意外泄露给子进程。

漏洞场景:

// 守护进程：创建 token 后 fork-exec 业务应用
int token_fd = bpf(BPF_TOKEN_CREATE, ...); // 没有设置 O_CLOEXEC！
pid_t child = fork();
if (child == 0) {
    // 子进程继承了 token_fd
    execve("/app/server", argv, envp); // token_fd 泄漏给 server 进程！
}

解决方案:

// 创建时设置 O_CLOEXEC（通过 syscall 或 fcntl）
fcntl(token_fd, F_SETFD, FD_CLOEXEC);

// 或者在创建时即支持 flags（未来内核可能添加 BPF_F_TOKEN_CLOEXEC）

陷阱二：Token 权限不随命名空间销毁而回收

现象: 当容器退出时，其 user namespace 被销毁，但已经通过 SCM_RIGHTS 发送给宿主机或其他容器的 token fd 依然有效——因为内核并未在命名空间销毁时自动使 token 失效。

攻击路径: 容器 A 获得 BPF token → 通过 socket 传给容器 B → 容器 A 退出，user namespace 销毁 → 但容器 B 手中的 token 仍可用（在某些情况下）。

缓解策略:

// 使用 pidfd_getfd + pidfd 监控容器生命周期
int container_pidfd = pidfd_open(container_pid, 0);
// 容器退出时 pidfd 会变为可读状态，在此回收所有 token

// 或在 BPF token 创建时绑定到 pid namespace
// Linux 6.10+ 支持 .pidns_fd 字段

陷阱三：Ringbuf 输出被视为信息泄露通道

现象: 当 token 允许创建 BPF_MAP_TYPE_RINGBUF 时，特权进程有时需要通过 ringbuf 获取 BPF 程序的输出数据。但如果 token 允许了 ringbuf map，容器内的进程也可以通过 ringbuf 向内核写入大量数据，或者读取不属于它的 BPF 程序输出。

解决方案: 在生产部署中，推荐将 BPF Token 与 Ringbuf 权限分离：

// 监控代理自身的 BPF 程序有独立的 ringbuf（不暴露在 token 中）
// 给被监控进程的 token 只允许 MAP_CREATE | MAP_LOOKUP_ELEM | MAP_UPDATE_ELEM
// 不允许 RINGBUF 类型
.allowed_maps = 1ULL << BPF>

┌─────────────────────────────────────────────────────────┐
│                  Host (特权域)                             │
│  ┌─────────────────────────────────────────────────┐    │
│  │  BPF Token Orchestrator (systemd service)        │    │
│  ├─────────────────────────────────────────────────┤    │
│  │  策略引擎: 哪些容器需要 BPF? 需要何种权限?         │    │
│  │  Token 工厂: 按策略生成 token_fd                   │    │
│  │  生命周期管理: 监听容器退出事件, 回收 token         │    │
│  └──────────────┬──────────────────────────────────┘    │
│                  │ Unix Socket per container               │
├──────────────────┼──────────────────────────────────────-─┤
│  Container A     │   Container B                          │
│  ┌───────────────▼──┐  ┌────────────────────────┐        │
│  │ 监控 Agent        │  │ 监控 Agent              │        │
│  │ ○ token_fd(A)    │  │ ○ token_fd(B)          │        │
│  │ ○ 加载 kprobe     │  │ ○ 加载 tracepoint      │        │
│  │ ○ 读/写 map      │  │ ○ 读/写 map           │        │
│  │ ✗ JIT 编译        │  │ ✗ 创建 ringbuf          │        │
│  │ ✗ 加载 struct_ops │  │ ✗ 加载 kprobe          │        │
│  └──────────────────┘  └────────────────────────┘        │
└─────────────────────────────────────────────────────────┘

// token-factory.c: 根据容器元数据生成对应 token
struct bpf_token_config *get_token_config(struct container_meta *meta) {
    if (strcmp(meta->type, "observability") == 0) {
        return &(struct bpf_token_config){
.allowed_cmds = BPF_OBS_AGENT_CMDS,
            .allowed_progs = BPF_OBS_AGENT_PROGS,
            .allowed_maps = BPF_OBS_AGENT_MAPS,
            .allowed_attach = BPF_OBS_AGENT_ATTACH,
        };
    } else if (strcmp(meta->type, "network-monitor") == 0) {
        return &(struct bpf_token_config){
            .allowed_cmds = BPF_NETMON_CMDS,
            .allowed_progs = BPF_NETMON_PROGS,X_MAPS,
        };
    }
    // 默认：无 BPF 权限
    return NULL;
}

# 检查内核版本支持
uname -r  # >= 6.9 支持基础 BPF Token, >= 6.10 支持 ns 绑定

# 加载 BPF Token Orchestrator systemd service
sudo systemctl enable --now bpf-token-orchestrator

# 容器启动前，Orchestrator 已经：
# 1. 创建 socket: /run/bpf-token//token.sock
# 2. 配置对应权限策略
# 3. 令牌已被创建，等待容器连接获取

# 容器启动后，init进程连接 socket 获取 token_fd
# 5. 监控 agent 使用 token_fd 加载 BPF 程序（不再需要 CAP_BPF）

测试场景: 10 个容器同时运行 eBPF 监控 agent
         agent 每 100ms 通过 bpf_map_lookup_elem 读取内核采集的指标