Utiliser des applications X distance

Utiliser des applications X à distance

Pour la plupart des utilisateurs Linux, XFree86 est tout simplement un système graphique Xwindow permettant de lancer des applications comme un gestionnaire de fenêtres ou encore des programmes comme Gimp, Konqueror et autres. Il s'agit d'une interface logicielle entre le matériel (carte graphique, pointeur, clavier) et des applications utilisant un mode graphique particulier. Mais Xwindow est surtout un serveur X, et qui dit serveur dit forcément réseau.

Xwindow est en effet un système conçu pour fonctionner en réseau. Il est ainsi possible de lancer une application sur une machine et de déporter l'affichage sur une autre. Xwindow permet cela de base avec un minimum d'effort de configuration. Mais attention, même si cela reste extrêmement pratique, il convient de ne pas perdre de vue l'aspect sécurité de la chose. On peut sans complexe comparer le support réseau d'Xfree à un telnet. Entendez par là qu'il est extrêmement dangereux d'ouvrir son serveur X sans prendre un minimum de précaution.

Cet article montrera tout d'abord la méthode par défaut qu'il ne faut pas utiliser puis nous nous pencherons sur les différentes techniques pour sécuriser l'ensemble à l'aide d'utilitaires adéquats.

Configuration de base
Nous considérerons, pour cet article, que nous possédons deux machines connectées toutes deux sur un LAN. Nous aurons :

- morgane dont l'adresse est 192.168.0.10 utilisant un XFree 3.3.6 ;
- egon dont l'adresse est 192.168.0.51 utilisant XFree 4.0.2.

Nous considérerons que morgane est la machine que nous configurerons en tant que serveur et egon en tant que client. Le but étant de déporter l'affichage des applications lancées sur egon vers le serveur X (et donc le moniteur) de morgane.

Ma méthode la plus simple pour permettre à egon d'utiliser l'affichage de morgane est tout simplement d'ajouter egon dans la liste des hôtes autorisé par morgane. Attention, ceci n'est pas une solution sûre ! Pour cela, nous n'avons qu'une commande à taper sur morgane :

$ xhost +egon

Nous utilisons ici une authentification basée sur le nom d'hôte du client. Il n'est absolument pas sécurisé de procéder de cette manière car une personne mal intentionnée pourrait se faire passer pour un hôte autorisé très facilement.

Sur egon (le client), nous avons plusieurs solutions qui utilisent la même syntaxe. Un serveur Xwindow est identifié par deux éléments, le nom de la machine sur laquelle il fonctionne et le numéro d'affichage ou plus simplement le display. Par défaut, lorsque vous lancez un serveur XFree sur votre système, il utilise le premier numéro disponible : 0. Votre serveur est donc accessible sous l'identification localhost:0.

Vous pouvez parfaitement lancer un second XFree en passant sur la ligne de commande un paramètre indiquant le nouveau display à créer. En omettant ce paramètre, le nouvel XFree tentera d'utiliser le display 0 et son exécution échouera :

Fatal server error :
Server is already active for display 0

Avec XFree 3.3.x, aussi bien qu'avec un 4.x.x, vous devrez utiliser :

$ startx -- :1

Vous allez ainsi créer un nouveau display (1) et pourrez basculer de l'un à l'autre à l'aide des touches Ctrl+Alt+7 et Ctrl+Alt+8. Vous aurez donc deux display à disposition : localhost:0 et localhost:1.

En ce qui concerne nos manipulations, le client egon devra donc utiliser morgane:0 pour déporter l'affichage des applications exécutées. La première technique consiste à spécifier le display à utiliser à l'aide d'une option sur la ligne de commande :

$ xeyes -display morgane:0

Vous devriez voir apparaître les magnifiques yeux suivant le pointeur de la souris sur morgane. Malheureusement, toutes les applications X ne proposent pas ce paramètre sur la ligne de commande. Dans ce genre de cas, il faudra se rabattre sur une solution universelle consistant à utiliser une variable d'environnement : DISPLAY. La syntaxe est la même que pour le paramètre en ligne de commande :

$ export DISPLAY=morgane:0

Dès lors, toutes les applications X que vous lancerez depuis egon verront leur affichage déporté sur morgane (display 0).

La commande xhost que nous avons utilisée un peu plus haut permet d'ajouter, mais également de lister ou de supprimer des hôtes de la liste des machines autorisées à utiliser les différents display :

$ xhost +nom_machine permet d'ajouter un hôte ;
$ xhost -nom_machine permet de supprimer une entrée dans la liste.

et

$ xhost permet de lister les entrées :

access control enabled, only authorized clients can connect
INET:egon

Il est également possible, mais fortement déconseillé, d'utiliser le symbole + seul afin d'autoriser n'importe quel client à se connecter, même s'il ne se trouve pas dans la liste. Inversement, le symbole - seul permet de limiter les clients aux seules entrées dans la liste.

xauth, un peu plus de sécurité
Il existe un moyen plus sûr d'autoriser des connexions à un serveur X. La technique qui va suivre n'est cependant valable que pour deux machines présentes sur un LAN sûr. Il est hors de question d'utiliser les manipulations qui vont suivre pour configurer deux machines se connectant via Internet. En effet, la méthode xauth utilise un secret partagé afin de garantir l'authentification des deux intervenants mais la communication reste en clair et quelqu'un pourrait parfaitement écouter (sniffer) les communications afin de récupérer le secret partagé. Nous verrons plus loin comment corriger ce problème.

Le schéma d'authentification est appelé MIT-MAGIC-COOKIE-1. Le secret partagé entre le client et le serveur est une chaîne de 128 bits, soit 32 caractères en hexadécimal. Cette chaîne est le MAGIC-COOKIE (littéralement, le gâteau magique). N'importe quelle chaîne de ce type pourra être utilisée. Un petit utilitaire appelé mcookie est sans doute présent dans votre système et permet de générer ce genre de chaîne. Une autre solution consiste à utiliser md5sum sur un fichier ou des données connues pour être parfaitement aléatoires.

xauth est un utilitaire vous permettant de gérer les MAGIC-COOKIES. Ceux-ci sont placés dans un fichier ~/.Xauthority mais ne sont lisibles que par l'intermédiaire de xauth. Votre configuration possède sans doute déjà des entrées dans ce fichier. La première étape consiste donc à lister le contenu du fichier avec la commande list de l'utilitaire xauth :

egon:~$ xauth
Using authority file /home/denis/.Xauthority
xauth> list
egon/unix:0 MIT-MAGIC-COOKIE-1 ebe773e811b6df842e18e7ebd26feaf6
egon:0 MIT-MAGIC-COOKIE-1 ebe773e811b6df842e18e7ebd26feaf6
egon/unix:1 MIT-MAGIC-COOKIE-1 bc8575f8eeb50d5adebde2f8aa2bdcde
egon:1 MIT-MAGIC-COOKIE-1 bc8575f8eeb50d5adebde2f8aa2bdcde
xauth>

Nous avons effectivement quatre entrées dans notre fichier. Pour nos tests, nous ne prendrons pas la peine de remplacer les entrées et les MAGIC-COOKIES par défaut par de nouveaux. Si vous comptez utiliser régulièrement le MIT-MAGIC-COOKIE-1, il est fortement conseillé de ne pas laisser les valeurs par défaut.

xauth est un utilitaire interactif. De la même manière que vous avez utilisé list pour lister les MAGIC-COOKIES, vous pouvez ajouter des entrées avec add, en supprimer avec remove, lire un fichier de commande avec source ou encore exporter le contenu du fichier .Xauthority sous une forme lisible avec extract. Ces commandes peuvent également être utilisées en tant qu'argument. Ces lignes sont équivalentes :

$ xauth
Using authority file /home/denis/.Xauthority
xauth> list

et

$ xauth list

Avant de modifier quoi que ce soit dans vos .Xauthority, retirez les entrées dans la liste des hôtes autorisés avec xhost -nom_machine. Il ne servirait à rien d'utiliser une méthode d'authentification plus sûre en laissant l'ancienne active.

Affichez ensuite les entrées de morgane avec xauth list. Celles qui nous intéressent concernent le display 0. Il est assez rare en effet de voir une machine exécuter plusieurs serveurs X autrement que pour des tests ou des manipulations exceptionnelles. Une entrée xauth est composée de 3 éléments séparés par des blancs :

- Le nom de display (dpyname). Celui-ci est composé de trois éléments : le nom d'hôte, la mention /unix et le numéro de display. La mention /unix est nécessaire afin de garder une compatibilité, voilà pourquoi les entrées sont répétées avec et sans le /unix.
- Le protocole. Il n'y a guère le choix ici, c'est MIT-MAGIC-COOKIE-1.
- Le cookie magique de l'hôte et du display en question.

Si nous désirons déporter l'affichage de nos applications exécutées sur egon vers morgane, nous devons ajouter deux entrées dans le .Xauthority d'egon :

$ xauth add morgane:0 MIT-MAGIC-COOKIE-1 3b0302b7b7a4bb53da1b378738bd8db0
$ xauth add morgane/unix:0 MIT-MAGIC-COOKIE-1 3b0302b7b7a4bb53da1b378738bd8db0

Dès lors, nous pouvons tester notre configuration depuis egon :

$ xeyes -display morgane:0

Et voilà !
Vous pouvez ainsi déporter l'affichage de vos applications de manière plus sûre qu'avec de simples entrées xhost. Ici, le pirate ne devra pas simplement tenter d'usurper l'identité d'une machine, mais il devra également posséder un exemplaire du MAGIC-COOKIE. Le problème principal de cette méthode est cependant que le MAGIC-COOKIE circule en clair sur le réseau. Pour preuve, il nous suffit d'utiliser dsniff n'importe où sur le même LAN pour immédiatement voir apparaître le MAGIC-COOKIE lorsqu'il est utilisé pour établir la connexion entre egon et morgane :

st_dsniff: listening on eth0
-----------------
09/24/01 13:38:05 tcp egon.1426 -> morgane.6000 (x11)
MIT-MAGIC-COOKIE-1 3b0302b7b7a4bb53da1b378738bd8db0

On voit clairement que egon envoie le MAGIC-COOKIE à morgane sur son port X (6000).

Sécuriser davantage
Nous venons de le constater, la sécurité apportée par MIT-MAGIC-COOKIE-1 n'est pas suffisante. Il nous faut protéger les données échangées entre les machines. Nous allons donc chiffrer les informations circulant entre nos machines.

Si vous avez l'habitude de vous connecter d'une machine sur une autre à travers Internet, vous connaissez sans doute le secure shell OpenSSH.

OpenSSH offre les mêmes facilités de connexion que la commande (à ne plus utiliser) rlogin. Vous pouvez ainsi ouvrir du shell distant en toute sécurité puisque non seulement le mot de passe de connexion est chiffré, mais également toutes les informations (entrées et sorties) circulant dans la connexion SSH. Heureusement pour nous, les concepteurs d'OpenSSH ont également prévu de faire transiter la connexion sécurisée toutes les informations permettant de déporter un affichage.

Du point de vue de la configuration (nous considérons ici que vous avez déjà sur les deux machines un ssh pleinement fonctionnel), vous n'avez qu'à modifier les fichiers de configuration du client et du serveur ssh de chaque machine en ajoutant :

- dans ssh_config (client) :
ForwardX11 yes

- dans sshd_config (serveur) :
X11Forwarding yes

Ces fichiers se trouvent normalement dans votre /etc/ssh ou dans /usr/local/etc. Après la modification, vous n'avez plus qu'à relancer les serveurs ssh des machines. Une simple connexion comme par exemple :

$ ssh -l utilisateur morgane

vous connectera à l'hôte distant de manière sécurisée et dans la session, vous n'aurez qu'à lancer votre application X. Son affichage sera alors automatiquement déporté vers la machine cliente et les information transiteront directement par le canal sécurisé ssh (port 22).

Pour ce petit miracle, aucune configuration supplémentaire n'est nécessaire. OpenSSH va créer lors de la connexion un MAGIC-COOKIE temporaire qu'il utilisera pour faire transiter les données X11. Vous pourrez le constater par vous même en utilisant xauth list dans la session ssh :

morgane$ ssh -l denis egon
denis@egon's password:

denis@egon:~$ xauth list
egon:10 MIT-MAGIC-COOKIE-1 b5737cde48f604a24706570a9c1772d6
egon/unix:10 MIT-MAGIC-COOKIE-1 b5737cde48f604a24706570a9c1772d6

denis@egon:~$ <CTRL-D>
morgane$ ssh -l denis egon
denis@egon's password:

denis@egon:~$ xauth list
egon:10 MIT-MAGIC-COOKIE-1 9d4155fc1a25b175d7f828d3a79cff7e
egon/unix:10 MIT-MAGIC-COOKIE-1 9d4155fc1a25b175d7f828d3a79cff7e

Comme vous pouvez le voir, un nouveau MAGIC-COOKIE est créé à chaque connexion du client OpenSSH. Au moment où le client se connecte, il va contrôler la présence d'un serveur X en fonction. Il va ensuite générer aléatoirement et ajouter un nouveau MAGIC-COOKIE dans le .Xauthority puis l'envoyer au serveur SSH. Ce dernier va alors l'ajouter au .Xauthority de la machine où tourne le serveur OpenSSH mais attention, cette machine est cliente pour l'affichage déporté.

Ici, pas de problème, l'échange des MAGIC-COOKIE se fait bien dans la connexion OpenSSH. Les données de l'affichage seront ensuite détournées par le serveur sshd pour passer dans le tunnel sécurisé. Aucune donnée ne circule en clair sur le réseau.

Seul problème de cette transparence pour l'utilisateur, on n'arrive pas à faire la différence entre un affichage déporté via OpenSSH et une connexion en clair. Il est donc à la charge de l'utilisateur de vérifier (par une lecture des fichiers de configuration ou via la commande xauth list) que les données circulent dans le bon tuyau.

Il est cependant nécessaire de préciser que la communication des données de l'affichage ne seront protégées que de l'extérieur des machines. En effet, comme l'explique Ulrich Flegel dans son papier "The Interaction between SSH and X11", une attaque est possible contre les données si celle-ci est portée par un utilisateur légitime de la machine serveur sshd (et client X11). Sur cette machine, il est parfaitement possible d'écouter les données circulant entre le client et le serveur et, dans ce cas, de compromettre la sécurité des informations visuelles manipulées par l'application déportant son affichage.

Il reste cependant assez rare que dans le cadre d'une utilisation courante (machine personnelle individuelle), on autorise d'autres utilisateurs à se connecter à nos machines. Et même dans ce cas, il s'agit habituellement d'utilisateurs (collègues) qui sont à portée de main pour d'éventuelles explications complémentaires concernant la sécurité d'un réseau.

En conclusion, même si vous prenez toutes les précaution nécessaires pour déporter l'affichage d'une application, vous serez obligé de faire des choix stratégiques quant aux applications à utiliser et ce, en fonction de votre environnement. En sécurisant les manipulations jusqu'à utiliser OpenSSH (ou d'autres méthode de tunneling), vous ne vous débarrasserez pas du plus gros problème : les attaques depuis l'intérieur de votre réseau ou de vos machines.

Liens
XFree86
http://www.xfree86.org/

Remote X Apps mini-HOWTO
http://www.ibiblio.org/pub/Linux/docs/HOWTO/mini/other-formats/html_single/Remote-X-Apps.html

SSH Frequently Asked Questions
http://www.employees.org/~satch/ssh/faq/

"The Interaction between SSH and X11" par Ulrich Flegel
http://www.artsoft.com.br/linux/ldpp/en/app/ssh-x11.pdf

Copyright (c) Linux Magazine France

Permission vous est donn�e de distribuer des copies exactes de cette page tant que cette note de permission et le copyright apparaissent clairement.