Add nosuid Option to /var
Mount /var with the nosuid option so SUID/SGID bits on files there are ignored by the kernel.
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 elevated privileges and must be tightly controlled. Mounting /var with nosuid prevents the kernel from honoring the SUID/SGID bits on any file there, so an attacker who plants a SUID-root binary in a writable /var subtree cannot use it to escalate privileges.
What Pavois checks
Pavois reads the effective mount options via mount('/var'), reflecting the kernel's live filesystem state. This catches options set by remounts, systemd mount units or fstab drop-ins that a scanner parsing /etc/fstab alone would miss.
describe mount('/var') do
its('options') { should include 'nosuid' }
end
describe command("{ findmnt --fstab -no OPTIONS /var 2>/dev/null; grep -hsE '[[:space:]]/var[[:space:]]' /etc/fstab 2>/dev/null; systemctl show -p Options -- $(systemd-escape -p --suffix=mount /var 2>/dev/null) 2>/dev/null; } | grep -ow 'nosuid'") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run findmnt -no OPTIONS /var and confirm nosuid is present. Example output: rw,nosuid,nodev,noexec,relatime.
Inspect & investigate
Inspect mount state with findmnt /var and mount | grep ' /var '. Kernel mount events appear in journalctl -k / dmesg. To find SUID files that would be neutralized, run find /var -perm -4000 -o -perm -2000.
Remediation
There is no automated harden plan for this rule, because /var must be a separate partition to carry mount options. Apply it manually: ensure /var is its own filesystem, add nosuid to its /etc/fstab entry (or systemd mount unit), then mount -o remount /var and reboot to confirm persistence.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | awk -v m=/var -v o=nosuid '$0!~/^[[:space:]]*#/&&$2==m{n=split($4,a,",");h=0;for(i=1;i<=n;i++)if(a[i]==o)h=1;if(!h)$4=$4","o}{print}' /etc/fstab >/etc/.fstab.pav && cat /etc/.fstab.pav >/etc/fstab && rm -f /etc/.fstab.pav; mountpoint -q /var && mount -o remount,nosuid /var || true |
|---|---|
| name | mount-var-nosuid |
| not_if | awk -v m=/var '$2==m&&$0!~/^[[:space:]]*#/{print $4}' /etc/fstab | tr , '\n' | grep -qx nosuid |
| resource | exec |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
What can break: legitimate SUID/SGID binaries stored under /var (rare, but some third-party software places helpers there) will lose their elevated privileges and may fail. Precautions: before enforcing, list affected files with find /var -perm -4000 -o -perm -2000 and relocate any needed binary to a proper path (e.g. /usr/bin). If /var is not already a separate partition, this is a planned repartitioning task with data migration, not a live remount.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R28 | direct | 2.0 | high |
| CIS | 1.1.2.4.3 | 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.