核心思路是通过提权动作反推系统调用链并结合上下文判断非法性，重点监控execve、setuid/setgid、cap_setpcap三类关键syscall，利用ausearch精准筛选异常行为，并验证auditd规则是否生效。
核心思路是：从提权动作反推系统调用链，再结合上下文判断是否非法。重点不是查“有没有提权”，而是看“谁在什么条件下做了不该做的提权操作”。
盯住三类关键提权相关系统调用
非法提权往往不是单次行为，而是由多个 syscall 组成的链条。优先过滤以下调用：
-
execve：执行命令的入口，几乎所有提权操作都从此开始。重点关注参数中含
sudo、su、bash -i、/bin/sh、python -c、nc、curl的记录 - setuid / setgid / setreuid / setregid：直接修改进程 UID/GID。非 root 进程调用成功即高度可疑
- cap_setpcap：授予或剥夺进程能力（capability）。普通用户调用此 syscall 是典型内核级提权信号
用 ausearch 快速定位异常提权痕迹
直接在 /var/log/audit/audit.log 上操作效率低，必须用 ausearch 带条件筛选：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 查某用户最近15分钟所有 execve 调用，并提取命令行参数：
ausearch -m execve -ui $(id -u username) -ts recent --raw | aureport -f -i - 查所有非 root 用户调用 setuid 成功的事件：
ausearch -m syscall -sc 105 -sv yes | awk '$5 != "uid=0" {print}'（syscall 105 = setuid） - 查 cap_setpcap 调用，并关联其父进程和命令：
ausearch -m syscall -sc 122 --raw | aureport -f -i（syscall 122 = cap_setpcap）
识别高危提权上下文特征
单条 syscall 不足以定性，要结合时间、路径、权限、失败标记等判断是否异常：
- execve 调用路径在
/tmp、/dev/shm、/var/tmp下，且参数含base64、curl -s、wget -q、bash -c—— 典型内存马或下载执行 - sudo 执行成功但无对应
/var/log/auth.log中的 PAM 认证记录，或认证时间与 execve 时间差超过 2 秒 —— 可能绕过 sudo 日志或伪造会话 - setuid 成功后立即调用
openat读取/etc/shadow或写入/root/.ssh/authorized_keys—— 提权后立刻横向或持久化
验证 auditd 规则是否真正生效
很多“没看到日志”是因为规则配置错误，导致关键调用根本没被记录：
- 确认已启用对 execve 和 capability 相关 syscall 的监控：
auditctl -l | grep -E "(execve|cap_setpcap|setuid)" - 检查规则是否指定 64 位架构（x86_64 系统必须加
-F arch=b64），漏掉会导致 90% 的 execve 事件丢失 - 测试规则是否触发：手动运行
sudo echo test，再执行ausearch -m execve -ts recent | head -3，应有输出
