Add nodev Option to /var/log/audit
Mounts /var/log/audit with the nodev option so the kernel refuses to interpret device files placed in that directory.
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
The only legitimate place for device files is /dev on the root partition (chroot jails being the rare exception). /var/log/audit holds the audit trail and should never contain device nodes. Mounting it with nodev tells the kernel to ignore any character or block special device found there, preventing an attacker who reaches this partition from planting a device node to bypass filesystem permissions and access raw disk or kernel memory.
What Pavois checks
Pavois inspects the effective mount with mount('/var/log/audit') and asserts its resolved options include nodev. It reads the live kernel mount table, what is actually enforced, rather than /etc/fstab, so it catches a partition remounted without the flag, a systemd mount-unit override, or an fstab entry that never applied, which a file-based scanner would wrongly pass.
describe mount('/var/log/audit') do
its('options') { should include 'nodev' }
end
describe command("{ findmnt --fstab -no OPTIONS /var/log/audit 2>/dev/null; grep -hsE '[[:space:]]/var/log/audit[[:space:]]' /etc/fstab 2>/dev/null; systemctl show -p Options -- $(systemd-escape -p --suffix=mount /var/log/audit 2>/dev/null) 2>/dev/null; } | grep -ow 'nodev'") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run findmnt /var/log/audit (or findmnt -no OPTIONS /var/log/audit) and confirm nodev is in the option list. Expected output contains nodev, e.g. /var/log/audit ... rw,nosuid,nodev,noexec,relatime.
Inspect & investigate
Mount state is queried live with findmnt /var/log/audit or cat /proc/mounts, not from a log. Boot-time and remount events appear via journalctl -b | grep -i audit. The audit daemon's own status is in systemctl status auditd and its records in /var/log/audit/audit.log.
Remediation
No automated harden plan ships for this rule yet, so it must be applied manually: this requires /var/log/audit to be a separate partition. Add nodev to its /etc/fstab entry, then mount -o remount /var/log/audit, or reboot, and re-scan to confirm.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | awk -v m=/var/log/audit -v o=nodev '$0!~/^[[:space:]]*#/&&$2==m{n=split($4,a,",");h=0;for(i=1;i<=n;i++)if(a[i]==o)h=1;if(!h)$4=$4","o}{print}' /etc/fstab >/etc/.fstab.pav && cat /etc/.fstab.pav >/etc/fstab && rm -f /etc/.fstab.pav; mountpoint -q /var/log/audit && mount -o remount,nodev /var/log/audit || true |
|---|---|
| name | mount-var-log-audit-nodev |
| not_if | awk -v m=/var/log/audit '$2==m&&$0!~/^[[:space:]]*#/{print $4}' /etc/fstab | tr , '\n' | grep -qx nodev |
| resource | exec |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Functional impact is essentially nil, the audit log directory never needs device nodes. Precautions: the option can only be set if /var/log/audit is a dedicated partition; on a default layout where it sits under the root or /var filesystem you must first create that partition (a disruptive change requiring planning, data migration of existing audit logs, and a reboot). Stop auditd before migrating data to avoid corrupting the active log.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 1.1.2.7.2 | direct | per OS, see the benchmark table | high |
| NIST | AC-6, AC-6(1), CM-6(a), CM-7(a), CM-7(b), MP-7 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
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.