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.
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
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.
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
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.
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 :
#!/bin/sh
cookie=`mcookie`
xauth add :0 . $cookie
xauth add "$HOST:0" . $cookie
exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority"
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 -
~/.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 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 add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926
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.
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é.
L'application X cliente peut traduire localhost:D en
host/unix:D pour les besoins de recherche du cookie.
Effectivement, cela signifie qu'un cookie pour localhost:D dans
votre ~/.Xauthority n'a aucun effet.
Les enregistrements d'autorisation sont transmis 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 voir simplement http://www.cs.hut.fi/ssh/, 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 ?