12. term et la sécurité

Contenu de cette section

Dans cette partie sont évoqués certains des aspects de la sécurité de term. Les problèmes y sont évoqués et des moyens d'accroître la sécurité sont donnés.

12.1 trsh

trsh pose des problèmes de sécurité lorsqu'il est utilisé pour accéder à la machine locale depuis le système distant. Le problème posé par term de ses clients est qu'en plus du propriétaire de la connexion term, root peut lancer, par l'intermédiaire de la connexion des programmes modifiés pour term.

Ceci implique en particulier que le root du système distant peut lancer trsh et donc se faire passer pour le propriétaire de la connexion term assez facilement. Si cet utilisateur sur la machine locale est root, les risques encourus sont considérables.

La solution à ce problème est simple~: il vous suffit d'ajouter la ligne suivante dans le fichier 'termrc', sur la machine locale~:

  denyrsh on

Cette ligne indique que personne ne peut lancer de trsh sur votre machine depuis le système distant. L'accès à votre machine est cependant encore possible par l'intermédiaire de la connexion term, en utilisant telnet et les ports redirigés.

12.2 txconn et xauth

txconn n'est pas particulièrement sûr. N'importe qui peut se connecter à votre serveur local par l'intermédiaire de term et se livrer à toutes sortes d'exactions. Si ce genre de problèmes vous inquiète, il est conseillé d'utiliser xauth pour autoriser vos connexions. Un exemple de l'utilisation de xauth pour sécuriser vos connexions est donné dans la partie suivante.

12.3 sxpc, xhost et xauth

L'utilisation de xauth est très importante pour assurer la sécurité lorsque vous utilisez sxpc. Si vous n'utilisez pas xauth en conjonction avec sxpc, tous les risques d'un xhost + s'appliquent. Entre autres, ils sont les suivants~:

xauth est fourni avec X depuis la R4. Nous décrivons ici comment en mettre en place une utilisation de base. Attention, cette configuration est vulnérable au snooping.

NOTE~: lorsque vous utilisez xauth, votre variable d'environnement $DISPLAY ne doit PAS être positionnée sur localhost (ou localhost:quelquechose). Si votre variable d'environnement $DISPLAY utilise localhost, les clients seront incapables de trouver les informations d'autorisation adéquates. La solution est d'utiliser le nom réel de la machine. Si vous suivez les instructions de compilation contenues dans le fichier 'README' et compilez sans l'option -DNOGETHOSTNAME, tout devrait fonctionner correctement.

Appelons C la machine sur laquelle vous allez lancer les clients et D celle sur laquelle ils seront affichés.

Tout d'abord, choisissez une clé composée d'au plus 16 couples de chiffres hexadécimaux (c'est-à-dire un nombre pair de caractères compris entre 0 et 9 et a et f). Dans l'exemple qui suit, il vous faudra remplacer <clé> par sa valeur.

Sur C~:

  % xauth
  xauth:  creating new authority file $HOME/.Xauthority
  Using authority file $HOME/.Xauthority
  xauth> add Chostname:8 MIT-MAGIC-COOKIE-1 <cle>
  xauth> exit

Sur D~:

  % xauth
  xauth:  creating new authority file $HOME/.Xauthority
  Using authority file $HOME/.Xauthority
  xauth> add Dhostname/unix:0 MIT-MAGIC-COOKIE-1 <cle>
  xauth> add Dhostname:0 MIT-MAGIC-COOKIE-1 <cle>
  xauth> exit

Lorsque vous lancez le serveur X sur D, il faut alors lui passer le paramètre -auth $HOME/.Xauthority. Peut-être vous faudra-t-il créer ou modifier le fichier '$HOME/.xserverrc' pour contrôler la façon dont le serveur X est lancé. Par exemple~:

  #!/bin/sh
  exec X -auth $HOME/.Xauthority $*

Assurez-vous que votre fichier '.Xauthority' n'est accessible en lecture que par vous, à la fois sur C et sur D.

Chapitre suivant, Chapitre Précédent

Table des matières de ce chapitre, Table des matières générale

Début du document, Début de ce chapitre