Ensure Users Cannot Change GNOME3 Screensaver Settings
Locks the GNOME screensaver lock-delay key so users cannot weaken or disable the automatic session lock that follows screen blanking.
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 session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the session lock. As such, users should not be allowed to change session settings.
What Pavois checks
Pavois confirms, against the effective system dconf database under /etc/dconf/db/*.d/, that lock-delay is set AND that /org/gnome/desktop/screensaver/lock-delay appears in a locks/ file. The lock entry is the key control here, it proves users cannot override the value. A file-only scan of a user profile could not tell whether the system policy is enforced and locked.
only_if { command('dconf').exist? }
describe command('{ grep -rqE \'^[[:space:]]*lock-delay[[:space:]]*=\' /etc/dconf/db/*.d/* 2>/dev/null && grep -rqxF \'/org/gnome/desktop/screensaver/lock-delay\' /etc/dconf/db/*/locks/* 2>/dev/null && echo ok; } || echo ko') do
its('stdout.strip') { should eq 'ok' }
endHow to verify it is applied
List the lock with grep -r lock-delay /etc/dconf/db/*/locks/ (must match) and read the enforced value via gsettings get org.gnome.desktop.screensaver lock-delay. Re-running the InSpec command should print ok.
Inspect & investigate
dconf is not logged to syslog; verify state with gsettings get org.gnome.desktop.screensaver lock-delay and ls /etc/dconf/db/. After editing keyfiles, dconf update recompiles the binary databases.
Remediation
pavois harden apply uses the dconf resource to add /org/gnome/desktop/screensaver/lock-delay to the system locks/ directory (alongside the enforced keyfile value), then runs dconf update so the setting becomes non-overridable for all users.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| key | org/gnome/desktop/screensaver/lock-delay |
|---|---|
| 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 risk: tightens an existing screensaver/lock policy without affecting login or services. Ensure a sensible lock-delay/idle-delay value is set first, otherwise locking the key cements whatever default is present. Users must re-login (or dconf update must run) to load the mandatory policy. GNOME desktop only; not applicable to headless servers.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 1.8.5, 1.8.3 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.10 | 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.