User Tools

Site Tools


securite:securite-xauth

Sécurité: protection des serveurs X

Xauth

xauth est un mécanisme permettant d'appliquer des contrôles d'accès sur des serveurs X (écrans).

Lorsqu'un serveur X est démarré, un “cookie” généré de manière aléatoire lui est attribué. Ce cookie est écrit dans un fichier détenu et lisible par l'utilisateur dont la session est en cours d'exécution sur le serveur X. Aucun autre utilisateur ne peut lire ce fichier.

Lorsqu'un client X (application) est démarré, il tente de lire et d'utiliser le cookie pour s'authentifier auprès du serveur. Si cette authentification xauth échoue, l'application n'est pas autorisée à se connecter au serveur et à afficher des fenêtres sur l'affichage X.

Le fichier .Xauthority est généré par le programme xauth. Il s'agit d'un système d'authentification pour les applications graphiques. Cela permet d'éviter que d'autres personnes envoient des images, des fenêtres sur votre écran - mais également que des personnes puissent “voir” ce qu'il y a sur votre écran.

Consultation des cookies

La commande xauth list permet d'affiche les cookies disponibles pour la session en cours:

$ xauth list
xfce/unix:0  MIT-MAGIC-COOKIE-1  e38904001366110fd8ef72c4d483ca4a
xx.xx.xxx.xx:0  MIT-MAGIC-COOKIE-1  c3b321e93d509eb3bac60c9a61370b2b

Traditionnellement, l'emplacement des cookies de chaque utilisateur a été ~/.Xauthority: le serveur X écrit ses cookies dans ce fichier au démarrage, et xauth (ainsi que d'autres clients X) recherchent dans ce fichier des cookies d'authentification.

Génération du fichier .Xauthority

Le principe est de donner une clef d'identification, en hexadécimal avec un nombre pair de caractères.

Lancer xauth et faire :

add MaMachine:0 MIT-MAGIC-COOKIE-1 MonCode
add MaMachine/unix:0 MIT-MAGIC-COOKIE-1 MonCode

Pour la machine locale, c'est en fait “hostname:NoDisplay”.

Un fois lancé, le serveur X interdit toute connexion, sauf si l'application :

  • est exécutée sur une machine référencée ;
  • possède le code.

On peut désactiver le système pour certaines machines avec un xhost +toto par exemple.

Certaines versions obligent à lancer le serveur X avec la commande suivante:

xinit -- -auth $HOME/.Xauthority

Sécurisation des connexions

Utilisation de $XAUTHORITY

Afin de se connecter à un serveur X et ouvrir une application client X sur l'affichage distant, il faut disposer des cookies xauth appropriés. Afin de sécuriser le serveur X il ne faut pas utiliser ~/.Xauthority comme emplacement pour les cookies. Au lieu de cela, on les place dans /tmp/.<Séquence-aléatoire-de-lettres>, puis on définit la variable d'environnement $XAUTHORITY pour indiquer à xauth où le rechercher. Cette variable d'environnement n'est visible que pour les applications lancées à partir de l'environnement X local. Par conséquent, seul l'utilisateur local qui “possède” actuellement l'affichage X peut savoir avec certitude l'emplacement du fichier approprié. Il ne peut le faire qu'à partir de l'affichage X.

  • Renommer le fichier .Xauthority existant en exécutant la commande suivante
mv .Xauthority old.Xauthority
  • Créer le repertoire /tmp/<Séquence-aléatoire-de-lettres>
mkdir /tmp/.xth-$(xxd -l 16 -p /dev/urandom)
  • Récupérer le chemin du répertoire ainsi créé
ls /tmp -al

drwxrwxr-x 1 jacques.nougat jacques.nougat    0 juil.  3 12:51 .xth-3bcd598058f6b8455458648a7a628b97
  • Créer le fichier .Xauthority existe
touch /tmp/.xth-3bcd598058f6b8455458648a7a628b97/.Xauthority
  • Définir la variable d'environnement $XAUTHORITY
export XAUTHORITY=/tmp/.xth-3bcd598058f6b8455458648a7a628b97/.Xauthority 
  • Générer le clef pour le domaine socket unix (seule cette clé est nécessaire pour X11 sur SSH)
xauth generate :0 . trusted
  • générer une nouvelle clé, xauth nécessite un encodage hex 128 bits
xauth add x.x.x.x:0 . $(xxd -l 16 -p /dev/urandom)

Afin d'autoriser sous ssh le serveur X depuis l'extérieur et exécuter une application X sur l'affichage, il faut définir $XAUTHORITY pour qu'il pointe vers ce fichier permetant aux applications client X de se connecter au serveur X et de l'utiliser.

Contrôle de la session

Seul xdm assure un contrôle de session X Window correct. La directive DontZap, placée dans la section ServerFlags du fichier de configuration de XFree86 limite aussi les possibilités de gourance.

Si on n'emploie pas xdm : afin d'interdire aux malintentionnés d'utiliser les touches de “basculement” des consoles virtuelles (Alt-F1, Alt-F2 …) il suffit de placer dans /etc/profile une ligne :

alias x='(startx >/dev/null &);clear;logout'

Puis d'invoquer x en lieu et place de startx.

Protection de la machine contre l'extérieur

Une solution pour éviter les connexions externes est d'utiliser TCP/Wrappers. Il est très fortement conseillé de le recompiler !

L'installation est assez intuitive. En bref, il suffit d'indiquer le nom des machines autorisées dans le fichier /etc/hosts.allow et les machines interdites dans /etc/hosts.deny. On peut permettre l'envoi de courrier lorsqu'une machine tente de se connecter alors qu'elle est interdite en mettant par exemple dans le fichier /etc/hosts.deny:

wu.ftpd:        ALL: twist = /usr/sbin/real-daemon-dir/safe_finger -l @%h |/bin/mail -s %d-%h root
securite/securite-xauth.txt · Last modified: 2025/02/19 10:59 by 127.0.0.1