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

Empêcher les utilisateurs de modifier les paramètres d'inactivité de session GNOME3

Verrouille la clé GNOME idle-delay afin que les utilisateurs ne puissent ni augmenter ni désactiver le délai d'inactivité qui déclenche le verrouillage automatique de session.

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 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 3 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 verrouillage de session sur inactivité est une action temporaire déclenchée lorsqu'un utilisateur cesse de travailler et s'éloigne physiquement du système d'information sans se déconnecter, en raison du caractère temporaire de son absence. Plutôt que de compter sur l'utilisateur pour verrouiller manuellement sa session avant de s'éloigner, les bureaux GNOME peuvent être configurés pour détecter l'inactivité d'une session et déclencher son verrouillage. Les utilisateurs ne doivent donc pas être autorisés à modifier ces paramètres de session.

Ce que vérifie Pavois

Pavois confirme, face à la base dconf système effective sous /etc/dconf/db/*.d/, que idle-delay est défini ET que /org/gnome/desktop/session/idle-delay figure dans un fichier locks/. L'entrée de verrou est le véritable contrôle : elle prouve que le délai d'inactivité ne peut être ni augmenté ni supprimé par un utilisateur. Une simple lecture de fichier d'un seul profil ne pourrait pas montrer si la politique système est imposée et verrouillée.

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

Listez le verrou avec grep -r idle-delay /etc/dconf/db/*/locks/ (doit correspondre) et lisez la valeur imposée via gsettings get org.gnome.desktop.session idle-delay. La réexécution de la commande InSpec doit afficher ok.

Inspecter et investiguer

dconf n'est pas journalisé dans syslog ; vérifiez l'état avec gsettings get org.gnome.desktop.session idle-delay et ls /etc/dconf/db/. Après modification des fichiers de clés, dconf update recompile les bases binaires.

Remédiation

pavois harden apply utilise la ressource dconf pour ajouter /org/gnome/desktop/session/idle-delay au répertoire locks/ système (aux côtés de la valeur imposée dans le fichier de clés), puis exécute dconf update afin que le délai d'inactivité devienne non modifiable par tous les utilisateurs.

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

Risque faible : impose une politique d'inactivité/verrouillage existante sans affecter la connexion ni les services. Définissez d'abord une valeur idle-delay raisonnable et non nulle, sinon verrouiller la clé fige la valeur présente (un 0 verrouillé signifierait ne jamais verrouiller). Les utilisateurs doivent se reconnecter (ou dconf update doit s'exécuter) pour charger la politique. Bureau GNOME uniquement ; sans objet sur un serveur sans interface graphique.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS1.8.5, 1.8.3directper OS, see the benchmark tablehaute
NIST3.1.10support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne
PCI DSS8.2.8support4.0.1moyenne

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