|
Term
y la seguridadEn esta sección puntualizaré algunos aspectos sobre la seguridad
usando TERM
. Los problemas serán expuestos junto a un
mecanismo para aumentar su seguridad.
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.
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.
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:
:-(
)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.
Hosting by: hurra.com
Generated: 2007-01-26 18:00:37