Verify permissions on Message of the Day Banner
Ensures /etc/motd is not writable, executable, setuid/setgid or sticky for group or other, so only root can alter the message-of-the-day banner.
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
Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable laws, directives, policies, regulations, standards and guidance. The /etc/motd banner is shown to users after they authenticate at the console or over SSH. If the file is group- or world-writable, any unprivileged user could rewrite it to mislead administrators or suppress the legal notice; setuid/setgid/executable bits serve no purpose on a text file and only enlarge the attack surface. Restricting permissions ensures only root can modify the banner.
What Pavois checks
Pavois reads the live mode bits of /etc/motd on the target (executable/setuid/setgid/sticky/writable by group and other) rather than a documented baseline. Permissions live in the inode, so the audit reflects the effective on-disk state with no include or drop-in to mislead it. The only_if guard skips the control when the file is absent.
only_if { file('/etc/motd').exist? }
describe file('/etc/motd') do
it { should_not be_executable.by('owner') }
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_sticky }
endHow to verify it is applied
Run stat -c '%A %U %G' /etc/motd. Expected: mode -rw-r--r-- (0644) owned by root root, with no write bit for group/other and no s/t bits. Quick check: find /etc/motd -perm /0133 must return nothing.
Inspect & investigate
File-permission changes are not logged by default. To detect tampering, watch the file with auditd: auditctl -w /etc/motd -p wa -k banner, then review events with grep 'key="banner"' /var/log/audit/audit.log. On systems using pam_motd/update-motd, the rendered banner may come from /etc/update-motd.d/; current ownership and mode are shown by stat /etc/motd.
Remediation
No automated harden plan ships for this rule yet, so it must be applied manually: chown root:root /etc/motd && chmod 0644 /etc/motd. This clears any group/other write and any setuid/setgid/sticky bits while keeping the banner world-readable.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0644 |
|---|---|
| path | /etc/motd |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if left mis-set: a non-root user can rewrite the post-login banner seen by every user and administrator, removing legal text or planting a misleading message. Applying the fix is low-risk: 0644 root:root is the conventional mode. Precaution: keep the read bit for other so the MOTD still displays; on Debian/Ubuntu the dynamic MOTD generated under /etc/update-motd.d/ is a separate concern and its scripts must remain root-owned.
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.