Ensure Users Cannot Change GNOME3 Session Idle Settings
Locks the GNOME idle-delay key so users cannot raise or disable the idle timeout that triggers the automatic session lock.
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 idle-delay is set AND that /org/gnome/desktop/session/idle-delay appears in a locks/ file. The lock entry is the real control: it proves the idle timeout cannot be raised or removed by a user. A file-only read of a single profile could not show whether the system policy is enforced and locked.
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
List the lock with grep -r idle-delay /etc/dconf/db/*/locks/ (must match) and read the enforced value via gsettings get org.gnome.desktop.session idle-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.session idle-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/session/idle-delay to the system locks/ directory (alongside the enforced keyfile value), then runs dconf update so the idle timeout 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/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 risk: enforces an existing idle/lock policy without affecting login or services. Set a sensible non-zero idle-delay first, otherwise locking the key cements whatever value is present (a locked 0 would mean never lock). Users must re-login (or dconf update must run) for the policy to load. 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 |
| PCI DSS | 8.2.8 | supporting | 4.0.1 | 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.