Linux内核 close_range 与文件描述符生命周期安全工程实战

引言：被忽视的 fd 安全鸿沟

在 Linux 系统编程中，文件描述符（File Descriptor）是最基础也是最脆弱的资源之一。一个长期被低估的安全问题：子进程在 execve() 执行前，父进程中打开的 fd 会被原样继承。这意味着，如果你的程序在配置解析阶段读取了 TLS 私钥、数据库密码文件或敏感配置文件后，忘记关闭这些 fd 就启动了子进程，敏感信息的内核 fd 引用便赤裸裸地暴露给了不可信代码。

这不是理论风险。2016 年 Docker 早期的 runC 容器逃逸漏洞（CVE-2016-9962）、2022 runC 的 fd 泄露漏洞（CVE-2022-0185），其核心都指向 fd 生命周期管理的失败：父进程以 root 权限打开的配置 fd 和 namespace fd 没有妥善关闭就被子进程继承，最终导致提权。

Linux 内核 5.9 引入的 close_range() 系统调用和 clone3() 的 CLONE_CLEAR_SIGHAND / CLONE_INTO_CGROUP 标志，为解决 fd 生命周期安全提供了系统级原子化方案。本文将从实际漏洞案例出发，深入分析 fd 继承机制及其风险源，解析 close_range 的内核实现，并结合现代容器运行时（runC、crun）的最佳实践，构建生产级 fd 安全框架。

一、fd 继承机制的深层原理

1.1 fork 与 exec 之间的危险窗口

Linux 的传统进程创建模型为 fork() + exec()。当我们使用 glibc 的 posix_spawn() 或直接 fork() 时：

fork() → 子进程继承父进程所有 fd 的副本 → close / dup2 等清理操作 → execve() → 新程序执行

这个"清理窗口"是问题的根源。早期的做法是：

1. 遍历 /proc/self/fd/，逐个 close
2. 或使用 fcntl(fd, F_SETFD, FD_CLOEXEC) 标记每个 fd

这两种方案都有严重缺陷：

// 方案1：/proc/self/fd 遍历 —— 存在 TOCTOU 竞态
// 攻击者可以在遍历过程中打开新 fd，绕过关闭
void close_all_fds_via_proc(void) {
    DIR *dir = opendir("/proc/self/fd");
    struct dirent *entry;
    while ((entry = readdir(dir)) != NULL) {
        if (entry->d_name[0] == '.') continue;
        int fd = atoi(entry->d_name);
        if (fd <= STDERR_FILENO) continue;
        close(fd); // 竞态窗口
    }
    closedir(dir);
}

// 方案2：FD_CLOEXEC —— 需要预设标记
// 许多第三方库在打开文件时未设置 CLOEXEC，导致 fd 泄露
// 例如某些 Python 的 tempfile 模块、Go 的 net 包早期版本

1.2 多线程环境下的竞态爆炸

当父进程是多线程应用时，fd 遍历的安全问题更加严重。在 fork() 与 exec() 之间：

• 线程 A 正在遍历 /proc/self/fd/，准备 close fd > 3
• 线程 B 调用 open() 创建了一个新 fd，序号大于当前遍历位置
• 线程 B 打开的新 fd 被继承到子进程
• ATOCTOU（Time-of-Check-to-Time-of-Use）攻击：攻击者可以通过精心控制线程调度，让遍历进程恰好错过自己打开的恶意 fd

这正是 libseccomp 和 runC 早期 fd 处理逻辑中反复出现漏洞的根本原因。

1.3 传统方案的代价

在 close_range() 出现之前，安全地进行 fd 批量关闭要么依赖遍历，要么依赖 O_CLOEXEC 事后审计。这带来了：

• 性能开销：对于拥有数万 fd 的高并发服务，遍历操作可能消耗毫秒级 CPU
• 安全盲区：无法处理动态创建的 fd
• 不可移植：/proc 文件系统不一定挂载（容器环境常见）

二、close_range() 系统调用深度解析

2.1 接口定义

#define _GNU_SOURCE
#include <unistd.h>

int close_range(unsigned int first, unsigned int last, unsigned int flags);

参数说明：

• first：起始 fd 编号（含）
• last：结束 fd 编号（含），可使用 UINT_MAX 表示"直到最大 fd"
• flags：目前仅支持 CLOSE_RANGE_UNSHARE (bit 0) 和 CLOSE_RANGE_CLOEXEC (bit 1)

返回值： 成功返回 0，失败返回 -1 并设置 errno。

2.2 两种工作模式

模式一：批量 close（默认）

// 关闭 3 到最大 fd
if (close_range(3, UINT_MAX, 0) == -1) {
    perror("close_range failed");
    // 降级到传统方案
    close_all_fds_fallback();
}

这是 FD_CLOEXEC 的最终替代方案——在 execve() 之前彻底销毁 fd，从根本上消除信息泄露风险。

模式二：批量设置 CLOEXEC（CLOSE_RANGE_CLOEXEC）

// 批量标记所有 fd 为 close-on-exec
if (close_range(0, UINT_MAX, CLOSE_RANGE_CLOEXEC) == -1) {
    perror("close_range CLOEXEC failed");
}

这种方式不关闭 fd，但确保后续 exec() 时自动关闭。适合 exec 前不想破坏父进程 fd 的场景。

模式三：unshare + close（CLOSE_RANGE_UNSHARE）

// 先 unshare fd 表，再 close，避免影响其他线程
close_range(3, UINT_MAX, CLOSE_RANGE_UNSHARE);

这种模式解决了多线程竞态问题：内核先复制一份 private fd 表，再在副本上执行 close，不会影响正在使用 fd 的其他线程。

2.3 内核实现核心逻辑

close_range() 的内核实现位于 fs/file.c：

// 简化版内核逻辑 (Linux 5.9+)
// include/linux/file.h
struct files_struct {
    struct fdtable *fdt;
    // ...
};

// fs/file.c: sys_close_range()
SYSCALL_DEFINE3(close_range, unsigned int, fd,
                unsigned int, max_fd, unsigned int, flags)
{
    // 参数校验
    if (fd > max_fd)
        return -EINVAL;

    // UNSHARE 模式：先复制 fd 表，保证线程安全
    if (flags & CLOSE_RANGE_UNSHARE) {
        retval = unshare_fd(CLONE_FILES, GFP_KERNEL, &new_fdt);
        if (retval)
            goto out;
    }

    // 遍历 fd 表，关闭指定范围的 fd
    // 红黑树辅助定位 —— O(k log n) 复杂度
    // ... (filp_close, fd 表维护)

    return 0;
}

关键实现点：

• 原子性：在禁用抢占和保护锁下完成，不会因调度产生竞态
• RBTREE 辅助：使用红黑树快速定位下一个活跃 fd，避免遍历所有槽位
• fd 表隔离：UNSHARE 模式利用已有的 unshare_fd 机制，提升多线程场景的安全性

2.4 性能对比

以下是不同 fd 数量下，关闭 fd 到 UINT_MAX 的性能对比（Intel Xeon 8375C，Linux 6.1）：

close_range 的优势随 fd 数量增长而显著放大——它利用内核 fd 表的红黑树索引实现高效定位，时间复杂度 O(k log n)，远低于遍历的 O(n)。

三、glibc posix_spawn 与现代系统调用融合

3.1 传统 posix_spawn 的困境

glibc 的 posix_spawn() 传统上依赖 fork() + 手动 fd 操作：

// 旧版 glibc posix_spawn 的 fd 关闭实现
// fork → 遍历 action 列表 → dup2 保留需要的 fd → 关闭所有不需要的 fd → exec

这种方式在并发场景下存在根本缺陷：fork 后子进程必须串行处理 fd，期间其他线程可能在父进程打开新 fd。

3.2 glibc 2.34+ 的 posix_spawn 优化

glibc 2.34（2021 年 8 月发布）引入了基于 clone3() + close_range 的新实现：

// glibc 2.34+ posix_spawn 中的简化流程
// 结合 clone3 的 CLONE_CLEAR_SIGHAND 标志
// 与 close_range 的原子化 fd 管理

// 1. 设置需要保留的 fd 为 CLOEXEC=0
// 2. 批量设置所有 fd 为 CLOEXEC=1
// 3. 使用 close_range 关闭不需要的 fd
// 4. exec 时仅保留需要的 fd 通过 dup2 重生

// 关键改进：fork + close_range 替代了遍历

实际工程中，glibc 2.34+ 在 posix_spawn 失败时会回退到传统方案，但优先尝试系统级原子操作，显著提升了安全性。

四、clone3 与进程创建安全增强

4.1 clone3 的关键安全标志

Linux 5.3+ 引入的 clone3() 系统调用提供了比传统 clone() 更完善的参数传递机制，其中与 fd 安全直接相关的标志包括：

CLONE_CLEAR_SIGHAND 对 fd 安全的间接意义：它解决了 fork() 继承信号处理器后可能被意外触发（如 SIGIO 处理函数操作 fd）的问题。

4.2 完整的安全进程创建模式

实际工程中最安全的进程创建模式：

#define _GNU_SOURCE
#include <linux/sched.h>
#include <linux/types.h>
#include <sys/syscall.h>
#include <unistd.h>

pid_t safe_spawn_child(int keep_fds[], int keep_fds_count,
                        const char *path, char *const argv[]) {
    // Step 1: 保存需要保留的 fd 到高位（避免冲突）
    unsigned int temp_high_base = UINT_MAX / 2;
    for (int i = 0; i < keep_fds_count; i++) {
        int new_fd = dup2(keep_fds[i], temp_high_base + i);
        if (new_fd == -1) return -1;
        fcntl(new_fd, F_SETFD, 0); // 清除 CLOEXEC
    }

    // Step 2: 关闭低区间的所有 fd
    close_range(0, temp_high_base - 1, CLOSE_RANGE_UNSHARE);

    // Step 3: 将保留的 fd 归还到安全位置
    for (int i = 0; i < keep_fds_count; i++) {
        dup2(temp_high_base + i, keep_fds[i]);
        close(temp_high_base + i);
    }

    // Step 4: 再次关闭所有不需要的高区间 fd
    close_range(temp_high_base + keep_fds_count, UINT_MAX, 0);

    // Step 5: exec
    execvpe(path, argv, environ);
    return -1; // exec 失败
}

五、容器运行时的 fd 安全实践

5.1 runC 的 fd 管理策略

runC（容器运行时标准参考实现）在 runc init 阶段（进入容器命名空间后）执行的关键步骤：

// runc/libcontainer/init_linux.go (简化版)
func finalizeNamespace(config *initConfig) error {
    // Step 1: 调用 close_range 关闭所有不需要的 fd
    if err := unix.CloseRange(3, math.MaxUint32, unix.CLOSE_RANGE_UNSHARE); err != nil {
        // 降级：/proc/self/fd 遍历
        return fallbackCloseFds()
    }

    // Step 2: 仅保留 init 进程需要的 fd（如 log fd、socket fd）
    // ...

    // Step 3: 重置信号处理
    unix.Prctl(unix.PR_SET_PDEATHSIG, uintptr(config.ParentDeathSignal), 0, 0, 0)
    return nil
}

runC 在 1.1.0 版本（2022 年 12 月）引入了 close_range 优先策略，完全移除了旧版依赖 /proc/self/fd 遍历的代码路径。

5.2 crun 的零 fd 泄露方案

crun（Red Hat 开发的轻量级容器运行时，C 语言编写）采用了更加激进的策略：

// crun 源码：src/libcrun/container.c
// 1. 在父进程中就记录所有有效的 fd
GPtrArray *saved_fds = g_ptr_array_new();
for (int fd = 3; fd <= max_open_fd; fd++) {
    if (is_fd_in_use(fd)) {
        g_ptr_array_add(saved_fds, GINT_TO_POINTER(fd));
    }
}

// 2. close_range CLOEXEC 标记所有 fd
close_range(0, UINT_MAX, CLOSE_RANGE_CLOEXEC);

// 3. 在子进程内，仅重新打开需要的 fd
//    （通过 Unix socket SCM_RIGHTS 传递）

crun 的策略确保即使在多线程环境下也不会有 fd 意外泄露。

5.3 Kubernetes Pod 级 fd 安全

在 Kubernetes 场景下，每个 Pod 包含多个容器时，fd 安全还需考虑：

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
    appArmorProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]

关键配置：seccomp profile 必须允许 close_range 系统调用。Docker 和 containerd 的 RuntimeDefault profile 默认已允许，但自定义 profile 可能遗漏。

六、FD 生命周期审计与监控

6.1 基于 eBPF 的 fd 生命周期追踪

在生产环境中，除了正确使用 close_range，还需要运行时审计。eBPF 可以追踪 fd 的继承链条：

// BPF 程序：追踪 close_range 调用与 fd 创建
// 使用 tracepoint/syscalls/sys_enter_close_range

SEC("tracepoint/syscalls/sys_enter_close_range")
int trace_close_range(struct trace_event_raw_sys_enter *ctx) {
    unsigned int first = (unsigned int)ctx->args[0];
    unsigned int last = (unsigned int)ctx->args[1];
    unsigned int flags = (unsigned int)ctx->args[2];

    struct event e = {};
    e.pid = bpf_get_current_pid_tgid() >> 32;
    e.first = first;
    e.last = last;
    e.flags = flags;

    // 获取进程的 fd 表统计信息
    e.total_fds = count_open_fds(ctx);

    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &e, sizeof(e));
    return 0;
}

配合用户空间工具，可以：

• 检测异常 fd 数量激增（可能是 fd 泄露）
• 发现 close_range 参数错误（如 first > last）
• 审计遗留的 /proc/self/fd 遍历代码

6.2 Audit 子系统关联

Linux Audit 可以记录哪些 fd 在 close_range 时持有：

# 审计规则：监控 close_range 调用
auditctl -a exit,always -F arch=b64 -S close_range -k fd_security
auditctl -a exit,always -F arch=b32 -S close_range -k fd_security

# 查看审计日志
ausearch -k fd_security -i

# 输出示例：
# type=SYSCALL msg=audit(1728220800.123:456): arch=c000003e syscall=436
#   success=yes exit=0 a0=3 a1=ffffffff a2=0 items=0 ppid=1234 pid=5678
#   auid=root uid=root gid=root comm="runc-init"

6.3 ptrace 主动防御

对于安全级别极高的场景（如加密密钥管理进程），可以使用 ptrace 监控 fd 操作：

// 父进程使用 ptrace 监控子进程
pid_t child = fork();
if (child == 0) {
    ptrace(PTRACE_TRACEME, 0, NULL, NULL);
    execvp(argv[0], argv); // 执行后会触发 SIGTRAP
}

// 父进程拦截 execve 后的所有 open/accept 调用
int status;
waitpid(child, &status, 0);
while (WIFSTOPPED(status)) {
    struct user_regs_struct regs;
    ptrace(PTRACE_GETREGS, child, NULL, &regs);

    if (regs.orig_rax == SYS_open || regs.orig_rax == SYS_accept) {
        // 检查打开的 fd 是否为授权资源
        long path_ptr = regs.rdi;
        char path[PATH_MAX];
        read_memory(child, path_ptr, path, PATH_MAX);

        if (!is_fd_allowed(path, child)) {
            // 替换 fd 为 -EPERM（阻断攻击）
            regs.rax = -EPERM;
            ptrace(PTRACE_SETREGS, child, NULL, &regs);
        }
    }

    ptrace(PTRACE_SYSCALL, child, NULL, NULL);
    waitpid(child, &status, 0);
}

七、生产环境实战：构建零 fd 泄露的服务框架

7.1 HTTP 服务的 fd 安全管理模型

一个典型的高并发 HTTP 服务在进程启动过程中，fd 的生命周期如下：

启动阶段：
  [0,1,2] stdin/stdout/stderr
  [3]     配置文件 fd（TLS 私钥、数据库密码）
  [4]     监听 socket fd
  [5]     日志文件 fd
  [6]     Sentinel / 恢复 fd
  [7+]    运行时动态 fd

↓ close_range(3, UINT_MAX, 0) 前的不安全区域

清理后：
  [0,1,2] 保留
  [3-7]   仅保留必要 fd
  [8+]    运行时正常创建/销毁

实践原则：服务启动代码应尽早 close_range；任何延迟都会增加攻击窗口。

7.2 自定义 fd 分配器

对于 fd 管理要求极高的场景（如金融交易网关），可以实现 fd 白名单机制：

#define MAX_FD_POOL 4096

typedef struct {
    int base_fd;
    int max_fd;
    uint8_t fd_bitmap[MAX_FD_POOL / 8];
} fd_pool_t;

// 一切 fd 操作必须经过 pool
int fd_pool_open(fd_pool_t *pool, const char *path, int flags) {
    int fd = open(path, flags | O_CLOEXEC);
    if (fd == -1) return -1;

    if (fd >= pool->base_fd && fd < pool->max_fd) {
        int idx = fd - pool->base_fd;
        pool->fd_bitmap[idx / 8] |= (1 << (idx % 8));
    }
    return fd;
}

void fd_pool_close(fd_pool_t *pool, unsigned int fd) {
    if (fd >= pool->base_fd && fd < pool->max_fd) {
        int idx = fd - pool->base_fd;
        if (pool->fd_bitmap[idx / 8] & (1 << (idx % 8))) {
            close(fd);
            pool->fd_bitmap[idx / 8] &= ~(1 << (idx % 8));
        }
    }
}

7.3 自动化测试用例

// 测试 close_range 的 fd 隔离效果
void test_fd_isolation_after_close_range(void) {
    int test_fd = open("/dev/zero", O_RDONLY);
    assert(test_fd > 2);

    // 保存 fd 编号
    int saved_fd = test_fd;

    // 调用 close_range
    int rc = close_range(3, UINT_MAX, 0);
    assert(rc == 0);

    // 验证 fd 已关闭
    errno = 0;
    char buf[1];
    ssize_t n = read(saved_fd, buf, 1);
    assert(n == -1);
    assert(errno == EBADF);

    // 验证标准 fd 未受影响
    struct stat st;
    assert(fstat(STDIN_FILENO, &st) == 0);
    assert(fstat(STDOUT_FILENO, &st) == 0);
    assert(fstat(STDERR_FILENO, &st) == 0);

    printf("✅ fd isolation test passed\n");
}

// 测试 CLOSE_RANGE_UNSHARE 不影响其他线程
void *thread_keep_fd(void *arg) {
    int fd = open("/dev/null", O_WRONLY);
    sleep(2);
    // fd 应该仍然有效
    write(fd, "test", 4);
    close(fd);
    return NULL;
}

void test_close_range_unshare_multithread(void) {
    pthread_t t;
    pthread_create(&t, NULL, thread_keep_fd, NULL);

    usleep(100000); // 等待子线程打开 fd

    // UNSHARE 模式不应影响其他线程
    close_range(3, UINT_MAX, CLOSE_RANGE_UNSHARE);

    pthread_join(t, NULL);
    printf("✅ multithread unshare test passed\n");
}

八、总结与展望

close_range() 的引入标志着 Linux 内核在 fd 安全管理上的一次范式转移——从"事后审计 + 人工关闭"进化为"内核原子化批量操作"。其核心价值在于：

1. 原子性消除竞态：不被其他线程的 fd 操作干扰
2. 性能突破：红黑树索引使大规模 fd 操作降至接近常数时间
3. 安全降级链：内核提供的统一接口，用户态无需遍历 /proc

结合 clone3() 的 CLONE_CLEAR_SIGHAND 标志和现代容器运行时设计，我们可以构建出真正的零 fd 泄露服务。在未来的 Linux 内核中，预期会看到更多针对 fd 生命周期管理的原子化系统调用。

实践建议：

• Linux ≥ 5.9 的项目应直接使用 close_range() 替代 /proc/self/fd 遍历
• 多线程服务优先使用 CLOSE_RANGE_UNSHARE 标志
• 安全敏感服务应在启动审计日志中记录 close_range 调用参数
• 容器运行时需确保 seccomp profile 允许 close_range (syscall 436 on x86_64)

参考资源：

- kernel.org: close_range(2) man page

- LKML: c3g0a3c1 — "fs: add close_range() system call" (Linux 5.9)

- runC source: libcontainer/init_linux.go

- glibc 2.34 release notes: posix_spawn reimplementation

作者注：本文所有代码示例均基于 Linux 6.1+ 内核 API，compile with gcc -D_GNU_SOURCE。适用于内核 5.9+ 环境，低于此版本请参考 fallback 方案。

Linux 内核 futex 机制与同步原语实战：从系统调用到高性能锁的工程真相

Linux内核进程调度器深度实战：CFS完全公平调度器、SCHED_DEADLINE实时调度与NUMA负载均衡

Linux内核内存管理深度实战：SLAB/SLUB分配器原理、调优与故障排查

io_uring 深度实战：从架构原理到生产级高性能异步 I/O

立即
投稿

微信公众账号

微信扫一扫加关注

发表
评论 返回
顶部