Verify that audit tools are owned by root
Ensures the audit control tool /sbin/auditctl (representative of the audit toolset) is owned by root (uid 0).
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
The audit tools (auditctl, auditd, ausearch, aureport, autrace, augenrules) are what defines, collects and reviews the security audit trail. If auditctl is owned by a non-root user, that user can replace the binary to silently disable rules, drop events, or forge audit data, destroying the integrity of the very record investigators rely on after an incident. Restricting ownership to root (uid 0) ensures only the superuser can operate or alter the audit tooling.
What Pavois checks
Pavois asserts that the live binary /sbin/auditctl has owner uid 0, skipped via only_if when auditd is not installed. It reads the effective owner from the filesystem (stat) instead of the package manifest, so a binary swapped or re-owned out-of-band, exactly the kind of tampering an attacker would attempt to blind the audit subsystem, is still detected.
only_if { file('/sbin/auditctl').exist? }
describe file('/sbin/auditctl') do
its('uid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%U %u' /sbin/auditctl. Expected output: root 0. To check the whole toolset, run for b in auditctl auditd ausearch aureport autrace augenrules; do stat -c '%U %n' "$(command -v $b)"; done and confirm every line starts with root.
Inspect & investigate
Ownership has no continuous log; query it with stat /sbin/auditctl. Audit activity itself is recorded in /var/log/audit/audit.log; if the audit binaries' directory is watched, changes to them appear there too. Note that ausearch can return false "no matches", grep the raw log directly, e.g. grep auditctl /var/log/audit/audit.log.
Remediation
No automated harden plan is defined, so apply it manually: chown root:root /sbin/auditctl (and likewise for the other audit binaries). Reinstalling the auditd/audit package restores the correct root ownership for the whole toolset.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| owner | root |
|---|---|
| path | /sbin/auditctl |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A non-root owner of the audit tools can disable or falsify your entire audit trail, defeating forensics and many compliance controls at once. Restoring root ownership is safe: it does not change how the tools behave for authorized administrators (who run them via sudo). Precaution: the audit binaries must keep their executable bit and their normal mode; only correct the owner, do not loosen permissions, or you would let non-privileged users invoke audit administration.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 6.2.4.9, 6.3.4.9 | direct | per OS, see the benchmark table | high |
| DISA STIG | UBTU-22-232110, UBTU-24-901240 | direct | per OS STIG release | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.