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.
Veuillez noter que certains serveurs X (de XFree86) peuvent être configurés
pour ne pas écouter sur le port habituel TCP avec le paramètre
-nolisten tcp. La configuration par défaut de Debian GNU/Linux,
notamment, désactive l'écoute sur le port TCP par le serveur X. Si vous
désirez utiliser X à distance sur un système Debian, vous devriez réactiver
ceci en modifiant la façon dont est lancé le serveur X. Veuillez voir le
fichier /etc/X11/xinit/xserverrc pour un point de départ.
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).
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
ensemble dans ~/.Xauthority. Votre fichier
~/.Xauthority doit être inaccessible pour les utilisateurs
groupe/autres. Le programme xauth gère ces cookies, d'où le surnom xauth dans
ce schéma.
Vous pouvez spécifier un fichier cookie différent avec la variable
d'environnement XAUTHORITY, mais vous aurez rarement besoin de le
faire. Si vous ne savez pas quel fichier cookie votre xauth utilise, faites
un xauth -v et il vous l'indiquera.
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.
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 paquet util-linux, site primaire
ftp://ftp.win.tue.nl/pub/linux-local/utils/util-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 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 informations.
Par exemple, mon /etc/X11/xdm/xdm-config
contient la ligne suivante :
DisplayManager.authDir: /var/lib/xdm
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.
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"
rshSi 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 -
~/.Xauthority
(xauth nlist :0).
| rsh dark.matt.er).
~/.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 !
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 usurpé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.
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 vous ne pourrez pas empêcher la
visualisation du cookie dans $TERM si certains veulent le voir.
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échit, 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érant chacun avec ses propres cookies.
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 chiffrées.
Pour activer la transmission X par ssh, utilisez l'option de la ligne de
commande -X ou écrivez ce qui suit dans votre fichier local de
configuration de ssh :
Host remote.host.name
ForwardX11 yes
Le serveur ssh (sshd) du côté distant positionnera automatiquement la
variable DISPLAY sur l'extrémité du tunnel X transmis. Le tunnel
distant récupère son propre cookie ; le serveur ssh distant le génère
pour vous et le place dans ~/.Xauthority là-bas. Ainsi,
l'autorisation X avec ssh est complètement automatique.
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.
Si vous possédez d'autres informations sur les méthodes d'authentification ou de chiffrement des connexions X, par exemple, grâce à Kerberos, envoyez-les moi, je les intégrerai ici.