Set the GNOME3 Login Number of Failures
Limits the number of authentication failures the GNOME login screen tolerates before resetting, via allowed-failures 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
Capping the number of password attempts the GNOME greeter accepts before resetting (allowed-failures) slows down interactive password-guessing at the login screen and forces an attacker to restart the prompt, which both reduces throughput and draws attention to repeated failures. Leaving it unbounded lets someone with physical access (or a remote display) hammer guesses against a logged-out console with no friction.
What Pavois checks
Pavois verifies in the effective dconf configuration that a drop-in under /etc/dconf/db/*.d/ sets allowed-failures, and that /org/gnome/login-screen/allowed-failures is in a locks/ file so it cannot be raised by a user. Reading the resolved dconf database catches the value in whichever keyfile defines it.
only_if { command('dconf').exist? }
describe command('{ grep -rqE \'^[[:space:]]*allowed-failures[[:space:]]*=\' /etc/dconf/db/*.d/* 2>/dev/null && grep -rqxF \'/org/gnome/login-screen/allowed-failures\' /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/allowed-failures (or gsettings get org.gnome.login-screen allowed-failures); the expected output is your configured small integer, e.g. 3. Confirm the lock with grep -r allowed-failures /etc/dconf/db/*/locks/.
Inspect & investigate
Failed greeter authentications are logged by the display manager: journalctl -u gdm and journalctl _COMM=gdm-session-worker. The PAM stack behind it records failures in /var/log/secure (Fedora/RHEL).
Remediation
Pavois's harden plan uses the dconf resource to write the keyfile setting allowed-failures to a small value and a matching locks/ entry, then runs dconf update. 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/allowed-failures |
|---|---|
| resource | dconf |
| value | uint32 5 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Low impact: legitimate users simply re-trigger the prompt after the cap. Precaution: set the limit high enough (e.g. 3) to avoid annoying users who mistype, but note this caps prompts only, it is not an account lockout, so pair it with faillock/pam_faillock for real lockout. Only affects machines running the GNOME greeter.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| NIST | 3.1.8 | 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.