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

Définir le délai d'inactivité du screensaver GNOME3

Définit le délai d'inactivité de session qui déclenche le screensaver via idle-delay 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é →
Ubuntu 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

Le délai d'inactivité (idle-delay) est la durée pendant laquelle une session peut rester inactive avant que GNOME ne la marque comme inactive et déclenche la chaîne screensaver/verrouillage. Un verrouillage par temporisation protège un poste lorsqu'un utilisateur s'éloigne sans se déconnecter. Si idle-delay n'est pas défini ou trop long, un bureau laissé sans surveillance reste ouvert bien au-delà de la fenêtre de politique (souvent 15 minutes / 900 s), exposant la session active à toute personne à proximité.

Ce que vérifie Pavois

Pavois vérifie dans la configuration dconf effective qu'un drop-in sous /etc/dconf/db/*.d/ définit idle-delay, et que /org/gnome/desktop/session/idle-delay figure dans un fichier locks/ afin que les utilisateurs ne puissent ni l'allonger ni l'effacer. Lire la base dconf résolue capte la valeur quel que soit le fichier de clés qui la définit.

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' }
end

Comment vérifier qu’elle est appliquée

Exécutez dconf read /org/gnome/desktop/session/idle-delay (ou gsettings get org.gnome.desktop.session idle-delay) ; la sortie attendue est un uint32 égal ou inférieur à votre limite de politique, p. ex. uint32 900 (15 minutes). Confirmez le verrou avec grep -r idle-delay /etc/dconf/db/*/locks/.

Inspecter et investiguer

Les transitions d'inactivité et l'activation du screensaver sont journalisées dans le journal de la session utilisateur : journalctl --user -u gnome-session et via journalctl _COMM=gnome-shell. L'état d'inactivité en direct est exposé par le gestionnaire de session via D-Bus (org.gnome.SessionManager).

Remédiation

Le plan de durcissement de Pavois utilise la ressource dconf pour écrire le fichier de clés définissant idle-delay à votre valeur de politique (p. ex. 900 s) 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/session/idle-delay
resourcedconf
valueuint32 900
pavois harden plan local

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

Impact & précautions

Impact faible mais visible : les écrans s'assombrissent et se verrouillent après la durée d'inactivité configurée. Précaution : choisissez un délai conforme à la politique (souvent 900 s) sans gêner les présentations, les tâches longues ou les bornes, exemptez les hôtes borne/tableau de bord. Une valeur de 0 désactive entièrement la temporisation et trahirait l'intention ; définissez toujours une valeur positive conforme à la politique.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS1.7.4, 1.8.5, 1.7.5, 8.2.8directper OS, see the benchmark tablehaute
NIST3.1.10, AC-11(a), CM-6(a)support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne
PCI DSS8.2.8support4.0.1moyenne
DISA STIGUBTU-22-271025, 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