Sécurité

Pour des raisons de sécurité, il est recommandé d'utiliser un identifiant d'utilisateur et de groupe dédié pour un fonctionnement correct. Cet utilisateur et ce groupe sont sur la plupart des systèmes « gdm », mais peuvent être configurés comme n'importe quel utilisateur ou groupe. Tous les programmes d'interface graphique de GDM sont lancés par cet utilisateur, afin que les programmes qui interagissent avec l'utilisateur s'exécutent dans un environnement protégé. Cet utilisateur et ce groupe doivent avoir des privilèges restreints.

Le seul privilège spécial nécessaire pour l'utilisateur « gdm » est l'autorisation de lire et d'écrire des fichiers Xauth dans le répertoire <var>/run/gdm. Le répertoire <var>/run/gdm doit être la propriété de root:gdm avec les permissions 1777.

Vous ne devez en aucun cas configurer l'utilisateur/groupe GDM comme un utilisateur auquel un autre utilisateur puisse en obtenir facilement l'accès, tel que nobody. Tout utilisateur qui obtient l'accès à une clé Xauth peut explorer et contrôler les programmes de l'interface graphique de la session associée ou exécuter un attaque par déni de service sur la session. Il est important de s'assurer que le système est configuré correctement pour que seul l'utilisateur « gdm » ait accès à ces fichiers et qu'il ne soit pas facile de se connecter en utilisant ce compte. Par exemple, le compte devrait être configuré sans mot de passe et sans autoriser les utilisateurs non root à se connecter au compte.

La configuration de la bannière d'accueil de GDM est stockée dans GConf. Pour permettre à l'utilisateur GDM d'écrire la configuration, il est nécessaire qu'il ait un répertoire $HOME accessible en écriture. Il est possible de configurer GConf par défaut pour éviter d'avoir à fournir un répertoire $HOME accessible en écriture à l'utilisateur « gdm ». Cependant, certaines fonctions de GDM peuvent être désactivées s'il ne lui est pas possible d'écrire des informations d'état dans la configuration GConf.

GDM utilise PAM pour authentifier la connexion. PAM signifie Pluggable Authentication Module (Module d'authentification enfichable) et est utilisé par la plupart des programmes qui demandent une authentification sur votre ordinateur. Il permet à l'administrateur de configurer différents types d'authentification pour différents programmes de connexion (tels que ssh, interface graphique de connexion, économiseur d'écran, etc).

PAM est compliqué et hautement configurable ; cette documentation n'a pas pour but d'expliquer cela en détails. Le but ici est de donner un aperçu de la façon dont la configuration de PAM se rapporte à GDM, comment PAM est configuré couramment avec GDM, ainsi que les problèmes connus. Il est nécessaire pour une personne qui doit effectuer une configuration de PAM de lire plus en détails la documentation de PAM afin de comprendre comment configurer PAM ainsi que les termes utilisés dans cette section.

La configuration de PAM se fait par différentes interfaces, en général similaires, selon les systèmes d'exploitation ; consultez la page de manuel de pam.d ou de pam.conf pour plus de détails. Prenez soin de lire la documentation de PAM et soyez bien conscients des implications de sécurité induites par les modifications de votre configuration.

Il est à noter que par défaut, GDM utilise le nom de service PAM « gdm » pour une connexion normale et le nom de service PAM « gdm-autologin » pour une connexion automatique. Ces services ne sont peut-être pas définis dans votre pam.d ou dans le fichier de configuration pam.conf. S'il n'y a pas d'entrée, GDM utilise le fonctionnement par défaut de PAM. Sur la plupart des systèmes cela fonctionne bien. Cependant, la fonction de connexion automatique peut ne pas fonctionner si le service gdm-autologin n'est pas défini.

Le script PostLogin est lancé avant l'appel de pam_open_session et le script PreSession est appelé après. Cela permet à l'administrateur système d'ajouter des scripts de connexion soit avant ou après que PAM initialise la session.

Si vous souhaitez faire fonctionner GDM avec d'autres types de mécanismes d'authentification (comme par ex. un lecteur d'empreintes digitales ou de carte à puce), il vous faut alors implémenter cela en créant un module de service PAM pour ce type d'authentification, plutôt qu'en essayant de modifier directement le code de GDM. Référez-vous à la documentation de PAM sur votre système. Cette question a été fréquemment abordée sur la liste de diffusion

PAM comporte quelques limitations dans le cas où il doit fonctionner avec plusieurs types d'authentification en même temps, comme prendre en charge soit une carte à puce soit un identifiant et mot de passe dans le programme de connexion. Il existe des techniques pour parvenir à le faire fonctionner, et il convient de rechercher comment ce problème est généralement résolu lorsque l'on configure une configuration de ce type.

Si la connexion automatique ne fonctionne pas sur un système, vérifiez si la pile « gdm-autologin » PAM est définie dans la configuration de PAM. Pour que cela fonctionne, il est nécessaire d'utiliser un module PAM qui ne fait simplement pas d'authentification ou qui retourne simplement PAM_SUCCESS de toutes ses interfaces publiques. Si l'on suppose que le système a bien le module PAM pam_allow.so qui gère cela, une configuration PAM pour activer le « gdm-autologin » ressemble à ce qui suit :

       gdm-autologin auth  required    pam_unix_cred.so.1
       gdm-autologin auth  sufficient  pam_allow.so.1
       gdm-autologin account  sufficient  pam_allow.so.1
       gdm-autologin session  sufficient  pam_allow.so.1
       gdm-autologin password  sufficient  pam_allow.so.1

La configuration ci-dessus ne produit aucune journalisation dans lastlog. Si vous souhaitez une telle journalisation, utilisez la configuration suivante pour l'élément session :

       gdm-autologin session required pam_unix_session.so.1

Si l'ordinateur est utilisé par plusieurs personnes, un cas où la connexion automatique n'est pas appropriée, il peut être souhaitable de laisser certains utilisateurs se connecter sans mot de passe. Cette fonctionnalité peut être activée individuellement pour chaque utilisateur dans l'outil de gestion des utilisateurs de GNOME (users-admin de gnome-system-tools). Il s'agit alors de vérifier que l'utilisateur est membre d'un groupe Unix nommé « nopasswdlogin » avant la demande d'un mot de passe. Pour que cela fonctionne, le fichier de configuration PAM du service « gdm » doit inclure une ligne telle que :

      gdm auth  sufficient  pam_succeed_if.so  user ingroup nopasswdlogin

GDM génère des éléments utmp et wtmp dans la base de données de suivi des utilisateurs lors de la connexion et déconnexion de sessions. La base de données utmp contient des informations concernant le suivi et l'accès des utilisateurs ; ces informations sont utilisées par des commandes telles que finger, last, login et who. La base de données wtmp contient l'historique des informations de suivi et d'accès des utilisateurs de la base de données utmp. Référez-vous aux pages de manuel de utmp et wtmp pour plus d'informations.

Les fichiers d'autorisation du serveur X sont stockées au démarrage dans un nouveau sous-répertoire de <var>/run/gdm. Ces fichiers sont utilisés pour stocker et partager un « mot de passe » utilisé entre les clients X et le serveur X. Ce « mot de passe » est unique pour chaque session connectée, de façon à ce qu'aucun utilisateur ne puisse espionner la session des autres.

GDM ne prend en charge que le processus d'authentification du serveur X MIT-MAGIC-COOKIE-1. Normalement, les autres processus n'apportent pas grand chose et jusqu'à présent, aucun effort n'a été fait pour les implémenter. Soyez extrêmement prudent lors de l'utilisation de XDMCP, car le cookie d'authentification du serveur X passe en texte clair sur le réseau. Si un pirate peut renifler le trafic réseau, il pourra simplement intercepter votre mot de passe d'authentification lors de la connexion, quel que soit le processus d'authentification utilisé. Lorsque vous ne pouvez pas faire confiance au trafic réseau, vous devriez alors utiliser SSH au lieu de XDMCP, pour faire transiter la connexion X par un tunnel. On peut comparer XDMCP à une sorte de Telnet graphique, avec les mêmes problèmes de sécurité. Dans la plupart des cas, ssh -Y doit être préféré aux fonctionnalités XDMCP de GDM.

Même si votre affichage est protégé par des cookies, XEvents et donc aussi les frappes au clavier lors de la saisie des mots de passe transitent toujours sur le réseau en texte clair. Il est trivial de les capturer.

XDMCP est surtout utile pour mettre en place des clients légers, par exemple dans une salle de terminaux. Ces clients légers n'auront besoin du réseau que pour accéder au serveur, il semble donc que la meilleure politique de sécurité dans ce cas est de séparer ce réseau du monde externe et de le réserver à l'accès au serveur. Le seul point à partir duquel vous avez besoin d'accéder à l'extérieur est le serveur. Ce type de configuration ne doit jamais utiliser un hub non administrable ou un autre type de réseau reniflable.

Le contrôle d'accès XDMCP est réalisé par TCP wrappers. Il est possible que GDM soit compilé sans la prise en charge de TCP wrapper, il se peut donc que cette fonctionnalité ne soit pas prise en charge par certains systèmes d'exploitation.

Vous devriez utiliser le nom de service gdm dans les fichiers <etc>/hosts.allow et <etc>/hosts.deny. Par exemple, pour empêcher les ordinateurs de .danger.domaine de se connecter, ajoutez

gdm: .danger.domaine

à <etc>/hosts.deny. Il se peut que vous deviez aussi ajouter

gdm: .votre.domaine

à <etc>/hosts.allow, dans le cas habituel où vous refusez tous les services de tous les hôtes. Consultez la page de manuel de hosts.allow(5) pour les détails.

Même si GDM essaie de déjouer les plans d'attaques potentiels sur le protocole XDMCP, il est tout de même conseillé de bloquer le port XDMCP (normalement le port UDP 177) sur votre pare-feu dans le cas où vous n'en avez pas réellement besoin. GDM se protège des attaques par déni de service (DoS), mais le protocole X est tout de même non sécurisé en lui-même et ne devrait être utilisé que dans un environnement maîtrisé. De plus, chaque connexion distante consomme beaucoup de ressources, ce qui rend les attaques par déni de service plus simples par XDMCP que sur un serveur Web.

Il est également sage de bloquer tous les ports du serveur X sur votre pare-feu. Cela correspond aux ports TCP 6000 + (un pour chaque numéro d'affichage). Il est à relever que GDM utilise des numéros d'affichage à partir de 20 pour les serveurs flexibles sur demande.

X n'est pas un protocole très sûr à utiliser sur Internet, et XDMCP l'est encore moins.

GDM peut être configuré pour utiliser PolicyKit et permettre à l'administrateur système de contrôler si l'écran de connexion fournit les boutons d'extinction et de redémarrage sur l'écran d'accueil.

Ces boutons sont respectivement contrôlés par les actions org.freedesktop.consolekit.system.stop-multiple-users et org.freedesktop.consolekit.system.restart-multiple-users. Les règles pour ces actions peuvent être configurées avec l'outil polkit-gnome-authorization ou le programme en ligne de commande polkit-auth.

GDM peut être configuré pour utiliser RBAC au lieu de Policykit. Dans ce cas, la configuration RBAC est utilisée pour contrôler si l'écran de connexion fournit les boutons d'extinction et de redémarrage sur l'écran d'accueil.

Par exemple, avec Oracle Solaris, on utilise l'autorisation de « solaris.system.shutdown » pour cette gestion. Modifiez simplement le fichier /etc/user_attr pour que l'utilisateur « gdm » dispose de cette autorisation.