Ensure Sudo Logfile Exists - sudo logfile
Declare a dedicated sudo log file (Defaults logfile="/var/log/sudo.log") so that every privileged command is written to a file of its own, independent of syslog. Without it, the sudo trail is just one stream among many inside auth.log or secure, easily drowned in noise or carried away by that stream's rotation.
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
A sudo log file simplifies auditing of sudo commands.
What Pavois checks
Pavois runs grep -rqE '^[^#]*Defaults[^#]*\blogfile\b' /etc/sudoers /etc/sudoers.d/ and expects ok. The grep is recursive over the drop-in directory, so a Defaults logfile placed in any file pulled in by @includedir /etc/sudoers.d counts, exactly as sudo itself would read it, and the ^[^#]* anchor rejects commented-out lines. Unlike SSH, sudo offers no unprivileged equivalent of sshd -T: the policy is re-parsed at every invocation, which is why this control is typed persistent-config and not effective-runtime.
describe command('grep -rqE \'^[^#]*Defaults[^#]*\blogfile\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.*logfile' /etc/sudoers /etc/sudoers.d/. Expected output:
/etc/sudoers.d/99-pavois-logfile:Defaults logfile="/var/log/sudo.log"
Then prove it end to end: run any sudo command and read the last entry with sudo tail -1 /var/log/sudo.log. Confirm the whole sudoers set still parses with sudo visudo -c.
Inspect & investigate
Once the rule is applied, every sudo invocation lands in /var/log/sudo.log:
Jul 14 10:12:03 : alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx
The logfile destination is additive: sudo keeps writing to syslog as well (/var/log/auth.log on Debian/Ubuntu, /var/log/secure on RHEL, journalctl -t sudo), so an existing syslog-based collection pipeline is not disturbed.
Remediation
The Pavois harden plan uses the file resource to create /etc/sudoers.d/99-pavois-logfile, owned root:root, mode 0440, holding the single line Defaults logfile="/var/log/sudo.log". The file is validated with visudo -cf <file> before it is kept, so a syntax error can never reach the live sudoers set. There is no service to reload: sudo re-reads its policy at the next invocation and creates the log file on first use.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| content | Defaults logfile="/var/log/sudo.log" |
|---|---|
| group | root |
| mode | 0440 |
| owner | root |
| path | /etc/sudoers.d/99-pavois-logfile |
| 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
Without a dedicated file, the record of who ran what as root exists only inside the general authentication stream, where it competes with SSH and PAM noise and inherits that stream's retention. Two precautions when applying. First, any malformed file in /etc/sudoers.d/ breaks sudo for everyone, which is why the plan gates the write behind visudo -cf and sets mode 0440 (sudo ignores files writable by group or others); keep a root session open while sudoers changes. Second, /var/log/sudo.log is not covered by any default logrotate rule: on a busy host it grows without bound, so add a logrotate snippet for it and treat its retention as audit data, since it holds the privileged-command history.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 5.2.3 | direct | per OS, see the benchmark table | high |
| PCI DSS | 2.2.6 | supporting | 4.0.1 | 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.