Ensure auditd Collects Information on the Use of Privileged Commands - fdisk
Ensures auditd has a live rule (keyed modules) recording use of the privileged fdisk command.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
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
fdisk and the related disk/module tooling can repartition storage and manipulate low-level device state, exactly the kind of privileged action an attacker uses to plant persistence or destroy data. Auditing its use (under the modules key on this platform) records who invoked it and when, so misuse of privileged functions by insiders or compromised accounts can be detected and investigated.
What Pavois checks
Pavois runs auditctl -l and checks the loaded ruleset for a rule keyed modules. This inspects the effective kernel ruleset, not the rule files: a rule sitting in /etc/audit/rules.d/ but never loaded (parse error or no reload) would fool a file-based scanner but correctly fails here.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)modules\b/) }
end
describe command("grep -rhwsE 'modules' /etc/audit/rules.d/*.rules /etc/audit/audit.rules 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run auditctl -l | grep modules. Expected: at least one rule line ending in -k modules (or key=modules) covering the fdisk binary. No output means the rule is not active.
Inspect & investigate
- Confirm the loaded rule:
auditctl -l | grep modules. - See recorded executions:
grep 'key="modules"' /var/log/audit/audit.log(prefer raw grep; ausearch is unreliable). - Service state:
systemctl status auditd.
Remediation
pavois harden apply uses the audit_ruleset resource to write the privileged-command watch for fdisk (keyed modules) into auditd's rules directory and reload the ruleset. The rule is reboot_required, so a reboot ensures the rules are loaded from boot and any immutable-mode setting is enforced.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| reboot_required | true |
|---|---|
| resource | audit_ruleset |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Without this rule, privileged disk operations leave no audit trail, hampering forensics and failing CIS/STIG/BP-028 audit requirements. Applying it only adds an audit watch and may require a reboot; impact is minimal since fdisk is invoked rarely, so log growth is negligible.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R73 | direct | 2.0 | high |
| CIS | 6.3.3.19, 6.2.3.19 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.7 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| DISA STIG | UBTU-22-654170, UBTU-22-654175, UBTU-22-654045, UBTU-22-654060, UBTU-24-900350, UBTU-24-900340, UBTU-24-900750, UBTU-24-900730 | 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.