Ensure /boot Located On Separate Partition
Verifies that /boot is mounted on its own partition so restrictive mount options can protect the kernel and bootloader.
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 /boot partition holds the kernel, initramfs and bootloader files. Mounting it separately lets you apply restrictive mount options (nodev, nosuid, noexec, and read-only outside upgrades), limiting tampering with the boot chain, and keeps the boot files isolated from a full root filesystem.
What Pavois checks
Pavois uses the InSpec mount('/boot') resource, which reads the effective mount table (/proc/self/mountinfo) rather than parsing /etc/fstab. This reflects what the running kernel has actually mounted, catching mounts added at runtime or fstab entries that never took effect, which a file-only check would report incorrectly.
describe mount('/boot') do
it { should be_mounted }
endHow to verify it is applied
Run:
findmnt /boot
Expected: a row showing /boot as its own mounted source (a distinct device/partition). If findmnt /boot returns nothing, /boot is part of the root filesystem and the rule fails.
Inspect & investigate
Inspect mounts with findmnt /boot or mount | grep ' /boot '; the persistent definition is in /etc/fstab. Mount/unmount events appear in the journal via journalctl -k (kernel) and unit logs journalctl -u boot.mount.
Remediation
No automated harden plan ships for this rule, splitting /boot onto its own partition is a manual disk-layout change, ideally done at install time. On an existing system it requires repartitioning, copying boot files, adding an /etc/fstab entry and updating the bootloader; Pavois cannot perform this safely online.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # /boot should be its OWN filesystem (isolation + mount options). This needs (re)partitioning , # offline disk/LVM work, not a safe runtime change. findmnt /boot >/dev/null 2>&1 && echo '/boot is already a mount point' || echo '/boot is NOT separate' # Then: dedicate an LVM volume / disk to /boot and add it to /etc/fstab. |
|---|---|
| reason | a separate /boot 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
Repartitioning /boot on a live system is high-risk: a mistake in the bootloader or /etc/fstab can leave the machine unbootable. Precautions: plan this at install time; if retrofitting, take a full backup and console/snapshot access, validate update-grub/grub2-mkconfig output, and reboot-test before relying on it. The control passing only requires the mount to exist, it does not, by itself, break anything.
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.