Linux Audit (auditd)
Linux Audit records selected security-configuration operations on the Rocky Linux host, with auditd collecting Audit records. It helps answer what process changed a monitored object, when the operation happened, and which login identity was available. This activity evidence helps investigate a difference detected by AIDE.
Select the changes that matter
The policy selects writes and attribute changes to authentication, privilege, firewall, device, detection, service and SELinux configuration. It uses file and directory rules for both supported syscall architectures, following the Linux Audit rule interface. Directory coverage is limited by filesystem and mount boundaries.
The selection concentrates review on changes to security controls. General command execution, file reads, network activity, known credential-bearing paths, application databases and container state are outside this policy. Investigations involving those activities need evidence from the relevant service or other configured controls.
The host's Audit retention, backlog and failure policies govern how this evidence is retained and handled under pressure. Validation checks both loaded rules and a matching event so the recorded configuration is tied to actual collection.
Investigate a configuration change
For example, an AIDE finding after SSH maintenance may show a configuration file with changed content or permissions. If the operation matched an Audit rule and the event is still retained, the Audit records can help associate that path with an executable, an operation result and available login identity. Compare those facts with the intended maintenance before deciding whether the new state is acceptable.
The security report and doctor bring selected activity and Audit health into the initial review. A missing matching event leaves attribution unresolved: the operation may be outside the selected coverage, outside the retained interval, or affected by collection problems. Check coverage and collection health before interpreting silence.
Interpret identity and activity
An Audit event can contain several records describing one operation. The local security report groups them by Audit timestamp and serial, associates syscall activity with selected paths, and keeps rule-loading events separate from filesystem changes.
| Evidence | What it establishes |
|---|---|
Login identity (auid) | The original login account when available; it can differ from the effective identity after privilege elevation. |
| Effective identity and executable | The privileges and process associated with the operation. |
| Selected path, result and timestamp | The affected monitored object, whether the operation succeeded, and when it was recorded. |
| Audit loss and backlog | Whether the observed collection state indicates lost events or queued work. |
Daemon activity can have an unset login identity. When an account is available, it identifies the recorded login context; establishing who controlled that account and whether the change was authorized requires additional context. The operation result describes whether the filesystem action succeeded.
Validation and limits
A controlled metadata-only change produced the expected event with its selected path, executable, login identity and effective identity. Reboot validation confirmed that the intended rules loaded again. Bounded observation found no lost events or outstanding backlog during those checks; that observation is not a guarantee of continuous future collection.
Use Audit for activity evidence, AIDE for comparison with approved state, and Maintenance for the review and acceptance workflow. SELinux, firewalld and service authentication enforce their respective access policies while these observations help the operator understand changes.