Verify ownership of Message of the Day Banner
Ensures /etc/motd (the post-login Message of the Day) is owned by root (UID 0).
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
The /etc/motd file holds the Message of the Day shown after a user authenticates. If a non-root account owns it, that user can alter or replace the post-login notice, injecting misleading or malicious content seen by every operator. Setting root (UID 0) as the owner ensures only privileged users can change the banner, keeping the notification consistent with applicable laws, policies and standards.
What Pavois checks
Pavois inspects the live filesystem with the InSpec file('/etc/motd') resource and asserts uid == 0, guarded by only_if so the test is skipped when the file is absent. Reading the actual inode owner (rather than trusting a deployment template) reflects the effective state on disk, catching any post-deployment chown. Note on Debian/Ubuntu the MOTD is often assembled dynamically from /etc/update-motd.d/ scripts, but the static /etc/motd must still be root-owned.
only_if { file('/etc/motd').exist? }
describe file('/etc/motd') do
its('uid') { should eq 0 }
endHow to verify it is applied
Run stat -c '%U %u %n' /etc/motd. Expected output: root 0 /etc/motd. The numeric 0 confirms the rule regardless of name-service mapping.
Inspect & investigate
Ownership changes are not logged by default. With the audit framework, add auditctl -w /etc/motd -p wa -k banner then inspect /var/log/audit/audit.log (filter grep 'key="banner"'). The MOTD is rendered at login by PAM (pam_motd), so display events appear in /var/log/auth.log / journalctl.
Remediation
No automated remediation is shipped for this rule. Apply it manually with chown root /etc/motd (run as root or via sudo); the file should remain group root and mode 0644.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| owner | root |
|---|---|
| path | /etc/motd |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
A wrong owner lets a non-privileged user rewrite the message every authenticated user sees. Risk of applying: none in practice, /etc/motd is a static text file with no service dependency, so chown root does not affect logins. As a precaution, keep it world-readable (0644) so the message still renders.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 1.6.4, 1.7.4 | 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.