不能。auditd 不解析 shell 环境变量赋值，需监控 execve()（记录 envp）、openat()（读取预加载 so 文件）和 setenv() 等系统调用，结合 /proc/PID/environ 与 /proc/PID/maps 验证实际劫持行为。
auditd 能不能直接监控 LD_PRELOAD 环境变量赋值？
不能。auditd 本身不解析 shell 环境变量赋值语句（比如 export LD_PRELOAD=/mal.so），也不会记录 bash 解析 export 命令的过程。它监控的是系统调用和进程行为，不是 shell 解释器的内部操作。
真正该监控的是哪些系统调用和事件？
LD_PRELOAD 劫持生效的关键动作发生在进程启动时的动态链接阶段，核心监控点有三个：
-
execve()：所有命令执行的起点，必须记录参数（尤其是argv和环境变量数组envp） -
openat()或open()：动态链接器（/lib64/ld-linux-x86-64.so.2）会尝试打开LD_PRELOAD指定的.so文件，这是最直接的落地痕迹 -
setenv()/putenv()：部分恶意库会在自身初始化时调用这些函数修改环境（比如清除LD_PRELOAD防止递归），可作为辅助线索
怎么写 auditd 规则才能捕获真实劫持行为？
规则要聚焦在「进程加载共享库」这个动作上，而不是盯住 export 命令。推荐两条关键规则：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
监控所有 execve 调用并记录完整环境变量：-a always,exit -F arch=b64 -S execve -F key=exec_env
监控对可疑路径的 openat（比如临时目录、用户家目录下的 .so）：-a always,exit -F arch=b64 -S openat -F path=/tmp/ -F perm=r -k ld_preload_open-a always,exit -F arch=b64 -S openat -F path=/home/ -F perm=r -k ld_preload_open
注意：perm=r 是为了捕获读取操作（链接器必须能读取该文件），不要用 perm=w —— 攻击者通常不会在劫持时写这个文件。
为什么只靠 auditd 日志还不够？
因为 LD_PRELOAD 的实际影响发生在进程内存中，auditd 日志里看不到函数被替换、puts 被重定向这些运行时行为。你只能看到「某进程试图加载了 /tmp/hack.so」，但无法确认它是否真的劫持了某个函数。真正的确认需要结合：
– cat /proc/<PID>/environ | tr '\0' '\n' | grep LD_PRELOAD（查当前进程环境）
– readelf -d /proc/<PID>/exe | grep NEEDED（看它依赖哪些库，但看不出 preload）
– 更可靠的是用 lsof -p <PID> 或 cat /proc/<PID>/maps 查看是否映射了异常的 .so 文件
