Logo de AulaDigital

Term Como 12

TERM Como: Term y la seguridad Anterior Siguiente Indice

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 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 aún 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 hay 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:

En 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

En 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 parámetro -auth $HOME/.Xauthority. Puede que necesites crear o editar el 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 sólo por C y por D.


Anterior Siguiente Indice