Add noexec Option to /tmp
Mounts /tmp with the noexec option so the kernel refuses to execute any binary located 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
Executing binaries from world-writable directories such as /tmp is never required in normal operation. The noexec option makes the kernel refuse to run any program stored under /tmp, removing a favourite staging ground for attackers: dropped malware, exploit payloads and downloaded toolkits are commonly written to /tmp and run from there. Without noexec, any unprivileged user or compromised service can execute arbitrary code from this directory.
What Pavois checks
Pavois inspects the effective mount with mount('/tmp') and asserts that its resolved options include noexec. It reads the live kernel mount table, what is actually enforced, rather than /etc/fstab, so it catches a partition remounted without the flag, an option overridden by a systemd mount unit, or an fstab entry that never took effect, all of which a file-based scanner would report as compliant.
describe mount('/tmp') do
its('options') { should include 'noexec' }
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 'noexec'") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run findmnt /tmp (or findmnt -no OPTIONS /tmp) and confirm noexec is in the option list. Expected output contains noexec, e.g. /tmp ... rw,nosuid,nodev,noexec,relatime. A practical functional test: cp /bin/true /tmp/x && /tmp/x should fail with Permission denied.
Inspect & investigate
Mount state is queried live with findmnt /tmp or cat /proc/mounts, not from a log file. Boot-time and remount events appear via journalctl -b | grep -i tmp or journalctl -u tmp.mount. Blocked execution attempts surface as Permission denied in the calling program's own logs (and, if auditd is configured, in /var/log/audit/audit.log).
Remediation
No automated harden plan ships for this rule yet, so it must be applied manually: add noexec 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 | noexec |
| resource | mount |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Things that can break: some package managers and installers (e.g. building software, certain pip/dnf plugins, application self-updaters) stage and run helper scripts from /tmp and will fail under noexec. Java and some installers honour $TMPDIR, point them elsewhere or grant a temporary exception during maintenance. Precautions: verify /tmp is a dedicated mount first; test critical workflows (package upgrades, app deployments) after applying; if a tool needs execute temporarily, use a separate exec-capable scratch directory rather than removing noexec from /tmp.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R28 | direct | 2.0 | high |
| CIS | 1.1.2.1.4 | 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.