Add nosuid Option to /tmp
Mounts /tmp with the nosuid option so the kernel ignores set-UID/set-GID bits on binaries in that directory.
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
SUID and SGID executables run with the privileges of their owner (often root) rather than the calling user, so their presence must be tightly controlled. The nosuid option makes the kernel ignore the set-user-ID and set-group-ID bits on any binary under /tmp. Because /tmp is world-writable, an attacker could otherwise drop a SUID-root binary there and use it for privilege escalation; nosuid neutralises that path.
What Pavois checks
Pavois inspects the effective mount with mount('/tmp') and asserts that its resolved options include nosuid. It reads the live kernel mount table, the options actually enforced, instead of /etc/fstab, so it catches a partition remounted without the flag, an override by a systemd mount unit, or an fstab entry that never applied, which a file-based scanner would wrongly pass.
describe mount('/tmp') do
its('options') { should include 'nosuid' }
end
describe command("{ findmnt --fstab -no OPTIONS /tmp 2>/dev/null; grep -hsE '[[:space:]]/tmp[[:space:]]' /etc/fstab 2>/dev/null; systemctl show -p Options -- $(systemd-escape -p --suffix=mount /tmp 2>/dev/null) 2>/dev/null; } | grep -ow 'nosuid'") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run findmnt /tmp (or findmnt -no OPTIONS /tmp) and confirm nosuid is in the option list. Expected output contains nosuid, e.g. /tmp ... rw,nosuid,nodev,noexec,relatime.
Inspect & investigate
Mount state is queried live with findmnt /tmp or cat /proc/mounts, not from a log. Boot-time and remount events appear via journalctl -b | grep -i tmp or journalctl -u tmp.mount.
Remediation
No automated harden plan ships for this rule yet, so it must be applied manually: add nosuid to the /tmp entry's options in /etc/fstab (or to the relevant systemd mount unit), then mount -o remount /tmp, or reboot, and re-scan to confirm.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| device | tmpfs |
|---|---|
| fstype | tmpfs |
| mount_point | /tmp |
| option | nosuid |
| resource | mount |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Functional impact is low: legitimate workloads do not place SUID/SGID binaries in /tmp. Precautions: confirm /tmp is a dedicated mount before applying; apply with mount -o remount /tmp. The risk is negligible compared with noexec, since only the privilege bits are stripped, normal (non-SUID) programs are unaffected.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R28 | direct | 2.0 | high |
| CIS | 1.1.2.1.3 | direct | per OS, see the benchmark table | high |
| NIST | AC-6, AC-6(1), CM-6(a), CM-7(a), CM-7(b), MP-7 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
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.