test

Guía avanzada del usuario

Más acerca de la seguridad

Esta sección describe algunos conceptos fundamentales referentes a la seguridad de la red que podría encontrar útiles a medida que ejecute aplicaciones en la red, incluyendo:

Quién debe leer esta sección

La configuración de seguridad predeterminada en el software de la Versión 3.3 de OpenWindows, o versiones posteriores, no necesita cambiarse excepto si ejecuta aplicaciones en alguna de las configuraciones siguientes:

Mecanismos de control de acceso

Un mecanismo de control de acceso controla qué clientes o aplicaciones tienen acceso al servidor X11. Sólo a los clientes debidamente autorizados pueden conectar con el servidor; al resto se les deniega el acceso, y se termina el intento de conexión, enviándoles el siguiente mensaje de error. 

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

El intento de conexión se registra en la consola del servidor como:

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

Hay dos tipos diferentes de mecanismos de control de acceso: basado en el usuario y basado en el computador principal. Es decir, un mecanismo garantiza el acceso a una cuenta de usuario determinada, mientras que el otro garantiza el acceso a un computador principal o sistema particular. A no ser que la opción -noauth se utilice con el comando openwin, estarán activos tanto el mecanismo de control basado en el usuario como el basado en el computador principal. Si desea más información, consulte "Manipulación del acceso al servidor"" en este capítulo.

Acceso basado en el usuario

Un mecanismo basado en el usuario, o basado en la autorización le permite conceder acceso explícito a un usuario determinado de cualquier sistema principal. El sistema cliente de ese usuario pasará los datos de autorización al servidor. Si dichos datos coinciden con los datos de autorización del servidor, al usuario se le permitirá el acceso.

Acceso basado en el computador principal

Un mecanismo basado en el computador principal es un mecanismo de uso general. Le permite conceder el acceso a un computador principal determinado, de forma que todos los usuarios de dicho computador principal puedan conectar con el servidor. Es el método más impreciso para controlar el acceso: si ese computador principal tiene acceso al servidor, entonces todos los usuarios de dicho computador principal podrán conectar con el servidor.

El entorno Solaris proporciona el mecanismo basado en el computador principal para ofrecer compatibilidad con el software anterior. Las aplicaciones enlazadas con versiones de Xlib o de libcps anteriores al software de la Versión 2 de OpenWindows o X11R4 no reconocen al nuevo mecanismo de control de acceso basado en el usuario. Para permitir que estas aplicaciones se puedan conectar con el servidor, un usuario deberá cambiar al mecanismo de control basado en el computador principal, o bien reenlazar con las nuevas versiones de Xlib y de libcps.

Nota -

Si fuera posible, las aplicaciones clientes enlazadas con versiones anteriores de Xlib o de libcps deberían reenlazarse con las nuevas versiones de estas bibliotecas para permitir la conexión con el servidor utilizando el nuevo mecanismo de control de acceso basado en el usuario.

Protocolos de autorización

En esta versión del software OpenWindows se soportan dos protocolos de autorización: MIT-MAGIC-COOKIE-1 y SUN-DES-1. Se diferencian en los datos de autorización que utilizan, y se parecen en el mecanismo de control de acceso que usan. En todo momento, el servidor implementa únicamente un protocolo. El protocolo MIT-MAGIC-COOKIE-1 con el mecanismo de control basado en el usuario es la opción predeterminada del software de OpenWindows.

MIT-MAGIC-COOKIE-1

El protocolo de autorización MIT-MAGIC-COOKIE-1 se desarrolló en el Instituto de Tecnología de Massachusetts. En el inicio del servidor, se crea un magic cookie para el servidor y el usuario que empezó el sistema. En cada intento de conexión, el sistema cliente del usuario envía el magic cookie al servidor formando parte del paquete de conexión. Este magic cookie se compara con el magic cookie del servidor. Se permite la conexión si los magic cookies coinciden, o se deniega si no coinciden.

SUN-DES-1

El protocolo de autorización SUN-DES-1, desarrollado por Sun Microsystems, está basado en Secure RPC (abreviatura de Remote Procedure Call; Llamada a Procedimiento Remoto) y requiere soporte DES (abreviatura de Data Encryption Software; Software de Cifrado de Datos). La información de autorización consiste en el netname, o nombre de red de un usuario, que es independiente del sistema. Esta información es cifrada y enviada al servidor, formando parte del paquete de conexión. El servidor descifra la información, y si el nombre de red es conocido, se permite la conexión.

Este protocolo ofrece un mayor nivel de seguridad que el protocolo MIT-MAGIC-COOKIE-1. Ningún usuario puede utilizar el nombre de red independiente del sistema para acceder al servidor, sin embargo es posible que otro usuario utilice el magic cookie para acceder al servidor.

Este protocolo sólo está disponible en las bibliotecas de la Versión 3 de OpenWindows y versiones posteriores. Todas las aplicaciones construidas con bibliotecas estáticas, en particular Xlib, en los entornos anteriores a la Versión 3 de OpenWindows no pueden utilizar este protocolo de autorización.

El apartado "Cómo permitir el acceso cuando se utilice SUN-DES-1 "", de este capítulo, explica cómo permitir el acceso al servidor para otro usuario, añadiendo el el nombre de red de ellos a la lista de acceso del servidor.

Cómo cambiar el protocolo de autorización predeterminado

El protocolo de autorización predeterminado, MIT-MAGIC-COOKIE-1, puede cambiarse a SUN_DES-1, el otro protocolo de autorización soportado, o bien cambiar para no utilizar ningún mecanismo de control de acceso basado en el usuario. Puede cambiar el valor predeterminado mediante opciones del comando openwin. Por ejemplo, para cambiar el valor predeterminado de MIT-MAGIC-COOKIE-1 a SUN-DES-1, empiece el software OpenWindows de esta forma: 

ejemplo% openwin -auth sun-des

Si tiene que ejecutar el software OpenWindows sin mecanismo de acceso basado en el usuario, utilice la opción-noauth en la línea de comando: 

example% openwin -noauth

Precaución - Precaución -

GraphicSi utiliza -noauth se debilita la seguridad. Es equivalente a ejecutar el software OpenWindows únicamente con el mecanismo de control de acceso basado en el computador principal; el servidor desactiva el mecanismo de control de acceso basado en el usuario. Cualquier persona que pueda ejecutar aplicaciones en el sistema local del usuario, tendrá permiso de acceso al servidor.

Manipulación del acceso al servidor

A no ser que la opción -noauth se utilice con openwin (consulte "Cómo cambiar el protocolo de autorización predeterminado""), estarán activos tanto el mecanismo de control de acceso basado en el usuario como el basado en el computador principal. El servidor verifica primero el mecanismo basado en el usuario, y a continuación el mecanismo basado en el computador principal. La configuración de seguridad predeterminada utiliza MIT-MAGIC-COOKIE-1 como el mecanismo basado en el usuario, y una lista vacía como el mecanismo de control basado en el computador principal. Debido a que la lista basada en el computador principal está vacía, únicamente será efectivo el mecanismo basado en el usuario. La utilización de la opción -noauth le ordena al servidor que desactive el mecanismo de control de acceso basado en el usuario, e inicializa la lista basada en el computador principal, agregando el computador principal local.

Para cambiar el mecanismo de control de acceso al servidor puede utilizar dos programas: xhost y xauth.Para más información, consulte las páginas del comando man. Estos programas acceden a dos archivos binarios creados por el protocolo de autorización. Estos archivos contienen datos de autorización específicos de la sesión. Un archivo es de uso interno del servidor, y el otro está colocado en el directorio $HOME del usuario: 

.Xauthority

Archivo de autorización del cliente

Utilice los programas xhost y xauth para cambiar en el servidor la lista de acceso basada en el computador principal. Puede agregar o borrar computadores principales de la lista de acceso. Si ha empezado con la configuración predeterminada -con la lista de acceso basada en el computador principal que está vacía- y utiliza xhost para agregar un nombre de sistema, reducirá el nivel de seguridad. El servidor permitirá el acceso al computador principal que ha agregado, así como a cualquier usuario que especifique el protocolo de autorización predeterminado. Consulte "Acceso basado en el computador principal"" si desea una explicación de porqué el mecanismo de control de acceso basado en el computador principal es considerado un nivel de seguridad inferior.

El programa xauth accede a los datos de autorización en el archivo .Xauthority del cliente. Puede extraer estos datos del archivo .Xauthority para que otro usuario pueda mezclar esos datos en el archivo .Xauthority, permitiéndole así acceso al servidor, o bien al servidor al que esté conectado.

Consulte "Cómo permitir el acceso cuando se utiliza MIT-MAGIC-COOKIE-1 "" si desea ejemplos de cómo utilizar xhost y xauth..

Archivo de autorización del cliente

El archivo de autorización del cliente es .Xauthority. Contiene entradas con este formato: 

connection-protocol          auth-protocol          auth-data

Como valor predeterminado, .Xauthority contiene MIT-MAGIC-COOKIE-1 como el auth-protocol, y entradas para la pantalla local como connection-protocol y auth-data. Por ejemplo, en el computador principal anyhost, el archivo .Xauthority podría contener las entradas siguientes: 

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

Cuando se inicia el cliente, se lee una entrada correspondiente al connection-protocol en .Xauthority, y el auth-protocol y el auth-data se envían al servidor formando parte del paquete de conexión. En la configuración predeterminada, xhost muestra listas de acceso basadas en el computador principal que están vacías e informan que la autorización está activa.

Si ha cambiado el protocolo de autorización del valor predeterminado a SUN-DES-1, las entradas en .Xauthority contendrán SUN-DES-1 como auth-protocol y el nombre de red del usuario como auth-data. El nombre de red tiene el formato siguiente: 

unix.userid@NISdomainname

Por ejemplo, en el computador principal anyhost, el archivo .Xauthority podría contener las entradas siguientes, donde unix.15339@EBB.Eng.Sun.COM es el nombre de red del usuario, que es independiente del sistema:

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"

Nota -

Si no conoce el nombre de red, o nombre de red independiente del sistema, consulte al administrador de sistemas.

Cómo permitir el acceso cuando se utiliza MIT-MAGIC-COOKIE-1

Si utiliza el protocolo de autorización MIT-MAGIC-COOKIE-1, siga estos pasos para permitir a otro usuario el acceso al servidor:

  1. En el sistema donde se ejecute el servidor, utilice xauth para extraer una entrada correspondiente a hostname:0 en un archivo.

    En este ejemplo, hostname es anyhost y el archivo es xauth.info:

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

  2. Envíe el archivo que contenga la entrada del usuario que solicite acceso (utilice la Herramienta de Correo, rcp o cualquier otro método de transferencia de archivos).

    Nota -

    Enviar por correo electrónico el archivo que contenga la información de autorización es un método más seguro que utilizar rcp. Si utiliza rcp, no sitúe el archivo en un directorio al que pueda acceder fácilmente otro usuario.

  3. El otro usuario debe introducir dicha entrada en el archivo .Xauthority.

    En este ejemplo, userhost fusiona xauth.info con el archivo .Xauthority del otro usuario: 

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

    Nota -

    El valor auth-data es específico para la sesión; por tanto, será válido únicamente hasta que el servidor sea reiniciado.

Cómo permitir el acceso cuando se utilice SUN-DES-1

Si está utilizando el protocolo de autorización SUN-DES-1, siga estos pasos para permitir el acceso a su servidor a otro usuario:

  1. En el sistema donde se ejecute el servidor, utilice xhost para que el servidor reconozca al nuevo usuario.

    En este ejemplo, para permitir al nuevo usuario somebody ejecutar en myhost:

    $ xhost + somebody@

  2. El nuevo usuario debe utilizar xauth para agregar la entrada en el archivo .Xauthority.

    En este ejemplo, el nombre de red independiente del sistema para el nuevo usuario es unix.15339@EBB.Eng.Sun.COM. Observe que este comando se debe escribir en una línea sin retorno de carro. Después del símbolo del canal de comunicación ,deje un espacio en blanco y escriba el resto del comando. 

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

Cómo procesar clientes remota o localmente como otro usuario

Los clientes X utilizan el valor de la variable de entorno DISPLAY para obtener el nombre del servidor al que deben conectarse.

Para ejecutar clientes remota o localmente como otro usuario, siga estos pasos:

  1. En el sistema donde se ejecute el servidor, permita el acceso a otros usuarios.

    Dependiendo del protocolo de autorización que utilice, siga los pasos indicados en "Cómo permitir el acceso cuando se utiliza MIT-MAGIC-COOKIE-1 "" o bien en "Cómo permitir el acceso cuando se utilice SUN-DES-1 "".

  2. Establezca DISPLAY en el nombre del computador principal donde se ejecute el servidor.

    En este ejemplo, el computador principal es remotehost:

    $ DISPLAY=remotehost:0

  3. Ejecute el programa del cliente de esta forma. 

    $ client_program&

    El cliente se mostrará en el sistema remoto, remotehost.