Ensure Privileged Escalated Commands Cannot Execute Other Commands - sudo NOEXEC
Enable the Defaults noexec option so commands run under sudo cannot spawn further sub-commands (e.g. a shell escape) via the C library exec functions.
Checked against the content of a persistent configuration file, the source of truth that survives reboots.
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
Many interactive programs (editors like vi, pagers like less, even awk or find -exec) can launch a sub-shell. When run via sudo, that sub-shell would inherit root privileges, giving the user a full root shell from a narrowly scoped privilege. noexec uses an LD_PRELOAD wrapper to neutralise the exec*() family, so privileged commands run but cannot escalate into arbitrary command execution, a classic sudo jailbreak.
What Pavois checks
Pavois greps the active sudoers tree, /etc/sudoers and every file under /etc/sudoers.d/, for an uncommented Defaults ... noexec. Because sudo assembles its policy from the main file plus all drop-ins, scanning the whole tree reflects the effective policy rather than a single file a later drop-in could override.
describe command('grep -rqE \'^[^#]*Defaults[^#]*\bnoexec\b\' /etc/sudoers /etc/sudoers.d/ 2>/dev/null && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run sudo grep -rE '^[^#]*Defaults.*noexec' /etc/sudoers /etc/sudoers.d/. A matching, uncommented line confirms the option is active. To test behaviour, sudo vi then :!sh should fail to spawn a shell when noexec is in force.
Inspect & investigate
sudo invocations are logged to /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL), and via journalctl -t sudo. A blocked exec attempt typically leaves the parent command in the sudo log while the sub-process never starts, helping correlate attempted shell escapes.
Remediation
Pavois's harden plan writes a file resource at /etc/sudoers.d/99-Pavois-noexec containing Defaults noexec, owned root:root with mode 0440, validated with visudo -cf before activation. Apply it with pavois harden apply. The dedicated drop-in keeps the change isolated and reversible.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| content | Defaults noexec |
|---|---|
| group | root |
| mode | 0440 |
| owner | root |
| path | /etc/sudoers.d/99-pavois-noexec |
| resource | file |
| verify | visudo -cf %{path} |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A blanket noexec will break legitimate sudo commands that must launch sub-processes, package managers, build tools, systemctl chains or admin scripts that call other binaries. Before applying, identify such commands and exempt them with a per-command NOEXEC:/EXEC: override (e.g. user ALL = EXEC: /usr/bin/apt) instead of dropping the global default. The drop-in is validated by visudo before activation, so it cannot corrupt sudoers; test critical admin workflows right after applying.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R39 | 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.