Enable GNOME3 Login Warning Banner
Ensures the GNOME login screen displays a warning banner by setting banner-message-enable=true and locking the key so users cannot disable it.
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
Displaying a standardized, approved use-notification banner before granting access to the system warns users that activity may be monitored and that unauthorized access is prohibited. This satisfies legal and policy requirements (consistent with applicable laws, directives, standards and guidance) and strengthens any later legal action against intruders. The setting must also be locked so a logged-in user cannot remove the banner.
What Pavois checks
Pavois verifies two things in the effective dconf state: the last definition of banner-message-enable across /etc/dconf/db/*.d/* resolves to true, and the key /org/gnome/login-screen/banner-message-enable appears in a dconf lock file. Reading the resolved key precedence (last drop-in wins) and the lock, rather than assuming a single file, matches how dconf actually computes the value, catching cases where a later drop-in re-enables editing or overrides the banner.
only_if { command('dconf').exist? }
describe command('{ s=$(grep -rhE \'^[[:space:]]*banner-message-enable[[:space:]]*=\' /etc/dconf/db/*.d/* 2>/dev/null | tail -1 | sed -E \'s/^[^=]*=[[:space:]]*//\' | tr -d "\'\\""); [ "$s" = "true" ] && grep -rqxF \'/org/gnome/login-screen/banner-message-enable\' /etc/dconf/db/*/locks/* 2>/dev/null && echo ok; } || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
After updating the dconf database (dconf update), confirm the effective value with gsettings get org.gnome.login-screen banner-message-enable (should print true) and check that the key is locked by listing /etc/dconf/db/*/locks/* for the entry /org/gnome/login-screen/banner-message-enable.
Inspect & investigate
dconf has no runtime event log; verify state with gsettings get org.gnome.login-screen banner-message-enable and inspect /etc/dconf/db/*.d/* and /etc/dconf/db/*/locks/*. The banner itself is visible on the GDM greeter; GDM/session messages can be reviewed with journalctl -u gdm (or journalctl -b /usr/sbin/gdm).
Remediation
Pavois's harden plan uses the dconf resource to write banner-message-enable=true (and typically a banner-message-text) into a system dconf profile drop-in, add the matching entry to a locks file, then run dconf update to compile the database. Apply it 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-enable |
|---|---|
| resource | dconf |
| value | true |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
This rule only applies to hosts running GNOME/GDM; on headless servers it is not relevant. The change is low-risk: it adds a banner to the login screen and does not block authentication. Precautions: keep the banner text aligned with your organization's approved legal notice, and remember that locking the key prevents users (and local config) from altering it, to change wording later you must edit the system profile and re-run dconf update.
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(b), AC-8(c) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| DISA STIG | UBTU-22-271010, UBTU-24-200650 | direct | per OS STIG release | 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.