Verify permissions on System Login Banner
Ensures /etc/issue is not writable by group or other and carries no executable, setuid, setgid or sticky bits (expected mode 0644 root:root).
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
/etc/issue is the pre-login banner shown on local terminals, typically a legally approved use-notification message. It is meant to be world-readable, but it must not be writable by group or other: an attacker who can edit it could remove the legal warning (weakening prosecution) or inject misleading text to aid social-engineering. Keeping write access to root ensures the displayed notice is authentic and consistent with policy.
What Pavois checks
Pavois reads the real inode permissions of /etc/issue with the InSpec file resource (a stat), under only_if. World-read is allowed (the banner is displayed to anyone at the login prompt), but group-write, other-write, and any execute/setuid/setgid/sticky bit fail, effectively requiring 0644 root:root. Checking the live mode catches a chmod slip or a deployment that loosened the file, which a packaged-default assumption would miss.
only_if { file('/etc/issue').exist? }
describe file('/etc/issue') 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/issue. Expected output is mode 644 owned by root root, i.e. 644 root root. Any group/other write or special bit fails the rule.
Inspect & investigate
There is no service log for a static banner file; verify it directly with stat /etc/issue and view the banner with cat /etc/issue. If auditd watches /etc/issue, edits appear in /var/log/audit/audit.log. The banner itself is rendered by getty/agetty at the login prompt.
Remediation
No automated remediation is defined, so apply it manually: chmod u-x,g-wx,o-wx /etc/issue && chown root:root /etc/issue (target 0644 root:root). No service restart is needed; the next login prompt reads the corrected file.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| mode | 0644 |
|---|---|
| path | /etc/issue |
| resource | file |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Restoring 0644 root:root is very low-risk, this is the standard mode and the banner must stay world-readable to display. Do not remove world-read or the login prompt may show nothing. Keep the owner root. There is no lockout risk. Leaving the file writable by non-root lets an attacker strip the legal notice or plant misleading text before authentication.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 1.6.5, 1.7.5 | 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.