Ensure /var Located On Separate Partition
Mounts /var on a dedicated filesystem so variable data is isolated and growth there 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 on its own partition lets you set more restrictive mount options (e.g. nodev, nosuid) and protects the system services (daemons and other programs) that write there. /var commonly holds world-writable directories shipped by other packages, and isolating it prevents a flood of files there from filling the root filesystem and crashing the whole system.
What Pavois checks
Pavois reads the effective mount table through the mount('/var') resource (findmnt / /proc/self/mountinfo), not /etc/fstab. fstab only records intent, a mount can fail silently at boot or be shadowed by a systemd .mount unit. Checking the live kernel state proves /var is currently a separate mounted filesystem.
describe mount('/var') do
it { should be_mounted }
endHow to verify it is applied
Run findmnt /var. A returned line confirms /var is its own mounted filesystem. Empty output means /var lives on the root partition and the rule fails.
Inspect & investigate
Check findmnt /var and df -h /var for current usage. Boot-time mount problems show up in journalctl -b | grep -i var and systemctl status var.mount.
Remediation
There is no automated harden plan: carving out /var on a running system is disruptive (services write there constantly) and risky. Apply it manually, ideally at install time, by giving /var a dedicated 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 should be its OWN filesystem (isolation + mount options). This needs (re)partitioning , # offline disk/LVM work, not a safe runtime change. findmnt /var >/dev/null 2>&1 && echo '/var is already a mount point' || echo '/var is NOT separate' # Then: dedicate an LVM volume / disk to /var and add it to /etc/fstab. |
|---|---|
| reason | a separate /var 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 spam, mail spools, package caches or container layers can fill the root filesystem and take the whole host down. Precautions before migrating: /var is written to constantly, so move it with services stopped (single-user mode or a rescue boot), copy data with rsync -aHAX to preserve ownership/ACLs, size it generously, and keep console/rescue access in case the new mount fails at boot.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R28 | direct | 2.0 | high |
| CIS | 1.1.2.4.1 | direct | per OS, see the benchmark table | high |
| NIST | 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.