Verify permissions of log files
Ensures no file under /var/log is group-writable/executable or readable/writable/executable by others (no bit in mask /037).
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
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
Log files record system configuration, authentication events and application activity. If they are world-readable, an unprivileged user can mine them for usernames, internal hostnames, paths and error messages that aid an attack; if they are group- or world-writable, an attacker can tamper with or wipe entries to destroy forensic evidence. Restricting /var/log to owner (and the dedicated log group) keeps error messages useful for defenders without revealing information that adversaries could exploit.
What Pavois checks
Pavois runs find /var/log -type f -perm /037 and expects empty output. The mask /037 matches any file that has any of: group-write, group-execute, or any of other-read/write/execute. Empty output means every log file is at most 0640 (owner rw, group r, others none). Scanning the live inodes catches files created at runtime by daemons and logrotate, which a static config audit would miss.
describe command('timeout 90 find /var/log -type f -perm /037 ! -group utmp ! -group systemd-journal 2>/dev/null') do
its('exit_status') { should_not cmp 124 } # timeout killed the scan: no evidence, not a pass
its('stdout.strip') { should eq '' }
endHow to verify it is applied
Run sudo find /var/log -type f -perm /037 2>/dev/null. Expected output: empty. Each path returned is a log file with too-permissive mode; inspect it with ls -l <path>.
Inspect & investigate
List offending files and their modes with find /var/log -type f -perm /037 -ls. After remediation, find /var/log -type f -perm /037 should print nothing. Watch logrotate runs in /var/log/syslog if files regain bad modes (a custom create directive in /etc/logrotate.d/*).
Remediation
Pavois's harden plan runs an exec resource named fix-varlog-perms that finds every offending file and applies chmod g-wx,o-rwx to it, stripping group write/execute and all other-access bits while leaving owner and group-read intact. A not_if guard skips the action when no file matches, so it is idempotent. Applied with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | if [ -f /etc/sysstat/sysstat ]; then sed -ri 's/^[[:space:]]*UMASK=.*/UMASK=0027/' /etc/sysstat/sysstat; grep -q '^UMASK=' /etc/sysstat/sysstat || echo UMASK=0027 >> /etc/sysstat/sysstat; fi; for u in apt-daily apt-daily-upgrade unattended-upgrades sysstat-collect sysstat-summary; do systemctl list-unit-files ${u}.service --no-legend 2>/dev/null | grep -q . || continue; mkdir -p /etc/systemd/system/${u}.service.d; printf '[Service]\nUMask=0027\n' > /etc/systemd/system/${u}.service.d/pavois-umask.conf; done; systemctl daemon-reload; find /var/log -type f -perm /037 ! -group utmp ! -group systemd-journal -exec chmod g-wx,o-rwx {} + 2>/dev/null; true |
|---|---|
| name | fix-varlog-perms |
| not_if | test -z "$(find /var/log -type f -perm /037 ! -group utmp ! -group systemd-journal 2>/dev/null | head -1)" && { ! test -f /etc/sysstat/sysstat || grep -q '^UMASK=0027' /etc/sysstat/sysstat; } |
| reason | the chmod alone does not hold: the files are RE-CREATED by the services that write them. Two sources must be fixed, not one: the systemd units (UMask=0027 drop-in, for apt-daily / unattended-upgrades / dnf-makecache) AND sysstat's own UMASK knob in /etc/sysstat/sysstat, which overrides the unit's umask. The chmod only repairs what already exists. |
| resource | exec |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Tightening permissions is low-risk because owner and the log group retain access. However, an application that runs unprivileged and reads its own log under /var/log via other-read could lose visibility after o-rwx is removed; confirm such services run as the file owner or are in the log group. Removing group-write can break a non-standard logging setup that has multiple writers sharing a group, verify your rsyslog/journald topology before applying broadly.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R71 | direct | 2.0 | high |
| CIS | 10.3.1, 6.1.4.1, 6.2.4.1, 6.2.6.1, 6.2.3.1 | direct | per OS, see the benchmark table | high |
| NIST | SI-11(a), SI-11(b), SI-11 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 10.3.1 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-24-700120 | direct | per OS STIG release | 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.