test

Manuel de l'Utilisateur Expérimenté Solaris

Précisions relatives à la sécurité

Cette section traite de certains aspects fondamentaux de la sécurité réseau qui peuvent se révéler utiles lorsque vous exécutez des applications en réseau, à savoir :

A qui s'adresse cette section ?

Vous n'avez pas à modifier la configuration de sécurité par défaut du logiciel OpenWindows Version 3.3 ou ultérieures, à moins que vous n'utilisiez l'une des configurations suivantes :

Mécanismes de contrôle d'accès

Un mécanisme de contrôle d'accès est une procédure visant à déterminer quels clients ou applications auront accès au serveur X11. Seuls les clients disposant des droits appropriés pourront se connecter au serveur ; tous les autres se verront refuser l'accès par le message d'erreur suivant : 

Xlib: connection to nom_machjne refused by server
Xlib: Client is not authorized to connect to server

La tentative de connexion s'affiche dans la console du serveur sous la forme suivante :

AUDIT: <Date Time Year>: X: client 6 rejected from IP 129.144.152.193
port 3485
	Auth name: MIT-MAGIC-COOKIE-1

Il existe deux types de mécanisme de contrôle d'accès, l'un étant basé sur l'utilisateur et l'autre sur la machine. (Le premier attribue l'accès à un compte utilisateur, le second à une machine spécifique.) A moins que vous n'ayez utilisé l'option -noauth avec openwin, ces mécanismes de contrôle d'accès sont tous les deux actifs. Pour plus d'informations, consultez la section "Gestion de l'accès au serveur "", dans le présent chapitre.

Accès basé sur l'utilisateur

Le mécanisme de contrôle d'accès basé sur l'utilisateur, ou sur les droits, vous permet d'attribuer des droits explicites à un utilisateur donné sur une machine donnée. Le client de cet utilisateur transmet au serveur les données d'attribution de droits. Si ces données sont conformes à celles du serveur, l'utilisateur est autorisé à se connecter.

Accès basé sur la machine

Le mécanisme de contrôle d'accès basé sur la machine est un mécanisme général qui vous donne accès à une machine spécifique, depuis laquelle tous les utilisateurs peuvent se connecter au serveur. C'est une forme de contrôle d'accès plus souple : si la machine a accès au serveur, tous ses utilisateurs sont également autorisés à s'y connecter.

L'environnement Solaris fournit le mécanisme assurant la compatibilité ascendante. Les applications générées avec les versions de Xlib ou libcps antérieures à OpenWindows Version 2 ou à X11R4 ne reconnaissent pas le nouveau mécanisme de contrôle d'accès basé sur l'utilisateur. Pour permettre à ces applications d'accéder au serveur, l'utilisateur doit sélectionner le mécanisme basé sur la machine ou générer l'application à nouveau avec des versions plus récentes de Xlib et de libcps.

Remarque :

les clients de versions antérieures de Xlib ou de libcps doivent, si possible, être générés à nouveau avec des versions plus récentes de ces bibliothèques pour pouvoir se connecter au serveur via le nouveau mécanisme de contrôle d'accès basé sur l'utilisateur.

Protocoles d'attribution de droits

La présente version du logiciel OpenWindows supporte deux protocoles d'attribution de droits, MIT-MAGIC-COOKIE-1 et SUN-DES-1, qui diffèrent par leurs types de données, mais utilisent, en revanche, le même mécanisme de contrôle d'accès. Le serveur ne peut mettre en oeuvre qu'un protocole à la fois. MIT-MAGIC-COOKIE-1, qui fait appel au mécanisme basé sur l'utilisateur, est le protocole par défaut du logiciel OpenWindows.

MIT-MAGIC-COOKIE-1

Le protocole d'attribution de droits (ou d'autorisation) MIT-MAGIC-COOKIE-1 a été développé par le Massachusetts Institute of Technology. Au démarrage du serveur, un "magic cookie" est attribué à ce dernier et à l'utilisateur qui a initialisé le système. A chaque tentative de connexion, le client de cet utilisateur envoie au serveur le "magic cookie" avec le paquet de connexion, pour comparaison avec celui du serveur. Si les deux "magic cookies" sont identiques, la connexion est établie ; sinon, elle est refusée.

SUN-DES-1

Développé par Sun Microsystems, le protocole d'attribution de droits SUN-DES-1 est basé sur l'appel de procédure distante sécurisé (Secure RPC) et requiert l'algorithme de chiffrement de données DES (Data Encryption Software). Les droits d'accès sont basés sur l'identité réseau de l'utilisateur, indépendamment de la machine utilisée. Cette information est chiffrée et envoyée au serveur avec le paquet de connexion. Le serveur décrypte l'information et, s'il reconnaît l'identité réseau, autorise la connexion.

Ce protocole offre un niveau de sécurité plus élevé que le protocole MIT-MAGIC-COOKIE-1. En aucun cas, un autre utilisateur ne peut accéder au serveur sous votre identité réseau, alors qu'il peut le faire avec le "magic cookie".

Ce protocole est disponible uniquement dans les bibliothèques OpenWindows Version 3 et environnements ultérieurs. Toute application construite avec des bibliothèques statiques, notamment Xlib, dans des environnements antérieurs à OpenWindows Version 3 ne peuvent faire appel à ce protocole d'attribution de droits d'accès.

La section"Attribution des droits d'accès à l'aide du protocole SUN-DES-1 "" du présent chapitre explique comment permettre à d'autres utilisateurs d'accéder à votre serveur en ajoutant leur nom sur la liste d'accès du serveur.

Modification du protocole d'attribution de droits par défaut

Vous pouvez remplacer le protocole d'attribution de droits par défaut, MIT-MAGIC-COOKIE-1, par SUN_DES-1, l'autre protocole supporté, ou encore ne spécifier aucun mécanisme de contrôle d'accès basé sur l'utilisateur. Il suffit pour cela d'indiquer des options avec la commande openwin. Par exemple, pour remplacer le protocole par défaut MIT-MAGIC-COOKIE-1 par SUN-DES-1, lancez le logiciel OpenWindows de la façon suivante : 

exemple% openwin -auth sun-des

Pour exécuter OpenWindows sans le mécanisme de contrôle d'accès basé sur l'utilisateur, servez-vous de l'option de ligne de commande -noauth : 

exemple% openwin -noauth

Attention : Attention :

Graphic l'option -noauth réduit le niveau de sécurité. Elle revient à exécuter OpenWindows avec le mécanisme de contrôle d'accès basé sur la machine seulement puisque le mécanisme basé sur l'utilisateur est désactivé par le serveur. Par conséquent, quiconque peut exécuter des applications sur votre machine a accès également à votre serveur.

Gestion de l'accès au serveur

A moins que vous n'utilisiez l'option -noauth avec l'option openwin (voir la section "Modification du protocole d'attribution de droits par défaut ""), le mécanisme de contrôle d'accès basé sur l'utilisateur et le mécanisme basé sur la machine sont tous les deux actifs. Le serveur commence par contrôler le mécanisme basé sur l'utilisateur, puis le mécanisme basé sur la machine. La configuration de sécurité par défaut utilise MIT-MAGIC-COOKIE-1 comme mécanisme basé sur l'utilisateur et une liste vide comme mécanisme basé sur la machine. Seul le mécanisme basé sur l'utilisateur est donc réellement actif. L'option -noauth commande au serveur de désactiver le mécanisme de contrôle d'accès basé sur l'utilisateur et initialise la liste de controle d'accès basé sur la machine en y ajoutant la machine.

Deux programmes permettent de modifier le mécanisme de contrôle d'accès du serveur : xhost et xauth. Ces programmes accèdent à des fichiers binaires créés par le protocole d'attribution de droits et contenant des données d'attribution de droits spécifiques à la session. L'un de ces fichiers est destiné uniquement au serveur, tandis que l'autre réside dans le répertoire $HOME de l'utilisateur :

Vous devez utiliser le programme xhost pour modifier la liste de contrôle d'accès basé sur la machine du serveur. Vous pouvez y ajouter des machines, ou en supprimer. Si vous utilisez la configuration par défaut (liste vide) et que vous ajoutez un nom de machine à l'aide de xhost, vous réduirez le niveau de sécurité. Le serveur autorisera alors l'accès à la machine que vous avez ajoutée et à tous les utilisateurs précisant le protocole d'attribution de droits par défaut. La section "Accès basé sur la machine"" explique pourquoi le mécanisme de contrôle d'accès basé sur la machine offre un niveau de sécurité moindre.

Le programme xauth accède aux données du protocole d'attribution de droits via le fichier .Xauthority. Vous pouvez extraire ces informations de votre fichier.Xauthority pour les faire fusionner avec les données du fichier .Xauthority d'un autre utilisateur et permettre à ce dernier d'accéder à votre serveur ou au serveur auquel vous êtes connecté.

Voir la section "Attribution des droits d'accès à l'aide du protocole MIT-MAGIC-COOKIE-1 "" pour obtenir des exemples d'utilisation de xhost et xauth.

Fichier de droits client

Le fichier de droits client, .Xauthority, contient des entrées du type : 

connection-protocol          auth-protocol          auth-data

Par défaut, .Xauthority contient MIT-MAGIC-COOKIE-1 comme protocole d'attribution de droits et les entrées associées à l'écran local comme protocole de connexion et données d'attribution de droits. Par exemple, sur la machine anyhost, le fichier.Xauthority peut comporter les entrées suivantes : 

anyhost:0      MIT-MAGIC-COOKIE-1  82744f2c4850b03fce7ae47176e75localhost:0    MIT-MAGIC-COOKIE-1
 82744f2c4850b03fce7ae47176e75anyhost/unix:0 MIT-MAGIC-COOKIE-182744f2c4850b03fce7ae47176e75

Au démarrage du client, une entrée correspondant au protocole de connexion est lue dans .Xauthority et les protocole et données d'attribution de droits sont envoyés au serveur avec le paquet de connexion. Dans la configuration par défaut, xhost génère des listes vides de contrôle d'accès basé sur la machine et déclarent que les droits sont accordés.

Si vous avez remplacé le protocole d'attribution de droits par défaut par SUN-DES-1, les entrées de .Xauthority contiennent SUN-DES-1 comme protocole d'attribution de droits et l'identité réseau de l'utilisateur comme données d'attribution de droits. L'identité réseau présente le format suivant : 

unix.ID_utilisateur@NISnom_domaine

Par exemple, sur la machine anyhost, le fichier .Xauthority peut comporter les entrées suivantes, où unix.15339@EBB.Eng.Sun.COM désigne l'identité réseau de l'utilisateur indépendante de la machine :

anyhost:0        SUN-DES-1            "unix.15339@EBB.Eng.Sun.COM"
localhost:0      SUN-DES-1            "unix.15339@EBB.Eng.Sun.COM"
anyhost/unix:0   SUN-DES-1            "unix.15339@EBB.Eng.Sun.COM"

Remarque :

si vous ne connaissez pas votre identité réseau ou identité réseau indépendante de la machine, contactez votre administrateur système.

Attribution des droits d'accès à l'aide du protocole MIT-MAGIC-COOKIE-1

Si vous utilisez le protocole d'attribution de droits MIT-MAGIC-COOKIE-1, suivez les étapes ci-après pour permettre à un autre utilisateur d'accéder à votre serveur :

  1. Sur la machine qui exploite le serveur, utilisez xauth pour extraire une entrée correspondant à nom_machine:0 dans un fichier.

    Dans cet exemple, nom_machine correspond à anyhost et le fichier s'appelle xauth.info : 

    myhost% /usr/openwin/bin/xauth nextract
- anyhost:0 > $HOME/xauth.info

  2. Envoyez le fichier contenant l'entrée associée à l'utilisateur qui a émis la demande d'accès (en utilisant la Messagerie, rcp ou une autre méthode de transfert de fichiers).

    Remarque :

    il est plus prudent d'envoyer le fichier contenant les informations sur l'attribution des droits à l'aide de la Messagerie qu'avec la commande rcp. Si vous utilisez rcp, évitez de placer le fichier dans un répertoire facilement accessible par un autre utilisateur.

  3. L'autre utilisateur doit faire fusionner cette entrée dans son fichier .Xauthority.

    Dans cet exemple, la machine_utilisateur fait fusionner xauth.info dans le fichier .Xauthority de l'autre utilisateur :

    userhost% /usr/openwin/bin/xauth nmerge - < xauth.info

    Remarque :

    les données d'attribution de droits sont spécifiques à la session en cours. Elles sont donc valables jusqu'à la réinitialisation du serveur.

Attribution des droits d'accès à l'aide du protocole SUN-DES-1

Si vous utilisez le protocole d'attribution de droits SUN-DES-1, suivez les étapes ci-après pour permettre à un autre utilisateur d'accéder à votre serveur :

  1. Sur la machine qui exploite le serveur, utilisez xhost pour déclarer le nouvel utilisateur au serveur.

    Dans cet exemple, le nouvel utilisateur quidam est autorisé à accéder à ma_machine:

    myhost% xhost + quidam@

  2. Le nouvel utilisateur doit utiliser xauth pour ajouter l'entrée dans son fichier .Xauthority.

    Dans cet exemple, l'identité réseau indépendante de la machine du nouvel utilisateur est unix.15339@EBB.Eng.Sun.COM. Notez que cette commande doit être tapée sur une seule ligne, sans retour chariot. A la suite du symbole pipe, tapez un espace suivi du reste de la commande. 

    userhost% echo 'add nom_mach:0 SUN-DES-1 "unix.15339@EBB.Eng.Sun.COM"' | $OPENWINHOME/bin/xauth

Exécution de clients sous une autre identité, à distance ou en mode local

Les clients X utilisent la valeur de la variable d'environnement DISPLAY pour déterminer le nom du serveur auquel ils doivent se connecter.

Pour exécuter des clients sous une autre identité, que ce soit à distance ou en mode local, suivez les étapes ci-après :

  1. Sur la machine exploitant le serveur, attribuez des droits d'accès à un autre utilisateur.

    Selon le protocole d'attribution de droits utilisé, suivez la procédure décrite dans la section "Attribution des droits d'accès à l'aide du protocole MIT-MAGIC-COOKIE-1 "".

  2. Attribuez comme valeur à DISPLAY le nom de la machine exploitant le serveur.

    Dans cet exemple, la machine est désignée par machine_distante : 

    myhost% setenv DISPLAY machine_distante:0

  3. Exécutez le programme client comme indiqué. 

    myhost% client_program&

    Le client s'affiche sur la machine distante, machine_distante.