Set GNOME3 Screensaver Inactivity Timeout
Sets the session inactivity timeout that triggers the screensaver via idle-delay 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
The idle delay (idle-delay) is how long a session may sit untouched before GNOME marks it idle and starts the screensaver/lock chain. A session time-out lock protects a workstation when a user steps away without logging out. If idle-delay is unset or too long, an unattended desktop stays open well past the policy window (commonly 15 minutes / 900 s), exposing the live session to anyone nearby.
What Pavois checks
Pavois verifies in the effective dconf configuration that a drop-in under /etc/dconf/db/*.d/ sets idle-delay, and that /org/gnome/desktop/session/idle-delay is in a locks/ file so users cannot lengthen or clear it. Reading the resolved dconf database catches the value wherever a keyfile defines it.
only_if { command('dconf').exist? }
describe command('{ grep -rqE \'^[[:space:]]*idle-delay[[:space:]]*=\' /etc/dconf/db/*.d/* 2>/dev/null && grep -rqxF \'/org/gnome/desktop/session/idle-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
Run dconf read /org/gnome/desktop/session/idle-delay (or gsettings get org.gnome.desktop.session idle-delay); the expected output is a uint32 at or below your policy limit, e.g. uint32 900 (15 minutes). Confirm the lock with grep -r idle-delay /etc/dconf/db/*/locks/.
Inspect & investigate
Idle transitions and screensaver activation are logged in the user session journal: journalctl --user -u gnome-session and via journalctl _COMM=gnome-shell. Live idle state is exposed by the session manager over D-Bus (org.gnome.SessionManager).
Remediation
Pavois's harden plan uses the dconf resource to write the keyfile setting idle-delay to your policy value (e.g. 900 s) 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/desktop/session/idle-delay |
|---|---|
| resource | dconf |
| value | uint32 900 |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Low impact, but user-visible: screens will dim and lock after the configured idle time. Precaution: choose a delay that meets policy (often 900 s) without disrupting presentations, long-running tasks, or kiosks, exempt kiosk/dashboard hosts. A value of 0 disables the timeout entirely and would fail the intent, so always set a positive, policy-compliant value.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 1.7.4, 1.8.5, 1.7.5, 8.2.8 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.10, AC-11(a), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 8.2.8 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-271025, UBTU-24-200020 | 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.