Hotdry.
归档
systems

psc：基于eBPF迭代器的容器感知进程监控工具

分析psc如何通过eBPF迭代器实现内核级进程监控，绕过/proc文件系统限制，提供完整的容器上下文感知与灵活的CEL查询能力。

在容器化部署成为主流的今天，传统的进程监控工具如ps、lsof、ss等面临着严峻挑战。这些工具不仅无法感知容器上下文，还依赖于易受攻击的/proc文件系统，使得在复杂的容器环境中进行精准监控变得异常困难。psc（ps container）应运而生，它通过 eBPF 迭代器直接读取内核数据结构，结合 Google CEL 查询语言，为容器环境提供了新一代的进程监控解决方案。

传统监控工具的三大局限

1. /proc 文件系统的安全漏洞

传统 Linux 监控工具的核心问题在于它们都依赖于/proc虚拟文件系统。当用户需要查看进程信息时，这些工具会读取/proc/[pid]目录下的各种文件。然而，/proc文件系统存在一个致命的安全缺陷：它可以通过用户态 rootkit 进行篡改。

攻击者可以通过LD_PRELOAD注入恶意共享库，拦截readdir()、open()等系统调用，从而隐藏特定的进程、网络连接或文件。这意味着传统工具看到的只是攻击者允许看到的内容，而非真实的系统状态。正如 psc 文档中指出的："A compromised library loaded via LD_PRELOAD can intercept system calls and hide processes, network connections, or files from these traditional utilities."

2. 容器上下文缺失

在容器化环境中，每个容器都有自己的命名空间隔离。传统的ps命令只能看到主机视角的进程列表，无法回答以下关键问题：

  • 某个进程属于哪个容器？
  • 容器内进程的完整层次结构是怎样的？
  • 容器间的网络连接关系如何？

虽然可以通过复杂的 shell 管道组合来获取部分信息（如ps aux | xargs -I{} sh -c 'cat /proc/{}/cgroup 2>/dev/null | grep -q docker && echo {}'），但这种做法既低效又容易出错。

3. 查询灵活性不足

传统工具的输出格式固定，需要大量的文本处理才能提取有用信息。例如，要查找所有监听 443 端口的进程，需要执行：

ss -tnp | grep ESTAB | grep :443 | awk '{print $6}' | cut -d'"' -f2

这种基于文本的管道处理不仅性能低下，而且在处理大量进程时会产生显著的 CPU 开销。

psc 的架构设计：eBPF 迭代器 + CEL 查询语言

eBPF 迭代器的内核级访问

psc 的核心创新在于使用 eBPF 迭代器直接读取内核数据结构。eBPF 迭代器是 Linux 内核 5.8 引入的功能，它允许 BPF 程序遍历内核数据结构（如任务列表、文件描述符表等），并在内核空间进行过滤和处理。

与传统的/proc访问相比，eBPF 迭代器具有以下优势：

  1. 绕过用户态干扰：eBPF 程序在内核空间执行，不受LD_PRELOAD等用户态攻击的影响。即使攻击者篡改了系统调用，eBPF 程序仍然可以直接访问内核数据结构。

  2. 性能优化：传统方法需要为每个进程单独打开/proc文件，而 eBPF 迭代器可以在单次遍历中处理所有进程。根据 eBPF 教程的数据，这种差异在监控数百个进程时可以达到数量级的性能提升。

  3. 精确数据访问：eBPF 程序可以直接访问内核结构体字段，无需解析文本格式的/proc文件内容。

psc 使用的 eBPF 程序主要挂载在SEC("iter/task")和SEC("iter/task_file")等迭代器类型上。当用户执行 psc 命令时，内核会遍历任务列表，对每个进程调用相应的 eBPF 程序，程序内部进行过滤和数据处理，最终将结果返回给用户空间。

Google CEL 查询语言的集成

为了提供灵活的查询能力，psc 集成了 Google 的 Common Expression Language（CEL）。CEL 是一种类型安全的表达式语言，专门设计用于评估布尔条件。通过 CEL，用户可以编写简洁而强大的查询表达式：

# 查找所有nginx进程
psc 'process.name == "nginx"'

# 查找容器化进程
psc 'container.id != ""'

# 查找监听特权端口的进程
psc 'socket.state == listen && socket.srcPort < uint(1024)'

# 查找有外部443连接的进程
psc 'socket.state == established && socket.dstPort == uint(443)'

CEL 支持丰富的操作符和函数，包括字符串操作（.contains()、.startsWith()、.endsWith()）、数值比较、逻辑运算等。这种声明式的查询方式比传统的 shell 管道更加直观和安全。

容器感知的实现机制

命名空间与 cgroup 识别

psc 的容器感知能力建立在 Linux 内核的命名空间和 cgroup 机制之上。每个容器都有自己独立的命名空间（网络、PID、挂载、UTS、IPC、cgroup），这些信息在内核中都有对应的 inode 编号。

psc 通过以下方式识别容器上下文：

  1. 命名空间 inode 比对：通过比较进程的命名空间 inode 与初始命名空间 inode，可以判断进程是否在容器内运行。例如，process.namespaces.net != uint(4026531840)可以筛选出不在默认网络命名空间中的进程。

  2. cgroup 路径解析：从容器的 cgroup 路径中提取容器运行时信息。psc 支持识别 Docker、containerd、CRI-O、Podman 等多种运行时。

  3. 容器元数据收集：通过读取/run/containerd、/run/docker等目录下的容器元数据文件，获取容器名称、镜像、标签等详细信息。

运行时特定的适配逻辑

不同的容器运行时在实现细节上有所差异，psc 针对每种运行时都实现了相应的适配逻辑：

  • Docker：通过/run/docker/containerd/daemon/io.containerd.runtime.v2.task/moby/路径下的容器元数据
  • containerd：通过/run/containerd/io.containerd.runtime.v2.task/路径
  • CRI-O：通过/run/containers/storage/overlay-containers/路径
  • Podman：通过/run/user/[uid]/containers/storage/overlay-containers/路径

这种多运行时支持使得 psc 能够在混合容器环境中无缝工作。

工程实践：安装与使用指南

系统要求与安装

psc 对系统环境有一定要求：

  • Linux 内核 5.8 或更高版本（eBPF 迭代器功能需要）
  • Go 1.25 或更高版本
  • Clang 和 LLVM 工具链
  • libbpf 开发头文件
  • bpftool（用于生成 vmlinux.h）

在 Debian/Ubuntu 系统上的安装步骤：

# 安装依赖
sudo apt-get install clang llvm libbpf-dev linux-headers-$(uname -r) linux-tools-$(uname -r)

# 克隆并构建psc
git clone https://github.com/loresuso/psc
cd psc

# 生成vmlinux.h（每个内核版本只需执行一次）
make vmlinux

# 构建二进制文件
make build

常用查询示例

psc 提供了丰富的查询能力，以下是一些实用的示例：

基础进程查询：

# 列出所有进程
psc

# 以树形结构显示进程
psc --tree

# 查找特定用户进程
psc 'process.user == "root"'

容器相关查询：

# 显示所有容器化进程
psc 'container.id != ""'

# 查找Docker容器进程
psc 'container.runtime == docker'

# 查找特定容器内的进程
psc 'container.name == "nginx"'

# 显示容器进程树
psc 'container.runtime == docker' --tree

网络连接分析：

# 查找监听端口
psc 'socket.state == listen'

# 查找已建立的连接
psc 'socket.state == established'

# 查找连接到特定端口的进程
psc 'socket.dstPort == uint(443)'

# 查找使用Unix域套接字的进程
psc 'socket.family == unix'

文件系统监控：

# 查找打开/etc目录下文件的进程
psc 'file.path.startsWith("/etc")'

# 查找打开特定文件的进程
psc 'file.path == "/etc/passwd"'

自定义输出格式

psc 支持通过-o参数自定义输出列：

# 使用预设格式
psc 'socket.state == listen' -o sockets
psc 'container.id != ""' -o containers

# 自定义字段
psc -o process.pid,process.name,process.user,container.name
psc 'socket.state == listen' -o process.pid,process.name,socket.srcPort,socket.state

可用的预设格式包括：

  • sockets：进程信息 + 完整的套接字详情
  • files：进程信息 + 文件描述符详情
  • containers：进程信息 + 容器详情
  • network：紧凑的网络视图

性能与安全优势分析

性能对比

与传统监控工具相比，psc 在性能方面具有显著优势：

  1. 减少系统调用：传统方法需要为每个进程执行多次open()、read()、close()系统调用，而 psc 通过 eBPF 迭代器在单次遍历中处理所有进程，大幅减少了系统调用开销。

  2. 内核空间过滤：过滤逻辑在内核空间执行，只有匹配的结果才会传输到用户空间，减少了不必要的数据复制。

  3. 避免文本解析：直接访问内核结构体，无需解析/proc文件的文本格式。

根据 eBPF 迭代器的性能测试数据，在处理数百个进程时，eBPF 方法的性能可以比传统方法快 10 倍以上。

安全增强

psc 在安全监控方面提供了多重保障：

  1. 防篡改监控：由于 eBPF 程序在内核空间执行，即使系统被 rootkit 感染，psc 仍然能够看到真实的进程状态。这对于安全审计和入侵检测至关重要。

  2. 权限提升检测：psc 可以检测 SUID 权限提升：

    psc 'process.ruid != process.euid'

  3. 能力集监控：可以检查进程的能力集：

    psc 'process.euid == 0' -o process.pid,process.name,process.capabilities.effective

  4. 容器逃逸检测：通过比较容器内外进程的命名空间，可以检测潜在的容器逃逸行为。

限制与注意事项

尽管 psc 提供了强大的功能，但在实际使用中仍需注意以下限制：

  1. 内核版本要求：必须使用 Linux 内核 5.8 或更高版本，这限制了在旧系统上的部署。

  2. root 权限需求：加载 eBPF 程序需要 root 权限，这在一定程度上限制了非特权用户的使用。

  3. 运行时兼容性：虽然支持多种容器运行时，但不同版本的运行时可能在元数据格式上有所差异。

  4. 性能影响：虽然 psc 本身性能优秀，但在高负载系统中频繁执行复杂查询仍可能对系统性能产生影响。

未来发展方向

psc 作为新一代进程监控工具，在未来有几个值得关注的发展方向：

  1. 更丰富的查询语言：扩展 CEL 支持，增加更多内置函数和操作符。

  2. 实时监控模式：添加持续监控功能，支持事件驱动的告警机制。

  3. 分布式监控：支持跨多个节点的统一监控视图。

  4. 与现有监控系统集成：提供 Prometheus 导出器、Grafana 面板等集成方案。

  5. 更细粒度的权限控制：支持非 root 用户的受限监控能力。

结语

psc 代表了进程监控工具的一次重要演进。通过结合 eBPF 迭代器的内核级访问能力和 CEL 查询语言的灵活性，它为容器化环境提供了前所未有的监控能力。与传统的ps、lsof、ss等工具相比，psc 不仅在性能和安全方面具有显著优势，更重要的是它真正理解了容器上下文，使得在复杂的微服务架构中进行精准监控成为可能。

对于运维工程师和安全专家来说，psc 是一个值得深入学习和掌握的工具。它不仅能够提高日常运维的效率，还能在安全事件响应中发挥关键作用。随着 eBPF 技术的不断成熟和普及，我们有理由相信，像 psc 这样的工具将成为未来系统监控的标准配置。

资料来源：

查看归档