Page suivante Page précédente Table des matières

6. Dire au serveur ...

Le serveur n'acceptera pas de connexions venant de n'importe où. Vous ne voulez pas que n'importe qui puisse afficher des fenêtres sur votre écran. Ou lire ce vous tapez -- souvenez-vous que votre clavier fait partie de votre unité d'affichage!

Trop peu de gens semble réaliser que permettre l'accès à leur unité d'affichage pose des problèmes de sécurité. Quelqu'un qui dispose d'un accès à votre unité d'affichage peut lire et écrire sur vos écrans, lire vos frappes au clavier, et suivre les déplacements de votre mulot.

La plupart des serveurs disposent de deux manières d'authentifier les demandes de connexions qui arrivent : le mécanisme de la liste d'hôtes (xhost) et le mécanisme du mot de passe secret (magic cookie) (xauth). De plus, il y a ssh, l'interpréteur de commande sécurisé, qui peut acheminer les connexions X.

6.1 Xhost

Xhost permet les accès basés sur les nom d'hôtes. Le serveur entretient une liste des hôtes qui sont autorisés à se connecter à lui. Il peut aussi désactiver complètement la vérification des hôtes. Attention : cela signifie que plus aucun contrôle n'est effectué, et donc, que n'importe quel hôte peut se connecter!

Vous pouvez contrôler la liste des hôtes du serveur avec le programme xhost. Pour utiliser ce mécanisme dans l'exemple précédent, faites :

light$ xhost +dark.matt.er

Ceci permet toutes les connexions à partir de l'hôte dark.matt.er. Dès que votre client X a réalisé sa connexion et affiche une fenêtre, par sécurité, supprimez les permissions pour d'autres connexions avec :

light$ xhost -dark.matt.er

Vous pouvez désactiver la vérification des hôtes avec :

light$ xhost +

Ceci désactive la vérification des accès des hôtes et donc permet à tout le monde de se connecter. Vous ne devriez jamais faire cela sur un réseau où vous n'avez pas confiance dans tous les utilisateurs (tel internet). Vous pouvez réactiver la vérification des hôtes avec :

light$ xhost -

xhost - par lui-même ne supprime pas tous les hôtes de la liste d'accès (ce qui serait tout à fait inutile - vous ne pourriez plus vous connecter de n'importe où, pas même de votre hôte local).

Xhost est un mécanisme vraiment très peu sûr. Il ne fait pas de distinction entre les différents utilisateurs sur l'hôte à distance. De plus, les noms d'hôtes (en réalité des adresses) peuvent être manipulés. C'est mauvais si vous vous trouvez sur un réseau douteux (déjà, par exemple, avec un accès PPP téléphonique à Internet).

6.2 Xauth

Xauth autorise l'accès à tous ceux qui connaissent le bon secret. On appelle un tel secret un enregistrement d'autorisation ou cookie. Ce mécanisme d'autorisation est désigné cérémonieusement comme étant le MIT-MAGIC-COOKIE-1.

Les cookies pour les différentes unités d'affichage sont stockés ensembles dans ~/.Xauthority.Votre fichier ~/.Xauthority doit être inaccessible pour les utilisateurs groupe/autres. Le programme xauth gère ces cookies, donc le surnom xauth dans ce schéma.

Au démarrage d'une session, le serveur lit un cookie dans le fichier qui est indiqué par l'argument -auth. Ensuite, le serveur ne permet la connexion que des clients qui connaissent le même cookie. Quand le cookie dans ~/.Xauthority change, le serveur ne récupérera pas la modification.

Les serveurs les plus récents peuvent générer des cookies à la volée pour des clients qui le demandent. les cookies sont cependant encore conservés dans le serveur; ils ne finissent pas dans ~/.Xauthority à moins qu'un client ne les y mettent. Selon David Wiggins :

Une possibilité supplémentaire , qui peut vous intéresser, a été ajoutée dans X11R6.3. Par l'intermédiaire de la nouvelle extension SECURITY, le serveur X lui-même peut générer et renvoyer de nouveaux cookies à la volée. De plus on peut désigner les cookies comme étant ``douteux'' de sorte que les applications qui se connectent avec de tels cookies auront une capacité opératoire restreinte. Par exemple, ils ne pourront pas regarder les entrées au clavier/mulot, ou le contenu des fenêtres, d'autres clients ``fiables''. Il y a une nouvelle sous-commande ``generate'' de xauth pour rendre cette fonctionnalité, pas forcément facile, mais au moins possible à utiliser.

Xauth possède un avantage clair, au niveau de la sécurité, sur xhost. Vous pouvez limiter l'accès à des utilisateurs spécifiques sur des ordinateurs spécifiques. Il ne permet pas l'usurpation d'adresse comme le permet xhost. Et, si vous le désirez, vous pouvez encore utiliser xhost en parallèle pour permettre des connexions.

Fabrication du Cookie

Si vous voulez utiliser xauth, vous devez lancer le serveur X avec l'argument -auth authfile. Si vous utilisez le script startx pour lancer le serveur X, c'est le bon endroit pour le faire. Créez l'enregistrement d'autorisation comme indiqué ci-dessous dans votre script startx.

Extrait de /usr/X11R6/bin/startx:

mcookie|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"

Mcookie est un petit programme du paquetage util-linux, site primaire ftp://ftp.math.uio.no/pub/linux/. Autrement, vous pouvez utiliser md5sum pour créer quelques données aléatoires (de, par exemple, /dev/urandom ou ps -axl) au format cookie :

dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q
xinit -- -auth "$HOME/.Xauthority"

Si vous ne pouvez pas éditer le script startx (parce que vous n'êtes pas root), demandez à votre administrateur de système de configurer startx correctement, ou, à la place, laissez-le configurer xdm. S'il ne peut, ou ne veut, pas, vous pouvez écrire un script ~/.xserverrc. Si vous avez ce script, il sera exécuté par xinit au lieu du véritable serveur X. Alors, vous pourrez lancer le serveur X véritable à partir de ce script avec les arguments adaptés. Pour faire cela, faites utiliser par votre ~/.xserverrc le mcookie de la ligne ci-dessus pour créer un cookie puis lancer le véritable serveur X :

#!/bin/sh
mcookie|sed -e 's/^/add :0 . /'|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"

Si vous utilisez xdm pour gérer vos sessions X, vous pouvez utiliser xauth facilement. Définissez les ressources du DisplayManager.authDir dans /etc/X11/xdm/xdm-config. Xdm passera l'argument -auth au serveur X à son démarrage. Au moment de la connexion sous xdm, xdm place le cookie dans ~/.Xauthority pour vous. Consultez xdm(1) pour de plus amples information. Par exemple, mon /etc/X11/xdm/xdm-config contient la ligne suivante :

DisplayManager.authDir: /var/lib/xdm

Transfert du Cookie

Maintenant que vous avez lancé votre session X sur le serveur hôte light.uni.verse et que vous avez votre cookie dans ~/.Xauthority, il vous faut transférer le cookie sur le client, dark.matt.er. Il y a plusieurs façons de le faire.

Répertoires personnels (home) partagés

Le plus simple est que vos répertoires sur light et dark soient partagés. Les fichiers ~/.Xauthority sont les mêmes, donc le cookie est transféré instantanément. Cependant, il y a un piège : lorsque vous mettez un cookie pour :0 dans ~/.Xauthority, dark va croire que c'est un cookie pour lui au lieu de light. Il faut que vous utilisiez un nom d'hôte explicite à la création du cookie; on ne peut pas faire autrement. Vous pouvez installer le même cookie pour, à la fois, :0 et light:0 avec un peu d'astuce :

#!/bin/sh
mcookie|sed -e 's/^/add :0 . /' -e p -e "s/:/$HOST&/"|xauth -q
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"

En utilisant le shell à distance, rsh

Si les répertoires home ne sont pas partagés, vous pouvez transférer le cookie au moyen de rsh, le shell à distance :

light$ xauth nlist "${HOST}:0" | rsh dark.matt.er xauth nmerge -

  1. Extraire le cookie de votre fichier local ~/.Xauthority (xauth nlist :0).
  2. Le transférer vers dark.matt.er (| rsh dark.matt.er).
  3. >Le mettre dans ~/.Xauthority là (xauth nmerge -).

Notez l'utilisation de ${HOST}. Vous devez transférer le cookie qui est explicitement associé à l'hôte local. Une application X distante interpréterait une valeur d'unité d'affichage égale à :0 comme étant une référence à la machine distante, ce qui ne correspond pas à ce que l'on veut !

Manuellement, par Telnet

Il est possible que rsh ne fonctionne pas chez vous. En plus de cela, rsh a un inconvénient en ce qui concerne la sécurité (noms d'hôtes parodiés, si je me souviens bien). Si vous ne pouvez, ou ne voulez, pas utiliser rsh, vous pouvez également transférer le cookie manuellement, comme ceci :

light$ echo $DISPLAY
:0
light$ xauth list $DISPLAY
light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926
light$ rlogin dark.matt.er
Password:
dark% setenv DISPLAY light.uni.verse:0
dark% xauth
Using authority file /home/zweije/.Xauthority
xauth> add light.uni.verse:0 . 076aaecfd370fd2af6bb9f5550b26926
xauth> exit
Writing authority file /home/zweije/.Xauthority
dark% xfig &
[15332]
dark% logout
light$

Consultez également rsh(1) et xauth(1x) pour de plus amples informations.

En automatisant la méthode Telnet

Il doit être possible de superposer le cookie sur la variable TERM ou DISPLAY quand vous utilisez telnet sur l'hôte éloigné. Cela doit fonctionner de la même manière que de superposer la variable DISPLAY sur la variable TERM. Regardez la section 5 : Dire au Client. De mon point de vue, sur ce sujet, vous prenez vos responsabilités, mais cela m'intéresse si quelqu'un peut me confirmer ou m'infirmer cela.

Notez, cependant, qu'avec certains Unix les variables d'environnement peuvent être visibles par les autres et que que vous ne puissiez pas empêcher la visualisation du cookie dans $TERM si certains veulent le voir.

Utilisation du Cookie

Une application X, telle que xfig ci-dessus, sur dark.matt.er, ira automatiquement voir le cookie dans ~/.Xauthority pour s'authentifier.

L'utilisation de localhost:D entraîne une petite difficulté. Les applications X clientes traduisent localhost:D en host/unix:D pour effectuer la recherche du cookie. Effectivement, cela signifie qu'un cookie pour localhost:D dans votre ~/.Xauthority n'a aucun effet.

Si l'on y réfléchi, c'est logique. L'interprétation de localhost dépend entièrement de la machine sur laquelle s'effectue cette interprétation. Si ce n'était pas le cas, cela causerait un horrible bazar dans le cas d'un répertoire personnel (home) partagé, par exemple par l'intermédiaire de NFS, avec plusieurs hôtes interférants chacun avec ses propres cookies.

6.3 Ssh

Les enregistrements d'autorisation sont transmis sur le réseau sans codage. Si vous vous souciez de ce que l'on puisse espionner vos connexions, utilisez ssh, le shell sécurisé. Il effectuera des transmissions X sécurisées au moyen de connexions cryptées. De plus, il est génial pour d'autres choses aussi. C'est une bonne amélioration structurelle de votre système. Allez simplement voir http://www.ssh.org/, la page d'accueil de ssh.

Qui possède d'autres informations sur les méthodes d'authentification ou de cryptage des connexions X ? Peut-être Kerberos ?


Page suivante Page précédente Table des matières