Stop letting auditd flood your disk just to catch one execve

Security Hardening (SELinux/AppArmor/Auditd)

Stop letting auditd flood your disk just to catch one execve

Technical Briefing | 9/11/2026

You probably set up auditd years ago by blindly copying a rule set off the internet. It works until the day your disk hits 100 percent because a busy application is spamming execve calls, or worse, your log rotation script fails and the kernel starts dropping events. That last part is the silent killer. When the audit buffer overflows, you are flying blind without knowing a single thing was missed.

Filter the noise before it hits the logs

The trap most people fall into is logging every single process execution. If you have a web server spawning thousands of short-lived workers, your logs will be useless and your I/O wait will spike. The key is using the filter exit rule to ignore processes you already trust or that you simply do not care about. You should be filtering by group ID or specific user IDs to carve out the high-frequency chatter.

auditctl -a exclude,always -F arch=b64 -F euid=33 -S execve

  • Exclude high-volume service accounts by UID or GID
  • Use -F key= to label your rules so you can grep them out of the haystack
  • Set the audit buffer size to at least 8192 if you see backlog drops in dmesg
  • Never log file writes unless you are tracking specific sensitive configuration paths

What to do when the buffer starts dropping

Check your audit status periodically. If you see the lost count climbing, do not just increase the buffer. Auditd is a kernel-to-userland pipe and it has a finite capacity. If the logging daemon can not write to disk faster than the kernel produces events, the system will start dropping records regardless of how big you make the buffer. This is where you need to check if you have an I/O bottleneck or if your rules are just too aggressive for the production load.

Next time the logs are quiet, run auditctl -s and check the backlog_lost value. If it is anything higher than zero, you are already losing data, and you are better off narrowing your audit scope than trying to brute-force more performance out of the daemon.

Linux Admin Automation  |  © www.ngelinux.com  |  9/11/2026

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Newest
Oldest Most Voted