Ensure /usr Located On Separate Partition
Mounts /usr on a dedicated filesystem so the system binaries can be isolated and protected with restrictive mount options.
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 /usr directory holds system software, utilities and shared files. Hosting it on its own partition lets you cap its size and, above all, enforce restrictive mount options. Because /usr is largely read-only at runtime, it is a prime candidate for ro or nodev mounts that block device-node tricks and unexpected writes to the binaries an attacker would love to tamper with.
What Pavois checks
Pavois checks the effective mount table via the mount('/usr') resource (backed by findmnt / /proc/self/mountinfo), not /etc/fstab. This matters because fstab describes intent: a line can be present yet the mount may have failed at boot, been overridden by a systemd .mount unit, or bind-mounted elsewhere. Auditing the live kernel mount state confirms /usr is actually a separate mounted filesystem right now.
describe mount('/usr') do
it { should be_mounted }
endHow to verify it is applied
Run findmnt /usr (or mount | grep ' /usr '). It must return a line showing /usr as its own source device/filesystem. No output means /usr is part of the root filesystem and the rule fails.
Inspect & investigate
Inspect the live mount state with findmnt /usr and cat /proc/mounts | grep /usr. Boot-time mount failures are visible via journalctl -b | grep -i usr and the status of the related systemd unit with systemctl status usr.mount.
Remediation
There is no automated harden plan for this rule: repartitioning a live system is destructive and cannot be done safely in place. It must be applied manually, normally at install time, by allocating a dedicated partition (or LVM volume) for /usr and adding its entry to /etc/fstab.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # /usr should be its OWN filesystem (isolation + mount options). This needs (re)partitioning , # offline disk/LVM work, not a safe runtime change. findmnt /usr >/dev/null 2>&1 && echo '/usr is already a mount point' || echo '/usr is NOT separate' # Then: dedicate an LVM volume / disk to /usr and add it to /etc/fstab. |
|---|---|
| reason | a separate /usr 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
If /usr is not separated, you lose the ability to mount it ro/nodev and a runaway write elsewhere could in theory affect it. Precautions before migrating: mounting /usr ro can break package upgrades and any tooling that writes under /usr; an early-boot environment (initramfs) must be able to mount /usr before systemd needs it, otherwise the system fails to boot. Repartitioning risks data loss, take a full backup and have console/rescue access before touching the layout, and prefer doing this at install time.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R28 | direct | 2.0 | high |
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.