Linux Audit Framework and Security Event Collection

Updated on Oct 3, 2026

9 min read

Linux Audit Framework rules let administrators record selected security-relevant activity that ordinary application logs may not capture. For Linux operators and security teams, understanding how kernel audit events, auditd, and event searches fit together makes it easier to investigate account changes, configuration edits, and privileged actions without treating every system log as the same kind of evidence. This explainer follows an event from a rule to a searchable record and shows how to test a small collection setup.

Why the Linux Audit Framework Matters

When investigating a suspected compromise, teams need more than a service error or a login message. They may need to know which process accessed a sensitive file, which identity performed the operation, whether the action succeeded, and what happened immediately before or after it.

The Linux Audit Framework provides a kernel-supported way to select and record system activity for later review. It is especially relevant on servers where operators need evidence of changes to security-sensitive files or execution of privileged programs. It is not a complete security-monitoring system by itself: rules determine what the kernel records, and separate processes and controls are needed to retain, protect, interpret, and respond to those events.

What Is the Linux Audit Framework?

The Linux Audit Framework is a kernel facility and userspace toolchain for recording selected security events. Administrators define audit rules; the kernel evaluates matching activity and produces records; and the auditd daemon receives and writes those records, usually to /var/log/audit/audit.log.

An audit event may contain several records that share a message identifier. A record can describe the system call, the process identity, a file path, the working directory, or command arguments. Tools such as ausearch group and interpret related records so an operator can investigate one action rather than reading unstructured lines by hand.

The Red Hat guide to auditing the system documents audit architecture, rule configuration, service operation, and event searches. The same Linux Audit userspace project is maintained in the linux-audit/audit-userspace repository, which includes the daemon and command-line tools used by many distributions.

Why the Framework Exists

System logs are produced by different components for different purposes. An application may record that a request failed; journald collects service and system messages; authentication services record sign-in activity; and the audit subsystem can capture configured kernel-level actions such as access to files or system calls.

Without a deliberate audit policy, an investigation may find that the host never recorded the action in question. At the other extreme, recording broad activity without a plan can create high event volume, expose sensitive command details, consume storage, and make important events harder to find. Audit rules help operators choose events according to specific questions, such as whether files under a configuration directory were changed or whether a privileged executable ran.

Audit records complement other sources rather than replacing them. A system call record does not necessarily explain the business purpose of an action, while an application log may not reliably identify the kernel-level process that accessed a file. Correlating sources gives investigators a more complete sequence.

How Audit Event Collection Works

The basic path is:

Rule configuration -> kernel rule evaluation -> audit records -> auditd -> local log or dispatcher -> search and response

Rules define scope. Administrators load rules that select system calls, files, users, or other supported attributes. Rules can be temporary or loaded from distribution-specific files at startup.
The kernel evaluates activity. When a process performs an operation covered by a rule, the kernel creates one or more records. Rules that are too broad can create substantial overhead and log volume.
auditd receives and writes records. The daemon reads audit messages from the kernel and applies settings such as log location, rotation, and failure behavior.
Tools retrieve evidence. ausearch filters records by key, time, identity, or other fields. aureport creates summaries that help identify patterns before a deeper investigation.
A collection pipeline protects and forwards data. Organizations can forward events to a remote logging system, but should monitor delivery and restrict access to both local and central copies.

Audit records commonly share an identifier shaped like msg=audit(timestamp:serial). The serial helps distinguish and associate records from an event. Depending on the operation, a group may include SYSCALL, PATH, CWD, EXECVE, or PROCTITLE records. An event does not always contain every record type, so interpretation should use the complete event and its context.

The NIST Guide to Computer Security Log Management explains why log generation, collection, storage, analysis, and protection must be planned as a lifecycle. Linux auditing supplies one source of records in that larger process; it does not provide the whole lifecycle automatically.

Component or source	What it does	What it does not guarantee
Kernel audit subsystem	Evaluates loaded rules and emits matching audit records	That every action is recorded if no rule covers it
`auditd`	Reads audit messages and manages the local audit log	That local logs cannot be changed by a sufficiently privileged attacker
`auditctl` and `augenrules`	Inspect or load rules, including persistent rules on systems using `augenrules`	That a rule is appropriate, low-volume, or portable to every distribution
`ausearch` and `aureport`	Find and summarize records in audit logs	That a match alone proves malicious intent
`journald` and application logs	Capture service messages and application-specific context	Kernel audit coverage unless a source explicitly forwards or duplicates it

The audit subsystem is also not the same thing as a Linux Security Module such as SELinux. SELinux makes access-control decisions; related denials may appear in audit records, but the policy engine and the audit event collection mechanism serve different roles. For policy concepts and denial analysis, see the SELinux configuration and management guide.

Real-World Uses

Investigating configuration changes

Rules can record writes or attribute changes under directories containing SSH, identity, or service configuration. Investigators can then search for the event key and inspect the process, user identity, timestamp, and affected path. This is useful only when the rule is narrow enough to generate actionable records and the logs are retained long enough to support an investigation.

Reviewing privileged activity

Audit rules can record selected system calls or access to privileged executables. This helps security teams understand how an administrative action occurred, but it does not determine whether the action was authorized. Compare events with change approvals, account ownership, and the host’s role.

Supporting incident response and compliance

Local audit records can help establish a timeline after unexpected account, permission, or service changes. Central forwarding can protect evidence from loss when a host is damaged, but the forwarder itself needs access controls, buffering, health monitoring, and a tested retention policy. For the wider collection and response pipeline, see Security Logging and Monitoring.

Practical Guide: Install, Add a Rule, and Verify

The package and service names vary by distribution. On Debian or Ubuntu, install the audit daemon and start it:

sudo apt update
sudo apt install auditd
sudo systemctl enable --now auditd

On a RHEL-family distribution, the package is commonly named audit:

sudo dnf install audit
sudo systemctl enable --now auditd

First check whether the daemon is running and inspect the current kernel audit status:

sudo systemctl status auditd
sudo auditctl -s

For a controlled test, create a directory and add a syscall-based rule that records writes and attribute changes beneath it. This example uses openat and a directory filter instead of the older watch syntax:

sudo mkdir -p /var/tmp/audit-lab
echo '-a always,exit -F arch=b64 -S openat -F dir=/var/tmp/audit-lab -F perm=wa -k audit_lab' |
  sudo tee /etc/audit/rules.d/50-audit-lab.rules
sudo augenrules --load
sudo auditctl -l
sudo touch /var/tmp/audit-lab/check
sudo ausearch -k audit_lab --start recent -i

The example assumes a system that uses /etc/audit/rules.d/ and augenrules. Follow the distribution’s documentation if it uses a different persistence mechanism. Add the appropriate 32-bit architecture rule only when 32-bit processes need coverage on a 64-bit host. Avoid broad rules on production systems until their event rate, storage impact, and sensitive fields have been evaluated.

For a real service, use the narrowest directory or syscall filter that answers the investigation question, store persistent rules in a clearly named file, and record why each rule exists. Review the rule list after loading, generate a known test event, and confirm that the resulting records include the fields operators need.

Troubleshooting checks

Use the following checks when events are missing or the daemon is unhealthy:

sudo auditctl -s
sudo auditctl -l
sudo ausearch -k audit_lab --start today -i
sudo aureport --summary -i
sudo journalctl -u auditd --since today

The audit status reports include counters that can reveal backlog pressure or lost records. If events are missing, confirm the rule is loaded, the correct architecture and system call are covered, the process actually accessed the target, and the event has not been filtered from the query. A rule that reaches the kernel is not enough if auditd cannot keep up or local storage is full.

Common Misconceptions

“Auditd records everything by default”

The audit subsystem records activity selected by the active rules and configuration. A host with the daemon running can still lack evidence for a particular action if no applicable rule was loaded.

“An audit event proves an attack happened”

An event is evidence that a configured operation occurred, not a verdict about intent. An authorized package update and an unauthorized edit can produce similar low-level records. Correlate identity, process, host purpose, change records, and nearby events.

“Local audit logs are tamper-proof”

Local files are valuable evidence, but root-level access or a compromised host may allow an attacker to interfere with collection or storage. Restrict access, alert on service and disk problems, forward important events to a separate trust boundary, and test the forwarding path.

“More rules always mean better coverage”

Excessive or unfocused rules can overwhelm storage and analysis, increasing the risk of losing or overlooking important events. Start with specific questions, test rule volume, and review coverage as systems change.

Security Logging and Monitoring explains how to build a protected pipeline across different event sources.
Linux Server Hardening Techniques covers practical host controls, including audit rule deployment.
SELinux Configuration and Management explains access-control policy and related denial events.

Changelog and Last Updated

Initial publication.
Last updated: at initial publication; revise when upstream tooling or distribution guidance changes.