Ensure /home Located On Separate Partition
Verifies that /home is mounted on its own partition so restrictive mount options apply and users cannot fill the root or log filesystems.
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 /home on its own partition lets you apply restrictive options such as nodev and nosuid to user-owned data, and prevents users from filling the root or log/audit filesystems by writing large files in their home directories, a simple but effective denial-of-service safeguard.
What Pavois checks
Pavois uses the InSpec mount('/home') resource, which reads the effective mount table (/proc/self/mountinfo) instead of parsing /etc/fstab. It reports what the kernel has actually mounted, catching runtime mounts or fstab entries that failed to mount, distinctions a file-only check cannot make.
describe mount('/home') do
it { should be_mounted }
endHow to verify it is applied
Run:
findmnt /home
Expected: a row showing /home backed by its own device/partition. No output means /home lives on the root filesystem and the rule fails.
Inspect & investigate
Check the live mount with findmnt /home or mount | grep ' /home '; the persistent entry is in /etc/fstab. Mount-unit events appear via journalctl -u home.mount and kernel mount activity via journalctl -k.
Remediation
No automated harden plan ships for this rule, moving /home to its own partition is a manual disk-layout change, ideally at install time. Retrofitting means creating a new filesystem, copying user data with rsync -aXS, adding an /etc/fstab entry and remounting; Pavois will not perform this destructive operation automatically.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # /home should be its OWN filesystem (isolation + mount options). This needs (re)partitioning , # offline disk/LVM work, not a safe runtime change. findmnt /home >/dev/null 2>&1 && echo '/home is already a mount point' || echo '/home is NOT separate' # Then: dedicate an LVM volume / disk to /home and add it to /etc/fstab. |
|---|---|
| reason | a separate /home 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
Carving out /home on a live system risks data loss if user files are copied or remounted incorrectly, and nosuid/nodev could affect unusual home-based setups. Precautions: back up /home first, do the copy with users logged out (single-user mode or a maintenance window), verify the new mount before deleting the old data, and confirm logins and home access afterward. The control merely requires the mount to exist.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R28 | direct | 2.0 | high |
| CIS | 1.1.2.3.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.