auditd无法直接监控SHM读写内容，但可通过审计shmget/shmat/mmap等系统调用、分析flags/prot参数（如0x1001、0x5）、结合UID/命令路径/时间序列识别可疑行为，并配合/dev/shm权限收紧与memlock限制实现有效防护。
auditd 无法直接监控共享内存段（SHM）的读写内容，因为 SHM 数据访问发生在进程虚拟地址空间内，不经过文件 I/O 或传统系统调用路径（如 read/write）。但可通过精准捕获其生命周期控制行为与内存映射动作，结合上下文特征识别高风险操作，从而有效防范恶意进程窃取 SHM 中的敏感数据（如认证凭据、加密密钥、会话令牌等）。
监控 SHM 创建与映射的关键系统调用
所有合法 SHM 使用都始于特定系统调用。审计这些调用可掌握谁在何时、以何种权限创建或接入共享内存：
- 记录 SHM 生命周期：
sudo auditctl -a always,exit -F arch=b64 -S shmget,shmat,shmdt,shmctl -k shm_lifecycle可捕获 key、size、flags（含权限位如0600）、shmid、shmflg（是否只读）等关键字段 - 捕获可疑内存映射行为：
sudo auditctl -a always,exit -F arch=b64 -S mmap,mmap2 -F flags=0x1001 -k shm_mmap_anon0x1001表示MAP_SHARED | MAP_ANONYMOUS，常用于绕过 /dev/shm 目录限制的隐蔽通信 - 关注可执行映射（常见于注入攻击）：
sudo auditctl -a always,exit -F arch=b64 -S mmap,mmap2 -F prot=0x5 -k shm_exec_mapprot=0x5即PROT_READ | PROT_EXEC，可能加载恶意代码到 SHM 区域
从日志中识别非法读写意图的上下文线索
单条系统调用日志不能定性为“非法”，需组合分析 UID、命令路径、参数和时间序列：
- 排查宽松权限 SHM 段：
ausearch -m shmget -ui 1000..60000 --start today | aureport -f -i | grep -E "(0666|0644)"普通用户创建全局可读写的 SHM（如0666），极易被其他进程 attach 窃取 - 定位异常 shmat 后行为：
若某进程在
shmat返回成功后 1 秒内触发execve，且参数含 base64 字符串或指向/dev/shm/下临时文件，高度可疑 - 关联非授权进程访问：
ausearch -m shmat -F auid!=0 -F exe="/usr/bin/python3" -i | grep "shmid=[0-9]*"检查非 root 进程（如 Python 脚本）是否附加了本不该访问的 SHM 段
配合主动防护降低 SHM 数据暴露面
审计是事后手段，必须叠加权限控制与环境隔离才能真正防范内存窃取：
- 收紧
/dev/shm访问权限：sudo chmod 0755 /dev/shm && sudo chown root:root /dev/shm阻止普通用户在该目录下创建任意文件或绑定命名 SHM - 限制用户可创建的 SHM 总量：
在
/etc/security/limits.conf中添加：* soft memlock 65536* hard memlock 65536防止滥用mmap(MAP_SHARED)占满内存并隐匿数据 - 禁用非必要 SHM 接口（仅限可信环境）：
echo 'kernel.shmall = 0' | sudo tee -a /etc/sysctl.confsudo sysctl -p彻底关闭 System V SHM（需确认业务无依赖）
不复杂但容易忽略：真正有效的 SHM 安全监控，不是试图“监听内存”，而是盯紧谁有资格建、谁有权连、连完干了什么。把系统调用审计、上下文过滤和权限加固三者拧成一股绳，才能让 SHM 从攻击者的“自由通道”变成受控的“安检通道”。
