12. Term y la seguridad

En esta sección puntualizaré algunos aspectos sobre la seguridad usando TERM. Los problemas serán expuestos junto a un mecanismo para aumentar su seguridad.

12.1 trsh

Trsh es inseguro si se usa para acceder al Linux local desde el sistema remoto. El problema con TERM y sus clientes es que en el otro extremo de la comunicación el superusuario puede ejecutar programas de TERM.

Esto también indica que el 'root' del otro sistema puede ejecutar trsh y entrar en con los privilegios del propietario de la conexión fácilmente. Si este propietario es 'root' la habremos liado.

La solución es simple: poner la siguiente línea en el fichero termrc de la máquina local:

  denyrsh on

Con esto, nadie podrá usar trsh desde el sistema remoto para entrar en el local. Cuando tú mismo quieras entrar, podrás hacerlo aun usando telnet y puertos redirigidos.

12.2 txconn y xauth

Txconn no es terriblemente seguro; cualquiera puede conectar al servidor local con term y hacer de todo. Si te preocupa, puedes usar xauth para establecer las autorizaciones de acceso. Mira el ejemplo de la siguiente sección.

12.3 sxpc, xhost y xauth

Sxpc en combinación con 'xhost +' es muy peligroso si no usas xauth.

Usar xauth es muy importante para mantener la seguridad cuando se usa sxpc. Si no usas xauth al usar sxpc, será muy peligroso tener 'xhost +'. Algunos peligros son:

• Alguien puede saber lo que está en tu pantalla
• Alguien puede saber lo que tecleas
• Alguien puede teclear sobre alguna de tus ventanas (por ejemplo, un comando que borre tus ficheros :-( )

Xauth forma parte de las versiones R4 y posteriores de X. Aquí describiremos cómo usar básicamente el xauth. Esta configuración es vulnerable al husmeo de la red, pero puede convivir con ella fácilmente.

NOTA: cuando uses xauth asegúrate que la variable $DISPLAY no tiene el valor 'localhost' (o 'localhost:loquesea'). Si tu variable $DISPLAY vale 'localhost', los clientes no podrán encontrar la información de autorización. Lo mejor es usar el nombre real de la máquina. Si sigues las instrucciones de compilación del README, y compilas sin la variable -DNOGETHOSTNAME puede que todo funcione.

Sea C la máquina que ejecuta clientes, y D la máquina que pone la pantalla.

Primero, elige una 'clave', de hasta 16 pares de dígitos hexadecimales (números del rango 0-9 y a-f). Necesitarás proporcionar esta clave en el lugar de <clave> en este ejemplo:

On C:

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

On D:

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

Cuando inicies el servidor X en D deberías poner el flag -auth $HOME/.Xauthority. Puede que necesites crear o editar un fichero '$HOME/.xserverrc' para controlar el inicio del servidor X. Por ejemplo:

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

Asegúrate que el fichero '.Xauthority' es legible solo por C y por D.