Verify permissions on System Login Banner for Remote Connections
Ensures /etc/issue.net is not writable, executable, setuid/setgid or sticky for group or other, so only root can alter the remote login 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/issue.net banner is presented to remote clients (e.g. SSH) before authentication. If the file is group- or world-writable, any unprivileged user could rewrite the banner to mislead users, suppress the legal notice, or inject a phishing message; setuid/setgid/executable bits have no legitimate purpose on a plain text file and only widen the attack surface. Restricting permissions ensures only root can modify the banner.
What Pavois checks
Pavois evaluates the live mode bits of /etc/issue.net on the target (executable/setuid/setgid/sticky/writable by group and other) rather than trusting a documented baseline. Permissions are part of the inode itself, so the audit reads the effective state on disk, there is no drop-in or include mechanism to mislead it. The only_if guard skips the control when the file is absent.
only_if { file('/etc/issue.net').exist? }
describe file('/etc/issue.net') 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.net. Expected: mode -rw-r--r-- (0644) owned by root root, with no write bit for group/other and no s/t bits. A quick check: find /etc/issue.net -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/issue.net -p wa -k banner, then review events with grep 'key="banner"' /var/log/audit/audit.log. Current ownership and mode are shown by stat /etc/issue.net.
Remediation
No automated harden plan ships for this rule yet, so it must be applied manually: chown root:root /etc/issue.net && chmod 0644 /etc/issue.net. 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/issue.net |
| 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 pre-authentication remote banner, removing the legal warning or planting a deceptive message seen by every SSH user. Applying the fix is low-risk: 0644 root:root is the conventional mode and the banner stays readable. Precaution: do not remove the read bit for other, sshd and login display the file to unauthenticated clients, so making it unreadable would blank the banner.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 1.2.8, 1.6.6, 1.7.6 | direct | per OS, see the benchmark table | high |
| PCI DSS | 1.2.8 | supporting | 4.0.1 | medium |
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.