Ensure /opt Located On Separate Partition
Verifies that /opt is mounted on its own partition so restrictive options can be applied to third-party software.
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
/opt holds additional software, often installed outside the package manager. Putting it on a separate partition lets you apply restrictions such as nosuid and nodev to that third-party code, isolates it from the root filesystem, and prevents an over-grown /opt from filling /.
What Pavois checks
Pavois uses the InSpec mount('/opt') resource, reading the effective mount table (/proc/self/mountinfo) rather than /etc/fstab. It reflects what the kernel has actually mounted, distinguishing a real separate mount from an fstab entry that never took effect.
describe mount('/opt') do
it { should be_mounted }
endHow to verify it is applied
Run:
findmnt /opt
Expected: a row showing /opt on its own device/partition. No output means /opt is part of the root filesystem and the rule fails.
Inspect & investigate
Check the live mount with findmnt /opt or mount | grep ' /opt '; the persistent entry is in /etc/fstab. Mount-unit events appear via journalctl -u opt.mount and kernel mount activity via journalctl -k.
Remediation
No automated harden plan ships for this rule, relocating /opt to its own partition is a manual disk-layout change, best done at install time. On an existing host it requires a new filesystem, copying data with rsync -aXS, an /etc/fstab entry and a remount; Pavois will not perform this automatically.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # /opt should be its OWN filesystem (isolation + mount options). This needs (re)partitioning , # offline disk/LVM work, not a safe runtime change. findmnt /opt >/dev/null 2>&1 && echo '/opt is already a mount point' || echo '/opt is NOT separate' # Then: dedicate an LVM volume / disk to /opt and add it to /etc/fstab. |
|---|---|
| reason | a separate /opt 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
Moving /opt on a live system can disrupt software installed there (paths, running services), and nosuid/noexec may break vendor apps that ship setuid helpers or run scripts from /opt. Precautions: back up /opt, stop affected services during the migration, verify the new mount before removing old data, and test the third-party software before tightening mount options. The control only requires the mount to exist.
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.