auditd is the user-space daemon of the Linux Audit framework, often simply called Linux audit, which receives security-relevant events generated by the kernel and writes them to an audit log, by default /var/log/audit/audit.log. In Linux security, it provides the tamper-resistant event trail that compliance frameworks and incident responders rely on to answer who did what, when and with which result.
The kernel decides which events to record according to audit rules, while auditd handles storage, rotation and delivery. Together with tools such as auditctl, ausearch, aureport and the dispatcher plugins, it forms the standard auditing stack on Red Hat Enterprise Linux, Fedora, Debian, Ubuntu and SUSE systems.
How the Linux audit framework works
Auditing starts in the kernel. Hooks in the system call path and in security subsystems such as SELinux and the PAM login stack generate audit records whenever an event matches a loaded rule. The kernel sends these records over a netlink socket to auditd, which writes them to disk and can forward them to plugins.
Each event is composed of several record types sharing one event ID and timestamp, for example a SYSCALL record with the process details, a PATH record for each affected file and a PROCTITLE record with the command line. Every record carries the audit user ID (auid), also called the login UID, which stays constant when a user escalates privileges with sudo or su, so actions remain attributable to the original login.
| Component | Location | Role |
|---|---|---|
| Kernel audit subsystem | Kernel | Evaluates rules, generates records |
| auditd | User-space daemon | Writes logs, handles rotation and disk limits |
| auditctl | Command-line tool | Loads rules and queries status at runtime |
| augenrules | Helper script | Merges rule files from /etc/audit/rules.d |
| ausearch / aureport | Analysis tools | Search events and produce summaries |
| Dispatcher plugins | auditd plugin interface | Forward events, for example to syslog |
Audit rules and what they capture
Audit rules come in three kinds: control rules that configure the subsystem, file watch rules that monitor access to paths, and system call rules that match specific calls with filters on architecture, user, exit code and other fields. Rules are usually stored in /etc/audit/rules.d/ and compiled into audit.rules at startup.
| Rule type | Example | What it records |
|---|---|---|
| Control rule | -b 8192 and -f 1 | Buffer size and failure mode |
| File watch | -w /etc/shadow -p wa -k identity | Writes and attribute changes to a file |
| System call rule | -a always,exit -F arch=b64 -S execve | Every program execution |
| Filtered syscall rule | -F auid>=1000 -F auid!=unset | Restricts events to real user logins |
| Immutable flag | -e 2 | Locks rules until the next reboot |
The key field (-k) attaches a label to matching events so that analysts can later run ausearch -k identity instead of filtering raw records. Distributions ship sample rule sets aligned with common security baselines, which are a better starting point than writing rules from scratch.
Daemon configuration and failure handling
auditd is configured in /etc/audit/auditd.conf, which controls log size, rotation and what happens when the disk fills. These settings decide whether audit data is lost silently or whether the system protects the trail at the expense of availability.
| Parameter | Typical values | Effect |
|---|---|---|
| max_log_file | 8 to 100 MB | Size of one log file before action |
| max_log_file_action | ROTATE, KEEP_LOGS | Rotation behavior at the size limit |
| num_logs | 5 to 10 | Number of rotated files kept |
| space_left_action | SYSLOG, EMAIL, SUSPEND | Warning when free space is low |
| disk_full_action | SUSPEND, SINGLE, HALT | Behavior when the disk is full |
| flush | INCREMENTAL_ASYNC | Trade-off between speed and durability |
The kernel failure flag -f adds a second safety level: value 1 logs a kernel message when events are lost, while value 2 triggers a kernel panic. High-assurance environments choose to halt rather than continue unaudited, but most general servers favor availability.
auditd compared with related Linux security tools
auditd records events but does not prevent them. That distinguishes it from enforcement mechanisms such as SELinux, AppArmor and seccomp, which block actions, and from tools that react to logs, such as Fail2ban.
| Tool | Primary function | Relationship to auditd |
|---|---|---|
| auditd | Detailed, attributable event logging | Reference trail for investigation |
| SELinux / AppArmor | Mandatory access control | Denials appear as AVC or APPARMOR records |
| Seccomp | System call filtering per process | Violations can generate audit records |
| journald / syslog | General system logging | Can receive audit events via plugins |
| Fail2ban | Bans hosts after failed logins | Reacts to logs, records nothing itself |
In larger fleets, audit events are shipped to a central SIEM so that a compromised host cannot erase its own trail. eBPF-based monitoring tools increasingly complement auditd, offering richer context, but auditd remains the mechanism that compliance auditors expect to see.
Performance impact and common mistakes
The cost of auditing depends almost entirely on how many events the rules generate. Watches on a few sensitive files are negligible, while a rule that records every execve or every file open on a busy build server can produce gigabytes of logs per day and measurable CPU overhead.
- Over-broad rules: auditing all system calls without filters floods the log and hides relevant events.
- Missing architecture filters: on 64-bit systems, rules need both
arch=b64andarch=b32variants, otherwise 32-bit calls bypass them. - Small backlog buffer: a low
-bvalue causes lost events under load;auditctl -sshows the lost counter. - Logs kept only locally: an attacker with root access can delete them unless they are forwarded.
- Restarting with systemctl: auditd refuses ordinary stop requests; the
service auditd restartpath is the supported method.
Put simply
auditd is like a security camera system for a Linux computer. It does not lock any doors, but it writes down who opened which door and when, including attempts that failed.
Administrators decide in advance which doors to watch, such as the file with password hashes or the command that changes system time. When something goes wrong, the recorded trail lets investigators reconstruct exactly what happened, even if a user switched to the administrator account along the way.
In practice
A payment company must show auditors that changes to user accounts and privileged commands on its Linux servers are recorded. The security team deploys a rule set that watches /etc/passwd, /etc/shadow and /etc/sudoers with the key identity, records every command run with elevated rights, and sets the rules to immutable with -e 2.
Events are forwarded to a central log platform within seconds. When a configuration change breaks a service one night, an engineer runs ausearch -k identity -ts yesterday and finds that a colleague’s login, identified by its unchanged audit user ID, edited the sudoers file through sudo. The incident is explained in minutes, and the same evidence satisfies the annual compliance review.