auditd不能禁止系统调用，仅能审计记录；真正禁止需依赖seccomp-bpf、selinux/apparmor或capabilities等内核强制机制，auditd用于检测拦截事件、告警与追溯验证。
Linux auditd 本身不提供 Refuse_Anysyscalls 这类直接“禁止”系统调用的功能。它是一个审计（记录）工具，不是访问控制或执行拦截机制。所谓“拒绝高危系统调用”，必须依赖其他内核安全模块，auditd 只能配合完成日志记录与事后分析。
真正能禁止系统调用的机制
要阻止特定系统调用执行，需使用以下任一内核级强制机制：
-
seccomp-bpf：最常用、最灵活的方式。可为进程或容器精确白名单/黑名单系统调用（如禁止
execve、mount、ptrace）。Docker、systemd、runc 等均原生支持。 -
SELinux / AppArmor：通过策略限制进程能力，间接禁止某些调用（例如禁用
sys_admin权限后，多数挂载、模块加载调用将失败）。 -
Linux capabilities：移除
CAP_SYS_ADMIN、CAP_SYS_MODULE等能力，使普通进程无法执行对应高危操作。
auditd 在其中的角色：检测 + 告警 + 追溯
虽然不能禁止，但 auditd 是发现“谁试图调用被禁系统调用”的关键证据源。正确配置后，它能记录失败尝试（含 errno），帮助验证防护是否生效：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 监控被 seccomp 拦截的调用：
-a always,exit -F arch=b64 -S mount -F exit=-EPERM -k blocked_mount
（记录所有因权限不足被拒绝的mount调用） - 捕获异常 execve 尝试：
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F exit=-EACCES -k denied_exec - 标记所有失败的敏感调用：
-a always,exit -F arch=b64 -S openat,open,openat2 -F exit=-EACCES -k denied_file_access
验证防护是否真正生效的关键步骤
仅配置 auditd 不代表调用已被禁止。必须组合验证：
- 确认 seccomp 或 SELinux 策略已加载并启用（如
grep Seccomp /proc/$(pidof yourapp)/status） - 手动触发目标调用（如普通用户执行
mount /dev/sdb1 /mnt），观察是否返回Operation not permitted - 立即执行：
ausearch -m SYSCALL -ts recent | grep -E "(mount|execve)" | aureport -f -i
查看是否有带exit=-EPERM或exit=-EACCES的审计事件 - 检查
/var/log/audit/audit.log中是否出现type=ANOM_ABEND或type=AVC（SELinux 拒绝）等关联日志
不推荐的误区
避免以下无效或危险操作：
- 误以为
auditctl -a never,always -S mount能禁止调用——这只是让 auditd 忽略该调用，完全不记录，且对执行无任何影响； - 在未启用 seccomp 的情况下，仅靠 auditd 规则就声称“已禁止 execve”——这属于严重误判；
- 对 root 进程盲目加
-F uid!=0过滤，导致漏掉特权进程的违规行为。
