← All rules
SOCLE-CLD-MNT-037// Mountsloweffective runtime

Ensure /var/log/audit Located On Separate Partition

Mounts /var/log/audit on a dedicated filesystem so the audit trail has guaranteed space and cannot be disrupted by other files.

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.

A pass proves✓ running now? on disk? survives rebootthe qualified verdict →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
One check, maps to 3 standards

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

Placing /var/log/audit on its own partition separates audit records from all other files and, critically, guarantees space for auditing. If audit logs shared a partition that filled up, auditd could halt or, depending on its disk-full policy, the kernel could panic or stop the system. A dedicated partition keeps the audit trail intact and isolates a log flood from the rest of the host.

What Pavois checks

Pavois checks the effective mount table via the mount('/var/log/audit') resource (findmnt / /proc/self/mountinfo), not /etc/fstab. fstab only states intent; a mount may have failed at boot or been overridden by a nested mount or systemd .mount unit. Querying the live kernel state confirms the audit directory is truly on its own filesystem.

describe mount('/var/log/audit') do
  it { should be_mounted }
end

How to verify it is applied

Run findmnt /var/log/audit. A returned line confirms a dedicated filesystem. Empty output means it falls back to /var/log, /var or /, and the rule fails.

Inspect & investigate

Use findmnt /var/log/audit and df -h /var/log/audit to confirm the mount and free space. The audit subsystem itself logs to /var/log/audit/audit.log; disk-full behaviour is governed by space_left_action / admin_space_left_action in /etc/audit/auditd.conf.

Remediation

There is no automated harden plan: creating this partition requires repartitioning, which cannot be done safely on a live system. Apply it manually, ideally at install time, by allocating a dedicated partition or LVM volume for /var/log/audit and adding it to /etc/fstab.

Pavois applies this with its own harden engine, the plan below, not a shell script:

command# /var/log/audit should be its OWN filesystem (isolation + mount options). This needs (re)partitioning , # offline disk/LVM work, not a safe runtime change. findmnt /var/log/audit >/dev/null 2>&1 && echo '/var/log/audit is already a mount point' || echo '/var/log/audit is NOT separate' # Then: dedicate an LVM volume / disk to /var/log/audit and add it to /etc/fstab.
reasona separate /var/log/audit filesystem needs partitioning/LVM/tmpfs, not a safe runtime change
resourcemanual
pavois harden plan local

where the target is local, a user@host SSH alias, or a container , Docs

Impact & precautions

Without isolation, a filled-up shared partition can stop auditing or trigger auditd's disk-full action, which on hardened systems may halt the machine to avoid losing records. Precautions before migrating: stop auditd before moving its data, preserve SELinux contexts (rsync -aHAX then restorecon -R /var/log/audit), size the volume per your retention policy, and review space_left_action so a full audit disk fails the way you expect. Keep console/rescue access in case the mount fails at boot.

Standards mapping

StandardReferenceTypeVersionConfidence
ANSSI BP-028R71direct2.0high
CIS1.1.2.7.1directper OS, see the benchmark tablehigh
NISTAU-4, CM-6(a), SC-5(2)supporting800-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.

Sources & references