Record Events When Privileged Executables Are Run
Enforces an auditd rule (key setuid) that records every execution of a privileged setuid/setgid executable.
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/SGID binaries run with the privileges of their owner (often root) regardless of who launches them, which makes them a favourite vector for privilege escalation. Misuse of these privileged functions, by careless authorized users or by an attacker on a compromised account, is a serious, ongoing concern with potentially severe impact. Auditing every execution of a privileged (setuid) executable is a primary way to detect such misuse and insider/advanced-persistent-threat activity and to establish accountability for elevated actions.
What Pavois checks
Pavois runs auditctl -l and checks a rule with the key setuid is loaded. Reading the live kernel ruleset beats parsing /etc/audit/rules.d/*.rules: a rule on disk that was never loaded (no augenrules --load, syntax error, reload failure) would make a file scanner falsely pass. auditctl -l reflects what the kernel audits now.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)setuid\b/) }
endHow to verify it is applied
Run auditctl -l | grep -E '(-k |key=)setuid' (as root). Expected output is the syscall rules tracking setuid execution, for example:
-a always,exit -F arch=b64 -C euid=0 -F auid>=1000 -F auid!=unset -S execve -k setuid-a always,exit -F arch=b32 -C euid=0 -F auid>=1000 -F auid!=unset -S execve -k setuid
No output means the rules are not loaded.
Inspect & investigate
Events go to /var/log/audit/audit.log. After running a setuid binary, find the record with grep 'key="setuid"' /var/log/audit/audit.log (grep the raw log; ausearch can falsely report no matches). The record shows the auid, the effective uid, the executed program and the timestamp.
Remediation
pavois harden apply uses the audit_ruleset resource to add the missing setuid syscall rules to a Pavois-managed drop-in in /etc/audit/rules.d/ and load them. Because the audit subsystem is locked once running, the change is fully effective only after a reboot (reboot_required: true).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| reboot_required | true |
|---|---|
| resource | audit_ruleset |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
These are passive syscall watches, they never block setuid execution, so passwd, sudo, mount and other privileged tools keep working; they only add records to /var/log/audit/audit.log. Precautions:
- The rule fires on every privileged
execveby a normal user, so hosts where users frequently run setuid tools can produce significant audit volume, ensure/var/log/audithas space and rotation, and watchauditd's backlog limit. - If the ruleset is immutable (
-e 2), the rule can only be added after a reboot. - Confirm the rule parsed with
augenrules --loadand re-checkauditctl -l.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| NIST | AC-6(9), AU-12(3), AU-7(a), AU-7(b), AU-8(b), CM-5(1) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 10.2.1.2 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-654230, UBTU-24-200580 | direct | per OS STIG release | high |
| CIS | 10.2.1.2 | 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.