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

Empêcher les utilisateurs de modifier les paramètres de l'économiseur d'écran GNOME3

Verrouille la clé lock-delay de l'économiseur d'écran GNOME afin que les utilisateurs ne puissent ni affaiblir ni désactiver le verrouillage automatique de session qui suit l'extinction de l'écran.

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 2 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 lock-delay est défini ET que /org/gnome/desktop/screensaver/lock-delay figure dans un fichier locks/. L'entrée de verrou est ici le contrôle clé : elle prouve que les utilisateurs ne peuvent pas remplacer la valeur. Un simple examen de fichier d'un profil utilisateur ne pourrait pas indiquer si la politique système est imposée et verrouillée.

only_if { command('dconf').exist? }
describe command('{ grep -rqE \'^[[:space:]]*lock-delay[[:space:]]*=\' /etc/dconf/db/*.d/* 2>/dev/null && grep -rqxF \'/org/gnome/desktop/screensaver/lock-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 lock-delay /etc/dconf/db/*/locks/ (doit correspondre) et lisez la valeur imposée via gsettings get org.gnome.desktop.screensaver lock-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.screensaver lock-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/screensaver/lock-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 réglage 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/screensaver/lock-delay
resourcedconf
valueuint32 5
pavois harden plan local

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

Impact & précautions

Risque faible : durcit une politique d'économiseur/verrouillage existante sans affecter la connexion ni les services. Assurez-vous d'abord qu'une valeur lock-delay/idle-delay raisonnable est définie, sinon verrouiller la clé fige la valeur par défaut présente. Les utilisateurs doivent se reconnecter (ou dconf update doit s'exécuter) pour charger la politique obligatoire. 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

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