Ensure /srv Located On Separate Partition
Verifies that /srv is mounted on its own partition so served data is isolated and restrictive mount options can apply.
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
/srv holds data served by the host (web roots, FTP, network shares). Mounting it on its own partition lets you apply restrictive options such as nodev and nosuid, and ensures that user- or service-generated content cannot trivially fill the root or log/audit filesystems and cause a denial of service.
What Pavois checks
Pavois uses the InSpec mount('/srv') resource, reading the effective mount table (/proc/self/mountinfo) rather than /etc/fstab. It reports what the kernel has actually mounted, distinguishing a genuine separate mount from an fstab entry that never took effect.
describe mount('/srv') do
it { should be_mounted }
endHow to verify it is applied
Run:
findmnt /srv
Expected: a row showing /srv on its own device/partition. No output means /srv is part of the root filesystem and the rule fails.
Inspect & investigate
Check the live mount with findmnt /srv or mount | grep ' /srv '; the persistent entry is in /etc/fstab. Mount-unit events appear via journalctl -u srv.mount and kernel mount activity via journalctl -k.
Remediation
No automated harden plan ships for this rule, relocating /srv to its own partition is a manual disk-layout change, best done at install time. Retrofitting requires a new filesystem, copying served 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 | # /srv should be its OWN filesystem (isolation + mount options). This needs (re)partitioning , # offline disk/LVM work, not a safe runtime change. findmnt /srv >/dev/null 2>&1 && echo '/srv is already a mount point' || echo '/srv is NOT separate' # Then: dedicate an LVM volume / disk to /srv and add it to /etc/fstab. |
|---|---|
| reason | a separate /srv 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 /srv on a running server can interrupt the services that read from it (web, FTP, file shares), and noexec/nosuid may break apps that execute helpers from served paths. Precautions: schedule a maintenance window, back up /srv, stop the serving services during the copy, verify the new mount before deleting old data, and restart and test services afterward. 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.