How Auditd Tracks Security Events in Linux

The Linux Audit daemon (auditd) serves as the userspace component of the Linux Audit Subsystem, tasked with collecting, storing, and managing security-relevant event records generated by the kernel. By monitoring system calls, file access, and critical system state changes, auditd provides administrators and security teams with an immutable trail of system activity. This article explains how auditd interfaces with the Linux kernel to capture security events, how rules govern its behavior, and how raw data transforms into actionable audit logs.

The Kernel-Space Foundation

The tracking mechanism does not originate within auditd itself; rather, it begins inside the Linux kernel via the kernel audit subsystem (kauditd). Operating at the kernel level allows the subsystem to intercept operations before they execute in userspace.

Whenever a process attempts an action—such as executing a binary, modifying a file, or invoking a system call—the kernel’s hooks evaluate the request against active audit filters. Because the monitoring occurs at the kernel level, processes cannot bypass or tamper with the logging mechanism from userspace without root-level exploitation of the kernel itself.

The Netlink Socket Interface

Once the kernel audit subsystem identifies an event that matches an active rule, it formats the data into an audit record and places it in an internal queue.

auditd connects to the kernel through a dedicated Netlink socket (NETLINK_AUDIT). Through this high-speed, bidirectional communication channel, auditd receives the queued audit messages directly from the kernel and writes them to disk, typically at /var/log/audit/audit.log.

If auditd stops running or falls behind in reading from the buffer, the kernel can be configured to hold messages in memory, drop non-critical messages, or halt the system entirely (kernel panic) to maintain strict compliance and prevent unlogged actions.

Defining What to Track: Audit Rules

The audit framework relies on rules configured by administrators using the auditctl utility or loaded at boot from /etc/audit/rules.d/*.rules. These rules fall into three primary categories:

• File System Watches: Administrators can monitor sensitive files and directories (such as /etc/passwd, /etc/shadow, or /var/log). A watch triggers whenever a process attempts to read, write, execute, or change attributes on the specified path.
• System Call Rules: These rules instruct the kernel to monitor specific system calls (syscalls) such as execve (executing a program), openat (opening a file), or setuid (changing user privileges). Rules can be filtered by user ID (UID), process ID (PID), architecture, or exit code (success or failure).
• Control Rules: These rules configure the audit system's operational parameters, such as buffer sizes, failure flags, and rate limits.

The Event Lifecycle

The process of tracking an event follows a distinct lifecycle:

1. Trigger: A process invokes a system call or interacts with a monitored file system object.
2. Evaluation: The kernel checks the operation against the list of active audit rules.
3. Record Creation: If a rule matches, the kernel gathers context, including the time, process name, command-line arguments, parent process ID, real and effective user IDs, and the syscall return value.
4. Transmission: The record is forwarded via the Netlink socket to auditd.
5. Persistence: auditd writes the record to disk, rotating log files as they reach configured size limits.

Log Analysis and Visibility

The output written by auditd consists of structured, key-value pairs representing individual audit events. Each event receives a unique timestamp and serial number, allowing multiple interrelated records (such as execution parameters and file paths) to be correlated. Tools such as ausearch and aureport query these logs, allowing administrators to filter for specific security anomalies, failed authorization attempts, or privilege escalations across the operating system.