Verify Permissions on /var/log Directory
Ensure the /var/log directory is not group/other-writable and carries no setuid, setgid or sticky bit, so only privileged accounts can alter the log tree.
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
/var/log is the root of the system log tree. If it is group- or other-writable, any unprivileged user can create, rename or delete log files, tampering with the audit trail to hide an intrusion. A stray setuid/setgid bit on the directory, or a missing-but-then-misused sticky bit, can also enable privilege confusion. Locking the directory down preserves the integrity and non-repudiation of the logs.
What Pavois checks
Pavois reads the live inode of /var/log and asserts it is not setuid, setgid, sticky, nor writable by group or other. Inspecting the actual filesystem object (rather than a packaging manifest or a config file) catches drift introduced by a careless chmod, a restored backup or a misbehaving package, the effective permission is what an attacker actually sees.
only_if { file('/var/log').exist? }
describe file('/var/log') do
it { should_not be_setuid }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_writable.by('other') }
it { should_not be_sticky }
endHow to verify it is applied
Run stat -c '%A %U:%G' /var/log. Expect a mode such as drwxr-xr-x (no write for group/other, no s or t bit) owned by root:root. The permission string must not contain a group/other w, nor s/S/t/T.
Inspect & investigate
Permission changes on the directory are visible through the audit subsystem if a watch is set: auditctl -w /var/log -p wa then review /var/log/audit/audit.log. The current state is always readable with ls -ld /var/log and stat /var/log.
Remediation
No automated harden plan ships for this rule, so it must be applied manually: chown root:root /var/log and chmod g-w,o-w,u-s,g-s,-t /var/log (typically chmod 0755 /var/log).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0755 |
|---|---|
| path | /var/log |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A world-writable /var/log lets attackers erase evidence or fill the disk; an unexpected setgid bit can leak the adm/syslog group to new files. Precautions: keep the directory at least group/other-readable and traversable (0755), over-tightening to 0700 will break journald, rsyslog, logrotate and many service log writers that run as non-root, and can hide logs from monitoring agents. Verify ownership stays root:root and that no service relied on a special bit before removing it.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| DISA STIG | UBTU-22-232025, 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.