Ensure /dev/shm is configured
Verifies that /dev/shm is explicitly mounted so hardening options (nodev, nosuid, noexec) can be enforced on shared memory.
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
/dev/shm is a world-writable shared-memory tmpfs where any user can drop and run files, much like /tmp. Mounting it explicitly lets you apply nodev, nosuid and noexec, making it useless for installing executable code, blocking hardlink races against setuid binaries, and reducing it as a staging ground for attacks.
What Pavois checks
Pavois uses the InSpec mount('/dev/shm') resource, reading the effective mount table (/proc/self/mountinfo) rather than /etc/fstab. This shows the tmpfs as the kernel actually mounted it, including options applied at runtime or via systemd, which a file-only parse of fstab could not confirm.
describe mount('/dev/shm') do
it { should be_mounted }
endHow to verify it is applied
Run:
findmnt /dev/shm
Expected: a tmpfs mounted at /dev/shm, ideally with nodev,nosuid,noexec in the options column. No output means /dev/shm is not configured as its own mount.
Inspect & investigate
Check the live mount with findmnt /dev/shm or mount | grep /dev/shm; persistent config sits in /etc/fstab (or a systemd dev-shm.mount unit). Mount changes are visible via journalctl -u dev-shm.mount and journalctl -k.
Remediation
No automated harden plan ships for this rule, so apply it manually: add a tmpfs /dev/shm tmpfs defaults,nodev,nosuid,noexec 0 0 entry to /etc/fstab, then mount -o remount /dev/shm. Unlike the other partitions, /dev/shm is a tmpfs and needs no disk repartitioning.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | # /dev/shm should be its OWN filesystem (isolation + mount options). This needs (re)partitioning , # offline disk/LVM work, not a safe runtime change. findmnt /dev/shm >/dev/null 2>&1 && echo '/dev/shm is already a mount point' || echo '/dev/shm is NOT separate' # Then: dedicate an LVM volume / disk to /dev/shm and add it to /etc/fstab. # /dev/shm can instead be a tmpfs, add: tmpfs /dev/shm tmpfs defaults,rw,nosuid,nodev,noexec 0 0 |
|---|---|
| reason | a separate /dev/shm 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
Adding noexec to /dev/shm is usually safe, but a few applications (some installers, certain runtimes, or sandboxes) execute code from shared memory and may break. Precautions: test critical services after the remount, and if something fails, identify the culprit before loosening the option rather than dropping noexec blindly. The remount is online and reversible.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 1.1.2.2.1 | direct | per OS, see the benchmark table | 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.