Verify User Who Owns /var/log/waagent.log File
Ensures the Azure Guest Agent log /var/log/waagent is owned by the syslog user.
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
/var/log/waagent.log is written by the Azure Linux Guest Agent and records provisioning, extension installs and agent activity, data that can reveal the host's cloud configuration and, occasionally, sensitive bootstrap details. If it is not owned by syslog, an unprivileged user could read this operational intelligence or tamper with the log to hide how the VM was configured or compromised.
What Pavois checks
Pavois checks that the owner of /var/log/waagent is syslog, only when the file exists (only_if), since waagent is present only on Azure VMs. It reads the live owner (stat) on the target rather than a default, so a chown from the agent, rotation or a deployment script is caught as the effective on-disk state.
only_if { file('/var/log/waagent.log').exist? }
describe command("stat -c %U /var/log/waagent.log 2>/dev/null") do
its('stdout.strip') { should be_in ['root', 'syslog'] }
endHow to verify it is applied
Confirm the owner with:
stat -c '%U' /var/log/waagent.log
Expected output is syslog.
Inspect & investigate
This file is itself the agent log. Inspect ownership and content:
ls -l /var/log/waagent.log
tail -n 50 /var/log/waagent.log
The agent status is shown by systemctl status walinuxagent (or waagent). Ownership changes can be tracked with grep 'waagent' /var/log/audit/audit.log if auditd watches are configured.
Remediation
Pavois's harden plan uses a file resource to set the owner of /var/log/waagent to syslog. Run pavois harden apply to enforce it, the Chef engine performs the equivalent of chown syslog /var/log/waagent, leaving content and group untouched.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | chown root /var/log/waagent.log 2>/dev/null; true |
|---|---|
| name | log-owner-var-log-waagent.log |
| not_if | stat -c %U /var/log/waagent.log 2>/dev/null | grep -qxE 'root|syslog' |
| path | /var/log/waagent.log |
| resource | exec |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Consequences if misconfigured: wrong ownership exposes Azure provisioning details and lets a non-logging process tamper with the agent log, hiding configuration or compromise of the VM.
Precautions before applying: the change is low-risk. Note that the Azure Guest Agent (waagent) typically runs and writes its log as root, not syslog; on a genuine Azure VM, forcing the owner to syslog only matches the benchmark when rsyslog is configured to own the file, verify the agent can still write after applying so provisioning is not disrupted. The only_if guard skips non-Azure hosts entirely.
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.