AIDE
Advanced Intrusion Detection Environment (AIDE) is a file and directory integrity checker. Here it answers a practical maintenance question: do the selected configuration files and trusted local tools still match the state the operator approved?
AIDE records file contents as cryptographic hashes and records selected attributes in a database, used as the integrity baseline. Later checks report added, removed or changed entries. This makes an unexpected configuration edit visible even when the service still appears healthy. Linux Audit (auditd) supplies complementary activity evidence for investigating how a selected change happened.
Follow a configuration change
Consider an illustrative maintenance task: changing an SSH configuration file covered by the integrity policy. AIDE reports the resulting content or attribute difference. That finding is useful even when the edit was intended: it prompts the operator to compare the actual changes with the authorized work.
The review follows four steps:
- Inspect the changed objects and attributes, including any affected directory metadata.
- Compare them with the intended maintenance. Use retained Audit events for available process, login and timing evidence when a change needs investigation.
- Generate and review a candidate baseline once the changes are understood, then explicitly approve it.
- Run another check to confirm that the selected objects match the newly approved baseline.
An unexplained extra change stays under investigation. Approving a baseline is a trust decision: accepting every difference would turn an accidental or malicious change into the new reference state.
Scope and attributes
The integrity policy covers selected host security configuration, service configuration, trusted local maintenance code and stable ingress configuration. It checks content with SHA-512 and tracks file type, permissions, ownership, inode and link information, size, modification/change times, ACLs, SELinux context and extended attributes.
Metadata describes how a file is identified and accessed. A permissions change can affect who may modify a file; a SELinux context change can affect which confined processes may use it. Replacing a file with identical bytes can also change its inode, and installing or removing a child can change its parent directory's metadata. Access time is excluded so ordinary reads do not themselves create an integrity finding.
The policy concentrates on stable security configuration and trusted code whose changes can be reviewed against an intended operation. Known credential-bearing paths are excluded to protect sensitive material, while application databases, container state, logs, caches and release-managed output follow their own changing lifecycles. An explicit exclusion removes generated bytecode from traversal while retaining coverage of the surrounding trusted code. Changes in those excluded areas will therefore need evidence from their owning application or control.
The observed Rocky Linux package uses AIDE 0.19.2. The standalone policy is validated against that build's compiled features, including ACL, SELinux, extended-attribute and SHA-512 support. The AIDE 0.19.2 attribute reference defines the underlying checks; package feature inspection establishes which are available locally.
Approval is a separate action
AIDE provides initialization, checking and updating operations. The project's lifecycle helper adds explicit approval and three database roles around those upstream operations:
| Database | Purpose |
|---|---|
| Active | The approved baseline used by integrity checks. |
| Candidate | A newly generated baseline awaiting review. |
| Previous | The former active baseline retained after a subsequent promotion. |
An integrity check uses the active database as its reference. Findings remain visible on subsequent checks until the filesystem is restored to the approved state or the operator approves a reviewed candidate.
After an authorized change, an update creates a candidate while preserving the active baseline. Promotion is the helper's explicit approval action: the candidate becomes active and the former active database becomes previous. These names and the promotion workflow describe the local integration.
The lifecycle helper enforces restrictive ownership and permissions, refuses unsafe paths and retains previous baseline state. Interrupted promotion can leave recovery evidence requiring inspection before another transition. The previous database provides a retained reference; recovery still requires a deliberate choice of which filesystem state is trusted.
Validation and interpretation
Controlled validation changed only monitored metadata and produced the expected integrity finding. Repeating the check preserved that unapproved difference. Candidate creation left the active baseline intact; explicit promotion retained the former baseline, and the next check was clean. Reviewed changes to trusted maintenance code were also reconciled through this same approval boundary.
A finding means that a tracked object differs from the approved baseline. It can reflect authorized maintenance, an accidental change or malicious activity; the maintenance record and available Audit evidence help interpret it. A clean result means that the selected objects match the baseline. That conclusion depends on the operator's review and protection of the checker and database; excluded objects remain outside the conclusion.
Daily scheduled checks provide recurring integrity observations. The security report and doctor also run an integrity check and expose its outcome alongside control health. Start there for the review workflow, and use Maintenance to connect a finding with the work that preceded it. Baseline approval remains an explicit action in the AIDE lifecycle.