COMO: Parte 2 - control de autorización de X y su manejo

Imagen de acl

En la parte 1 de este howto vimos cómo se puede hacer para conectar una aplicación gráfica a una pantalla que se encuentra en un computador remoto. También dimos un vistazo rápido de cómo evitar que el control de acceso de X nos estorbe.

Ahora vamos a aprender cómo funciona ese control de acceso.

Un poco más de teoría

Si recuerdan, bajo el protocolo X tenemos básicamente dos actores:

  • El Servidor X: Lee las teclas presionadas y los movimientos y clicks del mouse y los enruta a las diferentes aplicaciones conectadas a él. También recibe las órdenes de dibujo de las aplicaciones y las traduce a píxeles para la pantalla y tarjeta de video que tenga el host.
  • El Cliente de X: obtiene los tecleos y movimientos del mouse del servidor X al que está conectado y envía las órdenes de despliegue de gráficos, y además interactúa con los usuarios.

En el documento anterior logramos decirle a una aplicación a qué servidor nos queremos conectar y el resultado es que la aplicación se despliega en un computador remoto. Este esquema sin un control de acceso es obviamente indeseable, pues no nos interesa que cualquier cristiano dibuje su aplicación mugrienta en nuestro monitor. Esto por una simple razón: los clientes de X pueden leer los tecleos y movimientos del mouse que hacemos en la pantalla de X y se presta para que nos roben los passwords y otros manjares.

La mala noticia es que los muchachos que diseñaron el protocolo no incluyeron un sistema de autenticación entre X y sus aplicaciones. La buena noticia es que incluyeron dos:

Xhost

El control de acceso más simple se lo hace a través de xhost. Lo que hace este programa es autenticar basado en el nombre de host de la aplicación que se quiere conectar. En otras palabras, al momento de que la conexión con el servidor se está armando, el servidor verifica si la ip o nombre del cliente está dentro de la lista de hosts autorizados a conectar. Si no lo está simplemente cierra la conexión.

Este no es un esquema demasiado seguro, pues es completamente posible que exista más de un usuario por ip (piensen en NAT, por ejemplo, o en una máquina multiusuario), pero es una solución rápida para redes en las que nosotros tenemos total control y confiamos en todos los usuarios.

Aquí algunos ejemplos de uso de xhost (recuerden que cristina es el host que corre X):


cristina$ xhost +susana #agrega el host susana a la lista de hosts permitidos
cristina$ xhost -betty # borra a betty de la lista
cristina$ xhost + # deshabilita el control por xhosts y todos los clientes pueden conectarse (¡CUIDADO!)
cristina$ xhost - # rehabilita el control por xhosts

La aplicación xhost es un cliente de X, como cualquier otro, con la diferencia que no muestra gráficos, solo manipula los parámetros del servidor. Así que también se le puede usar para manipular los parámetros de un servidor remoto (asumiendo que ese servidor nos permite el acceso) reasignando la variable DISPLAY

Xauth

El segundo tipo de control de acceso incluido con X es también bastante simple, pero es más granular que andar permitiendo hosts completos conectarse al servidor. Este segundo esquema permite conectarse a los clientes que conocen el número secreto que X está pensando.

Cuando un servidor de X con control de autenticación xauth arranca, se le debe proveer con un nombre de archivo en donde esté almacenado un cierto número (de preferencia aleatorio y volátil entre ejecuciones). Dicho número recibe el nombre de MIT-MAGIC-COOKIE y el servidor lo almacena en memoria y espera a que un cliente se conecte. En versiones más nuevas, se puede pedir al servidor X que genere un cookie al momento de ejecución.

Entonces, cuando el cliente se conecte, el servidor le preguntará a la aplicación que le demuestre que sabe el valor del cookie. Si la aplicación lo sabe, se permite continuar.

¿Cómo sabe la aplicación el valor del cookie? La respuesta es que el cookie se encuentra en un archivo dentro del home directory del usuario que invoca la aplicación. El archivo por omisión es ~/.Xauthority, pero se puede especificar otro con la variable XAUTHORITY o con la opción -f de xauth.

Creemos un cookie para nuestro servidor X y luego arranquémoslo para que use ese cookie.


cristina$ xauth -f ~/miarchivodeauthority add :1 . `mcookie`
cristina$ ls -l ~/miarchivodeauthority
-rw------- 1 acl acl 1821 2008-05-31 00:59 miarchivodeauthority
cristina$ X -auth ~/miarchivodeauthority :1 &
<>

Lógicamente el archivo tiene permisos 600 para evitar que cualquier usuario pueda leer el valor del cookie. Podemos ver el valor de los cookies almacenados en el archivo e incluso exportarlos e importarlos con la ayuda de 'xauth':


cristina$ xauth -f miarchivodeauthority
Using authority file /home/acl/miarchivodeauthority
xauth> list
cristina:1 MIT-MAGIC-COOKIE-1 dda8f2169226e2534ffc4439990a8999
xauth> extract cristina-archivo.xauth cristina:1
1 entries written to "cristina-archivo.xauth"
xauth> exit

Ahora podemos pasar el cristina-archivo.xauth, pero recuerden que este cookie no debe ser visto por nadie, así que nada de telnetearle, ftpearle, ponerle en un servidor web, ni enviarle por email.

También pudimos haber hecho:


cristina$ scp ~/miarchivodeauthority acl@susana:/home/acl/

Y transferir TODO el archivo de authority. Pero como el archivo de authority puede tener más de un cookie, no lo recomiendo. Prefiero extraer el cookie que quiero y solo ese transferirle.

Una vez almacenado el archivo del cookie en susana podremos importarle a nuestro archivo de .Xauthority en susana.

susana$ export DISPLAY=ip.de.cristina:1
susana$ xterm
Xlib: connection to "ip.de.cristina:1.0" refused by server
Xlib: No protocol specified

xterm Xt error: Can't open display: ip.de.cristina:1
susana$ ls -l ~/.Xauthority
ls: cannot access .Xauthority: No such file or directory
susana$ ls -l cristina-archivo.xauth
-rw------- 1 acl acl 54 2008-05-31 11:47 cristina-archivo.xauth
susana$ xauth
xauth: creating new authority file /home/acl/.Xauthority
Using authority file /home/acl/.Xauthority
xauth> list
xauth> merge cristina-archivo.xauth
1 entries read in: 1 new, 0 replacements
xauth> list
cristina:1 MIT-MAGIC-COOKIE-1 dda8f2169226e2534ffc4439990a8999
xauth> exit
susana$ xterm

Y finalmente tenemos nuestra ventanita de xterm.

Por lo general xauth no es un cliente de X, solamente manipula archivos y sabe escribir el cookie en el formato esperado, así que no se necesita autenticar.

Poniéndolo todo en contexto

Todo este menjurge de autenticación por suerte no lo tenemos que hacer nosotros, tenemos aplicaciones que se encargan de ello:

  • El display manager: Es una aplicación un poco especial que hace de cliente de X. Probablemente la hayan visto antes, pues es la aplicación con la que interactuamos para autenticarnos en una sesión gráfica. Algunos gestores de despliegue son xdm, gdm, kdm, wdm. Este gestor se encarga de generar el cookie para el servidor; y cuando ponemos nuestro usuario y clave correcta, el gestor copia el cookie a nuestro ~/.Xauthority y listo. Por eso no nos tenemos que preocupar por este archivo (excepto cuando lo borramos o hacemos algo igual de inteligente). Con ello solo nuestras aplicaciones tienen acceso al cookie.
  • Secure Shell: Además de ser una herramienta utilísima para correr shells en hosts remotos de manera segura, ssh puede extraer el cookie de un servidor de X, enviarlo al servidor de aplicación, agregarlo a la lista de cookies del servidor de aplicaciones, poner la variable de display al valor correcto y como si esto fuera poco, encima lo hace encriptado y también encripta la comunicación entre el servidor X y el cliente. Y todo esto simplemente corriéndolo con la opción -X y/o -Y:

    cristina$ ssh -Y acl@susana firefox
    xauth: creating new authority file /home/acl/.Xauthority

En la siguientes entregas veremos como integrar todo lo aprendido en estas dos secciones para mostrar ventanas de linux en window$ y más detalles acerca del display manager y lo que se puede hacer con él.