Ensure /var/log Located On Separate Partition
Mounts /var/log on a dedicated filesystem so log growth is contained and cannot exhaust the root partition.
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
Mounting /var/log on its own partition separates log files from other data in /var and prevents runaway logging from filling the root filesystem, which would crash services and lock out administrators. A dedicated partition also lets you apply restrictive mount options and preserves logs needed for incident investigation.
What Pavois checks
Pavois reads the effective mount table via the mount('/var/log') resource (findmnt / /proc/self/mountinfo), not /etc/fstab. fstab only records intent, a mount can fail at boot or be shadowed by another mount. Inspecting the live kernel state proves /var/log is currently a separate mounted filesystem.
describe mount('/var/log') do
it { should be_mounted }
endHow to verify it is applied
Run findmnt /var/log. A returned line confirms a dedicated filesystem; empty output means /var/log shares /var or /, and the rule fails.
Inspect & investigate
Confirm with findmnt /var/log and watch usage with df -h /var/log. System logs themselves live under /var/log/ (e.g. /var/log/syslog, journalctl --disk-usage for the journal footprint).
Remediation
There is no automated harden plan: separating /var/log requires repartitioning, which cannot be done safely on a running system. Apply it manually, ideally at install time, by giving /var/log its own partition or LVM volume and declaring it in /etc/fstab.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # /var/log should be its OWN filesystem (isolation + mount options). This needs (re)partitioning , # offline disk/LVM work, not a safe runtime change. findmnt /var/log >/dev/null 2>&1 && echo '/var/log is already a mount point' || echo '/var/log is NOT separate' # Then: dedicate an LVM volume / disk to /var/log and add it to /etc/fstab. |
|---|---|
| reason | a separate /var/log filesystem needs partitioning/LVM/tmpfs, not a safe runtime change |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Without a separate /var/log, a verbose service or a log-flood attack can fill the root filesystem and take the host offline. Precautions before migrating: move the data with logging services stopped (or systemctl stop rsyslog systemd-journald momentarily), copy with rsync -aHAX to keep permissions, restore SELinux contexts where applicable (restorecon -R /var/log), size the volume for your retention, and keep console/rescue access in case the mount fails at boot.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R28 | direct | 2.0 | high |
| CIS | 1.1.2.6.1 | direct | per OS, see the benchmark table | high |
| NIST | AU-4, CM-6(a), SC-5(2) | 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.