muy interesante :D
voy a probarlo... otra cosa, como vuelvo a darle los la proteccion al
xhost ??
Sebastián D. Criado escribió:
El Lunes 27 Noviembre 2006 22:30, Luciano escribió:
otra vez me paso lo mismo :S
trate de hacer lo del xhost y nada :(
Usar xhost es por demás de inseguro.
Aquí una explicación de Emiliano que vio el post y quiso colaborar:
http://pastebin.com/835557
Muchas veces pasa que algunos usuarios preguntan:
"Porque no puedo correr (pongan su aplicación X aqui) como root?"
El problema viene dado porque X dispone de ciertos mecanismos de seguridad,
los cuales impiden que cualquiera pueda conectarse a nuestro display y
mostrar ventanas. La página del manual de Xsecurity(7) nos da una lista
de los métodos de control de acceso disponibles.
El primer método de control esta basado en hosts, y se controla con la
utilidad
xhost(1). Sin embargo, la página advierte que
"Cualquier cliente de un host listado en la lista de control de accesos de
hosts tiene permitido acceder al servidor X. Este sistema puede trabajar
razonablemente bien en un ambiente donde todos confían en todos"
Si además estamos conectados a internet, estamos en un serio problema: no es
precisamente un lugar donde "todos confian en todos"
Desgraciadamente, la respuesta a la pregunta de arriba casi siempre es
"ejecuta xhost +"
lo cual es un muy serio error de seguridad. Funciona, si, pero no solo para
la persona que quería hacerlo, sino para todos los que puedan querer
conectarse.
Ahora bien, si pasamos al segundo método de control de accesos, veremos que,
si bien no es una maravilla de seguridad, al menos no expone la máquina como
la solución del "xhost +". Dicho método (MIT-MAGIC-COOKIE-1) se controla
mediante la utilidad xauth(1).
Veamos que pasa en mi máquina:
$ su -
Password:
Terminal type is xterm.
[EMAIL PROTECTED]:~# kate
kate: cannot connect to X server
[EMAIL PROTECTED]:~# export DISPLAY=:0
[EMAIL PROTECTED]:~# kate
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
kate: cannot connect to X server :0
[EMAIL PROTECTED]:~#
El mismo problema que generó la pregunta inicial. Si hiciera xhost + tendría
resuelto este problema, pero a costa de generar uno mucho peor.
Hagámoslo con xauth.
[EMAIL PROTECTED] exit
logout
$ xauth -n list
192.168.6.3:0 MIT-MAGIC-COOKIE-1 73df0129397a17256f13dcdc55f9f150
pepe.dominio.net/unix:0 MIT-MAGIC-COOKIE-1
73df0129397a17256f13dcdc55f9f150
$
Vemos que tengo la posibilidad de acceder mediante dos métodos: tcp (entrada
192.168.6.3:0, puerto 6000) y sockets unix (pepe.dominio.net/unix:0).
Exportemos la MAGIC-COOKIE a un archivo asi podemos importarla en otro lugar
(en este caso, el root)
$ xauth extract authfile $DISPLAY
$ su -
Password:
Terminal type is xterm.
[EMAIL PROTECTED]:~# kate
kate: cannot connect to X server
[EMAIL PROTECTED]:~# export DISPLAY=:0
[EMAIL PROTECTED]:~# kate
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified
kate: cannot connect to X server :0
[EMAIL PROTECTED]:~# xauth merge /home/user/authfile
[EMAIL PROTECTED]:~# kate &
[EMAIL PROTECTED]:~# xauth list
maq033.imae.fceia.unr.edu.ar/unix:0 MIT-MAGIC-COOKIE-1
73df0129397a17256f13dcdc55f9f150
Finalmente anduvo, y sin necesidad de abrir mi display al mundo. Puedo
conectarme a la X sin problemas. Este archivo podría copiarlo a otras
máquinas de mi red interna, importarlo con xauth y conectarme desde ahi.
Finalmente, unas aclaraciones y/o recomendaciones:
* El método no es una panacea de seguridad, ya que la cookie se transmite en
texto plano en las conexiones de red.
* Si realmente somos paranoicos (al menos yo lo soy) deberemos directamente
deshabilitar la conexión a la X mediante tcp (la opcion es -nolisten tcp en
el comando que lanza la X), aunque esto nos impide conectarnos desde otra
máquina.
* Si lo hacemos todo localmente, podríamos directamente, como root, haber
apuntado la "base de datos" de cookies a la del usuario en cuestión:
[EMAIL PROTECTED]:~# XAUTHORITY=/home/usuario/.Xauthority kate &
y también andaría (aunque es un método un tanto rudo para el usuario, sobre
todo si no es el mismo que el root !!!). Para mi gusto este sería el consejo
rápido y sucio para darle a alguien en vez del "xhost +".
* Si no andamos muy peleados con el inglés, leer las páginas de manual de
X(7), xdm(1), Xsecurity(7), Xserver(1), xhost(1) y xauth(1). Y si, ya se que
son muchas, pero como dice un viejo preoverbio chino "Sigue el sagrado camino
del RTFM, pequeño saltamontes ..."
* En http://tldp.org/HOWTO/Remote-X-Apps.html esta el howto que me hizo ver
el tema este del xhost vs xauth.
* Leer el código fuente de startx(1) es instructivo al respecto , sobre todo
la parte final.
* La última: en algunos sistemas (p.ej *BSD), el resolver de hosts es muy
puntilloso en cuanto a los nombres de archivo y como se resuelven a IPs. Si
algunos andan con problemas de delays para que se le lancen las aplicaciones
X, puede ser que haya un problema de este tipo y hay que esperar el timeout
de la consulta para ir a la IP directamente. Asegurense que su nombre de
host siempre se resuelva bien, sea mediante /etc/hosts o DNS.
Espero que ayude.
_______________________________________________
Lugro mailing list
Lugro@lugro.org.ar
http://www.lugro.org.ar/mailman/listinfo/lugro
