Set the GNOME3 Login Warning Banner Text
Enforces an organization-defined warning banner on the GNOME login screen via banner-message-text in the system dconf database, locked against user override.
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
A login banner is both a deterrent and a legal notice. Displaying an organization-approved warning at the GNOME login screen (banner-message-text) puts every user, and any intruder, on notice that access is monitored and unauthorized use is prohibited. Without it, attackers can later claim they had no notice of restrictions, weakening any disciplinary or legal action, and the system silently fails policy and accreditation requirements (NIST AC-8).
What Pavois checks
Pavois verifies in the effective dconf configuration that a drop-in under /etc/dconf/db/*.d/ actually sets banner-message-text, and that /org/gnome/login-screen/banner-message-text is listed in a locks/ file so users cannot clear it. Inspecting the resolved dconf database catches the banner regardless of which keyfile defines it, a file-only scan of one path would miss values set in another drop-in.
only_if { command('dconf').exist? }
describe command('{ grep -rqE \'^[[:space:]]*banner-message-text[[:space:]]*=\' /etc/dconf/db/*.d/* 2>/dev/null && grep -rqxF \'/org/gnome/login-screen/banner-message-text\' /etc/dconf/db/*/locks/* 2>/dev/null && echo ok; } || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
Run dconf read /org/gnome/login-screen/banner-message-text (or gsettings get org.gnome.login-screen banner-message-text); the expected output is your approved banner string, e.g. 'Authorized use only. Activity is monitored.'. Confirm the lock with grep -r banner-message-text /etc/dconf/db/*/locks/.
Inspect & investigate
The display manager renders the banner; its lifecycle is logged via journalctl -u gdm. Login attempts at the greeter appear in journalctl -u gdm and (for the resulting sessions) in /var/log/auth.log or journalctl _COMM=gdm-session-worker.
Remediation
Pavois's harden plan uses the dconf resource to write the keyfile setting banner-message-text and a matching locks/ entry, then runs dconf update. Provide your organization's approved text; apply with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| key | org/gnome/login-screen/banner-message-text |
|---|---|
| resource | dconf |
| value | 'Authorized access only. All activity is monitored and recorded.' |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
No technical risk: the banner only adds text to the login greeter and does not affect authentication or services. Precaution: the banner content is a legal artifact, use the exact wording mandated by your organization or regulator, as an inaccurate notice can be worse than none. The setting applies only where GDM/GNOME runs; headless servers are unaffected.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 1.7.2, 1.8.2, 1.8.1 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.9, AC-8(a), AC-8(c) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | 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.