The audit trail is your security camera
You notice a configuration file changed, or a service crashed with a vague "Permission denied" error. The journalctl output shows the symptom but not the cause. The kernel audit subsystem has been recording every file access, login attempt, and privilege escalation, but the data sits in binary logs in /var/log/audit/. You need to query those logs to reconstruct the timeline and identify the root cause.
How auditd, ausearch, and aureport fit together
Fedora ships with auditd, the audit daemon. It runs in the kernel space and captures events based on rules. The rules define what to watch. The logs are append-only to prevent tampering. ausearch is the query tool. aureport is the summary tool.
Think of auditd as a security camera system. The camera records everything based on the motion sensors you configured. The footage is stored on a hard drive. ausearch is the search function that lets you find the clip where someone touched the server rack. aureport is the monthly summary that tells you how many times the door was opened and how many times the alarm triggered.
The audit logs are separate from the journal. journalctl captures service logs and kernel messages. auditd captures security-relevant events like file modifications, user logins, and SELinux denials. The two systems complement each other. You use journalctl for debugging services. You use ausearch for forensics and compliance.
Fedora enables auditd by default on Server editions. On Workstation, it may be disabled to save resources. The configuration lives in /etc/audit/auditd.conf. The rules live in /etc/audit/rules.d/. Never edit files in /usr/lib/audit/. Those are shipped by packages and will be overwritten on updates.
Run systemctl status auditd before you start searching. If the daemon is inactive, the logs are empty and you are looking at a ghost.
Searching logs with ausearch
ausearch queries the audit logs and returns matching records. It supports filters for message types, time ranges, users, files, and keys. The output includes the raw audit record and a human-readable interpretation.
Here's how to find all SELinux denials since the last boot.
sudo ausearch -m avc -ts recent
# sudo: audit logs are owned by root and require elevated privileges
# -m avc: filter for Access Vector Cache denials, which are SELinux blocks
# -ts recent: search from the last boot, not just the current calendar day
The -m avc flag targets SELinux denials. These are the most common audit events on a Fedora system. When a process tries to access a resource and SELinux policy blocks it, the kernel generates an AVC denial. The output shows the source context, the target context, and the operation that was denied.
Here's how to track access to a specific file.
sudo ausearch -f /etc/passwd -ts today
# -f: filter by filename or path, matching any access to the file
# -ts today: restrict the search to the current calendar day
# The search covers the current log and rotated logs automatically
The -f flag searches for file access. It matches reads, writes, attribute changes, and deletions. If you suspect a user modified a password file, this command shows every interaction with that file. The -ts flag accepts relative times like recent, today, yesterday, or absolute timestamps.
Here's how to search using audit keys for efficient lookup.
sudo ausearch -k sshd_login
# -k: search by audit key name, which is the fastest search method
# Keys are defined in /etc/audit/rules.d/ and tag specific events
# Searching by key avoids parsing filenames or PIDs in the query
Keys are the most efficient way to search. Rules in /etc/audit/rules.d/ can assign a key to a file or syscall. When you search by key, ausearch jumps directly to the relevant records. This is much faster than scanning for filenames, especially on systems with high audit volume.
Check the rules file to see what keys are defined. The file /etc/audit/rules.d/audit.rules or files in /etc/audit/rules.d/ contain lines starting with -w for watch rules. The -k argument in the rule sets the key name.
Run ausearch with -k keys. Searching by key is faster than parsing filenames and scales better as logs grow.
Generating reports with aureport
aureport summarizes audit logs into readable tables. It aggregates data by user, file, or event type. It is useful for compliance checks and quick overviews.
Here's how to generate a login report with resolved names.
sudo aureport -l -i
# -l: generate a login report showing successful and failed logins
# -i: resolve IDs to names, converting user IDs to usernames and IPs to hostnames
# Without -i, the output shows numeric IDs that are hard to interpret
The -l flag produces a login report. It lists the number of successful and failed logins per user. The -i flag is essential for readability. It translates user IDs to usernames and IP addresses to hostnames. Without -i, you get a list of numbers that require manual lookup.
Here's how to summarize file access events.
sudo aureport -f -i -ts today
# -f: generate a file report showing file access counts
# -ts today: limit the summary to the current day
# The report groups events by file path and shows access counts
The -f flag generates a file report. It shows how many times each file was accessed. This helps identify files under heavy scrutiny or unexpected access patterns. Combine with -ts and -te to define a time range.
Here's how to check for authentication failures.
sudo aureport -a -i
# -a: generate an authentication report
# The report lists login attempts, sudo usage, and su usage
# Failed attempts are flagged separately for security review
The -a flag covers authentication events. It includes logins, sudo usage, and su usage. Failed attempts are highlighted. This report is useful for detecting brute-force attempts or unauthorized privilege escalation.
Use aureport -i for readability. Raw IDs are useless to humans and waste time during incident response.
Verify the audit daemon is running
The audit tools only work if auditd is active. The daemon must be running to capture events. It must be enabled to start on boot.
Here's how to check the daemon status and recent logs.
systemctl status auditd
# Check the active state and recent journal lines
# Look for "active (running)" in the output
# If inactive, run 'sudo systemctl enable --now auditd' to start it
If the service is inactive, enable it immediately. A system without audit logging is blind to security events. On Fedora, auditd integrates with systemd. The status command shows the state and recent messages. If the daemon failed to start, check the journal for configuration errors.
Check auditd status first. No daemon means no logs, and you cannot retroactively enable auditing for past events.
Common pitfalls and error messages
Audit logging has specific behaviors that catch new users off guard. The logs can fill the disk. The daemon can halt the system. The output can be noisy.
The most common error is a missing daemon. If you run ausearch and get this output, the service is not running.
Error: auditd is not running.
Start the daemon with sudo systemctl enable --now auditd. The error stops you from searching because there is no data source.
Another issue is disk space. auditd writes to /var/log/audit/audit.log. If the log grows too large, the daemon takes action based on max_log_file_action in /etc/audit/auditd.conf. The default action is rotate. The daemon rotates the log and continues. If the disk fills completely, the daemon may stop writing or halt the system depending on the configuration.
Monitor the log size. Rotate logs manually if necessary. A full disk can prevent the system from booting or logging critical events.
SELinux denials can be frequent. A fresh install or a custom application may trigger many AVC denials. Do not panic. Read the denial. Most are expected during initial configuration. Use ausearch -m avc to review them. If a denial is legitimate, adjust the policy. If it is noise, add an exception or ignore it.
Audit logs use UTC timestamps. ausearch converts timestamps to local time for display. Be aware of the timezone when correlating events with other logs. The raw records always use UTC.
Rotate logs manually if the disk fills up. auditd will stop writing and may halt the system if the configuration is set to syslog or halt.
When to use which tool
Use ausearch when you need to find a specific event, user, or file access pattern in the raw audit trail.
Use aureport when you need a statistical summary of logins, failures, or file changes for a compliance report.
Use journalctl when you are debugging a service failure or kernel message and don't need the granular security audit trail.
Use auditctl when you need to add or remove monitoring rules for specific files or syscalls.
Use sealert when you need to analyze a SELinux AVC denial and generate a policy module to fix it.
Trust the audit trail. journalctl can be cleared; audit logs are append-only and tamper-resistant.