Verify Permissions on /var/log/waagent.log(.*) Files
Ensure the Azure Linux Guest Agent log /var/log/waagent carries no execute, setuid, setgid or sticky bit and is not group/other-writable, so its records cannot be altered.
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/waagent.log records events from the Azure Linux Guest Agent, used for provisioning and troubleshooting cloud instances. It can expose cloud metadata, extension activity and VM identity details. If the file is group/other-writable an attacker can inject misleading entries or erase evidence of tampering with the agent. Restricting it keeps cloud-platform diagnostics trustworthy.
What Pavois checks
Pavois reads the live inode of /var/log/waagent and asserts no execute, setuid, setgid or sticky bit and no group/other write. Reading the real filesystem object catches drift that a packaging or config check would miss, the effective mode is what governs access at runtime.
['/var/log/waagent.log'].each do |f|
next unless file(f).exist?
describe file(f) do
it { should_not be_writable.by('group') }
it { should_not be_readable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_executable.by('other') }
it { should_not be_setuid }
it { should_not be_setgid }
end
endHow to verify it is applied
Run stat -c '%A %U:%G' /var/log/waagent.log. Expect a mode like -rw-r----- root:adm (0640 or stricter) with no x, s, S, t, T, and no group/other write bit.
Inspect & investigate
This file is a log; inspect with tail -n 50 /var/log/waagent.log. The agent itself is a systemd service: systemctl status walinuxagent (or waagent) and journalctl -u walinuxagent. To detect permission tampering, add auditctl -w /var/log/waagent.log -p wa and review /var/log/audit/audit.log.
Remediation
No automated harden plan ships for this rule, so it must be applied manually: chown root:adm /var/log/waagent.log and chmod u-x,g-wx,o-wx,u-s,g-s,-t /var/log/waagent.log (commonly chmod 0640).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | for f in /var/log/waagent.log; do [ -e "$f" ] && chmod g-wx,o-rwx "$f"; done; true |
|---|---|
| name | fileperm-var-log-waagent-tighten |
| not_if | ! find /var/log/waagent.log -maxdepth 0 \( -perm /g=wx -o -perm /o=rwx \) 2>/dev/null | grep -q . |
| resource | exec |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A writable agent log can be poisoned or truncated, hampering cloud incident analysis. Precautions: this file only exists on Azure VMs running walinuxagent; the agent runs as root and recreates the file, so after re-permissioning confirm the agent still writes (systemctl restart walinuxagent then tail /var/log/waagent.log). The agent's own rotation may reset the mode, so verify periodically. Keep root:adm readable rather than 0600 if your monitoring reads it as the adm group.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 6.1.4.1, 6.2.2.1 | 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.