← Toutes les règles
SOCLE-CLD-GEN-019// GNOME desktop (dconf)moyenneconfig persistante

Activer le verrouillage du screensaver GNOME3 après une période d'inactivité

Force le screensaver GNOME à verrouiller la session lors de son activation, via lock-enabled=true dans la base dconf du système, verrouillé contre toute modification par l'utilisateur.

Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.

Un PASS prouve? actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 4 normes

Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.

Pourquoi cette règle

lock-enabled est l'interrupteur maître qui fait que le screensaver GNOME exige réellement un mot de passe lors de son activation. Avec le délai et l'activation d'inactivité définis mais lock-enabled=false, le screensaver tourne mais ne verrouille jamais, la session reste accessible, annulant tout l'intérêt d'une temporisation d'inactivité. L'activer garantit qu'un poste sans surveillance exige une ré-authentification.

Ce que vérifie Pavois

Pavois lit la configuration dconf effective : il résout la dernière valeur définie de lock-enabled parmi les drop-ins /etc/dconf/db/*.d/, exige true, et vérifie que /org/gnome/desktop/screensaver/lock-enabled figure dans un fichier locks/ afin que les utilisateurs ne puissent pas désactiver le verrouillage. Évaluer la valeur résolue (le dernier fichier de clés l'emporte) reflète la façon dont dconf applique la politique et évite un faux succès si un drop-in ultérieur la désactive.

only_if { command('dconf').exist? }
describe command('{ s=$(grep -rhE \'^[[:space:]]*lock-enabled[[:space:]]*=\' /etc/dconf/db/*.d/* 2>/dev/null | tail -1 | sed -E \'s/^[^=]*=[[:space:]]*//\' | tr -d "\'\\""); [ "$s" = "true" ] && grep -rqxF \'/org/gnome/desktop/screensaver/lock-enabled\' /etc/dconf/db/*/locks/* 2>/dev/null && echo ok; } || echo ko') do
  its('stdout.strip') { should eq 'ok' }
end

Comment vérifier qu’elle est appliquée

Exécutez dconf read /org/gnome/desktop/screensaver/lock-enabled (ou gsettings get org.gnome.desktop.screensaver lock-enabled) ; la sortie attendue est true. Confirmez le verrou avec grep -r lock-enabled /etc/dconf/db/*/locks/.

Inspecter et investiguer

Les événements de verrouillage et de déverrouillage sont journalisés dans le journal de la session utilisateur : journalctl --user -u gnome-session et via journalctl _COMM=gnome-shell. L'état de verrouillage en direct est exposé via D-Bus par org.gnome.ScreenSaver (gdbus call ... GetActive).

Remédiation

Le plan de durcissement de Pavois utilise la ressource dconf pour écrire le fichier de clés définissant lock-enabled=true et l'entrée locks/ correspondante, puis exécute dconf update. Appliquez avec pavois harden apply.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

keyorg/gnome/desktop/screensaver/lock-enabled
resourcedconf
valuetrue
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Impact faible : les utilisateurs devront se ré-authentifier après l'activation du screensaver, ce qui est le comportement attendu. Précaution : assurez-vous que les utilisateurs connaissent leur mot de passe (surtout sur les systèmes où ils n'utilisent normalement qu'une carte à puce ou le SSO), et exemptez les hôtes borne/tableau de bord devant garder l'écran accessible. Associez à un idle-delay raisonnable pour que le verrouillage ne soit pas prématuré.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS1.7.4, 1.7.5, 8.2.8directper OS, see the benchmark tablehaute
NISTCM-6(a), 3.1.10support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne
PCI DSS8.2.8support4.0.1moyenne
DISA STIGUBTU-22-271020, UBTU-24-200020directper OS STIG releasehaute

Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.

Sources & références