Durcir le bureau GNOME (dconf)

La menace : la session bureau est là où atterrit le phishing

Un poste de travail est un point d'entrée privilégié : un clic de phishing ou un document piégé s'exécute dans la session bureau de l'utilisateur. De là, des réglages laxistes aident l'attaquant : montage et auto-exécution automatiques des supports amovibles (le classique USB abandonné), un écran déverrouillé sur une machine sans surveillance, ou un écran de connexion GDM qui énumère tous les noms d'utilisateur, prêts à être attaqués. Et comme ce sont des réglages utilisateur, un utilisateur normal (ou du code à sa place) peut souvent les rétablir.

Pourquoi le durcir

Les postes sont là où les humains, donc le phishing et les supports amovibles, rencontrent le réseau. Durcir GNOME réduit cette surface et, surtout, verrouille les bons réglages à l'échelle du système pour qu'ils ne soient pas rétablis par utilisateur. Le bureau devient une base contrôlée et prévisible plutôt que 200 machines configurées différemment.

Comment dconf impose les réglages

dconf est un stockage de réglages en couches, et la sécurité vient de la base système et des locks, pas des keyfiles par utilisateur :

1. Un profil (/etc/dconf/profile/user) indique à chaque session de lire une base système sous celle de l'utilisateur : user-db:user puis system-db:local.
2. Des keyfiles sous /etc/dconf/db/local.d/ posent les valeurs durcies (style INI, groupées par chemin de schéma).
3. Des fichiers de lock sous /etc/dconf/db/local.d/locks/ listent les clés que l'utilisateur peut lire mais pas surcharger. C'est ce qui transforme une suggestion en imposition.
4. dconf update compile les keyfiles texte en base binaire. Rien ne s'applique tant que vous ne le lancez pas.

# /etc/dconf/db/local.d/00-security
[org/gnome/desktop/screensaver]
lock-enabled=true
lock-delay=uint32 5
[org/gnome/desktop/session]
idle-delay=uint32 300
[org/gnome/desktop/media-handling]
automount=false
automount-open=false
autorun-never=true

# /etc/dconf/db/local.d/locks/00-security
/org/gnome/desktop/screensaver/lock-enabled
/org/gnome/desktop/media-handling/automount

Puis dconf update. Pour l'écran d'accueil GDM, posez org.gnome.login-screen disable-user-list=true et banner-message-enable=true avec banner-message-text, et désactivez toute session invité.

Principes de défense appliqués

• Réglages sûrs par défaut : désactiver automount/automount-open et poser autorun-never ; activer le verrouillage d'écran avec un délai d'inactivité court ; afficher la bannière de connexion ; masquer la liste d'utilisateurs à GDM.
• Imposer, pas suggérer : adosser chaque réglage à un lock dconf pour que l'utilisateur le lise sans pouvoir le surcharger.
• Traçabilité : une bannière d'avertissement à l'écran de connexion GDM rappelle l'accès autorisé et surveillé.

Ce que Pavois audite : la base dconf effective

Pavois lit la base dconf effective (la valeur résolue qu'obtient réellement une session, pas seulement un keyfile), et voit donc les défauts système et les locks tels que GNOME les applique. Parmi ses règles GNOME/dconf, il vérifie : la bannière de connexion GDM activée et son texte, automount/automount-open désactivés et autorun-never posé, le verrouillage d'écran par inactivité activé avec un délai borné, et que chacun est verrouillé pour que les utilisateurs ne puissent pas l'annuler.

Vérifier

# la valeur resolue qu'obtient la session :
dconf read /org/gnome/desktop/screensaver/lock-enabled    # true
gsettings get org.gnome.desktop.media-handling automount  # false
# est-elle verrouillee ? une clé verrouillee ne peut etre changee par l'utilisateur :
dconf write /org/gnome/desktop/screensaver/lock-enabled false  # échoue / sans effet si verrouillé
machinectl shell user@ -- gsettings get org.gnome.login-screen disable-user-list

Pièges

• Oublier dconf update : les modifications des keyfiles ne font rien tant que la base binaire n'est pas recompilée.
• Régler sans verrouiller : une valeur que l'utilisateur peut rétablir n'est pas du durcissement. Ajoutez l'entrée correspondante sous locks/.
• Pas de profil, pas de base système : si /etc/dconf/profile/user ne référence pas system-db:local, les keyfiles ne sont jamais lus.
• Le type compte : uint32 300, true/false, chaînes entre guillemets ; un mauvais type fait ignorer la clé en silence.
• Les serveurs sans écran ne lancent pas GNOME : ces contrôles concernent les postes de travail ; ils ne sont pas pertinents sur un serveur sans bureau.

FAQ

Pourquoi verrouiller les clés au lieu de seulement les régler ? Parce que les valeurs dconf sont modifiables par l'utilisateur par défaut ; sans entrée dans locks/, l'utilisateur (ou un malware dans la session) les rétablit. Le lock rend la valeur système prioritaire.

Ma modification de keyfile n'a eu aucun effet. Vous avez probablement sauté dconf update, ou le profil user n'inclut pas system-db:local. Vérifiez les deux.

Pourquoi Pavois lit-il la valeur résolue, pas le keyfile ? Parce que la superposition et les locks décident de ce que la session reçoit réellement ; la base effective est la vérité, un keyfile sur disque n'est qu'une entrée.