怎么在Linux利用Auditd监控特定PID的资源限制变更行为并输出至管理日志-linux运维-PHP中文网

auditd 无法直接按 pid 过滤资源限制变更，但可通过监控 setrlimit 系统调用并结合 ausearch 按 pid 字段筛选实现间接追踪；需添加 -a always,exit -f arch=b64 -s setrlimit 规则，再用 ausearch --pid 提取目标进程事件。

怎么在linux利用auditd监控特定pid的资源限制变更行为并输出至管理日志

auditd 本身不直接支持按 PID 过滤监控资源限制变更（如 setrlimit、prlimit 修改 open files、stack size 等），因为它的核心机制基于系统调用（syscall）和路径规则，而非运行时进程状态。但你可以通过精准挂钩相关系统调用，并结合上下文字段（如 pid、comm、exe、auid）实现“对特定 PID 行为的间接追踪”——前提是该 PID 对应的进程在生命周期内执行了受监控的系统调用。

监控资源限制变更的核心系统调用

Linux 中修改进程资源限制主要依赖以下系统调用：

setrlimit：设置当前进程或其子进程的资源限制（最常用）
prctl（部分子功能，如 PR_SET_NO_NEW_PRIVS 不相关，但 PR_SET_MM 等极少见）
arch_prctl（x86_64 架构特有，一般不用于资源限制）

其中 setrlimit 是审计重点。它属于 exit 类型系统调用（即在调用返回后触发审计事件），且可被 auditd 精确捕获。

添加针对 setrlimit 的审计规则

使用 auditctl 添加一条永久性规则（写入 /etc/audit/rules.d/rlimit.rules）：

-a always,exit -F arch=b64 -S setrlimit -k rlimit_change

说明：

-a always,exit：在系统调用退出时无条件记录
-F arch=b64：指定 64 位架构（CentOS/RHEL 8+/Ubuntu 20.04+ 默认；若需兼容 32 位，请额外加 -F arch=b32 规则）
-S setrlimit：监控 setrlimit 系统调用
-k rlimit_change：打标签便于后续检索

加载规则：

Obsidian (Linux)

操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。

下载

sudo augenrules --load

如何关联到“特定 PID”并输出至管理日志

auditd 不支持规则中硬编码 PID（PID 是动态的），但你可在日志分析阶段按 PID 筛选。关键在于：每条 setrlimit 审计事件都自带完整上下文，包括 pid 字段。因此分两步实现目标：

实时捕获：上述规则确保所有 setrlimit 调用都被记录到 /var/log/audit/audit.log
定向提取 + 转发：用 ausearch 实时过滤出目标 PID 的事件，并通过管道写入管理日志（如 /var/log/rlimit-monitor.log）

示例脚本（以监控 PID 1234 为例）：

#!/bin/bash
TARGET_PID="1234"
LOG_FILE="/var/log/rlimit-monitor.log"
<h1>持续监听新事件（从最新位置开始）</h1><p>sudo ausearch -m SYSCALL -sc setrlimit --start recent --pid "$TARGET_PID" --raw | \
aureport -f -i --key rlimit_change 2>/dev/null | \
sudo tee -a "$LOG_FILE" > /dev/null
</p>

更健壮的做法是配合 auditd 的插件机制或使用 audispd 配置外部插件（如自定义 Python 脚本），但对大多数场景，定时轮询 + ausearch --start boot --pid 已足够实用。

验证与调试技巧

手动触发测试行为：

# 启动一个测试进程并记下其 PID
sleep 3600 &
echo $!
<h1>在另一终端对其修改限制（需 root 或相同用户权限）</h1><p>sudo prlimit --nofile=1024:2048 $!
</p>

立即检查是否生成对应审计事件：

sudo ausearch -m SYSCALL -sc setrlimit -i --pid $YOUR_TEST_PID

若无输出，检查：
– 是否启用了 64 位规则（uname -m 确认架构）
– 目标进程是否真的调用了 setrlimit（strace -e trace=setrlimit $CMD 验证）
– 规则是否已加载（sudo auditctl -l | grep setrlimit）

本质上，auditd 提供的是 syscall 级别的“事件底座”，而“监控特定 PID”是上层分析逻辑。只要明确目标行为落在 setrlimit 范围内，这套方法就能稳定、低开销地完成追踪和日志分流。