[LUG.ro] problema con kedit
Sebastián D. Criado
lugro@lugro.org.ar
Wed, 29 Nov 2006 17:32:16 -0300
--nextPart1711385.ab0g0GcTLE
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
El Lunes 27 Noviembre 2006 22:30, Luciano escribi=F3:
> otra vez me paso lo mismo :S
> trate de hacer lo del xhost y nada :(
>
Usar xhost es por dem=E1s de inseguro.
Aqu=ED una explicaci=F3n de Emiliano que vio el post y quiso colaborar:
http://pastebin.com/835557
Muchas veces pasa que algunos usuarios preguntan:=20
=20
"Porque no puedo correr (pongan su aplicaci=F3n X aqui) como root?"=20
=20
El problema viene dado porque X dispone de ciertos mecanismos de seguridad,=
=20
los cuales impiden que cualquiera pueda conectarse a nuestro display y=20
mostrar ventanas. La p=E1gina del manual de Xsecurity(7) nos da una lista=20
de los m=E9todos de control de acceso disponibles.=20
El primer m=E9todo de control esta basado en hosts, y se controla con la=20
utilidad=20
xhost(1). Sin embargo, la p=E1gina advierte que=20
=20
"Cualquier cliente de un host listado en la lista de control de accesos de=
=20
hosts tiene permitido acceder al servidor X. Este sistema puede trabajar=20
razonablemente bien en un ambiente donde todos conf=EDan en todos"=20
=20
Si adem=E1s estamos conectados a internet, estamos en un serio problema: no=
es=20
precisamente un lugar donde "todos confian en todos"=20
=20
Desgraciadamente, la respuesta a la pregunta de arriba casi siempre es=20
=20
"ejecuta xhost +"=20
=20
lo cual es un muy serio error de seguridad. Funciona, si, pero no solo para=
=20
la persona que quer=EDa hacerlo, sino para todos los que puedan querer=20
conectarse.=20
=20
Ahora bien, si pasamos al segundo m=E9todo de control de accesos, veremos q=
ue,=20
si bien no es una maravilla de seguridad, al menos no expone la m=E1quina c=
omo=20
la soluci=F3n del "xhost +". Dicho m=E9todo (MIT-MAGIC-COOKIE-1) se control=
a=20
mediante la utilidad xauth(1).=20
=20
Veamos que pasa en mi m=E1quina:=20
=20
$ su -=20
Password:=20
Terminal type is xterm. =
=20
root@pepe:~# kate=20
kate: cannot connect to X server =20
root@pepe:~# export DISPLAY=3D:0=20
root@pepe:~# kate=20
Xlib: connection to ":0.0" refused by server=20
Xlib: No protocol specified=20
=20
kate: cannot connect to X server :0=20
root@pepe:~# =20
=20
El mismo problema que gener=F3 la pregunta inicial. Si hiciera xhost + tend=
r=EDa=20
resuelto este problema, pero a costa de generar uno mucho peor.=20
=20
Hag=E1moslo con xauth.=20
=20
root@pepe# exit=20
logout=20
$ xauth -n list=20
192.168.6.3:0 MIT-MAGIC-COOKIE-1 73df0129397a17256f13dcdc55f9f150=20
pepe.dominio.net/unix:0 MIT-MAGIC-COOKIE-1 =20
73df0129397a17256f13dcdc55f9f150=20
$=20
=20
Vemos que tengo la posibilidad de acceder mediante dos m=E9todos: tcp (entr=
ada=20
192.168.6.3:0, puerto 6000) y sockets unix (pepe.dominio.net/unix:0).=20
=20
Exportemos la MAGIC-COOKIE a un archivo asi podemos importarla en otro luga=
r=20
(en este caso, el root)=20
=20
$ xauth extract authfile $DISPLAY=20
$ su -=20
Password:=20
Terminal type is xterm. =
=20
root@pepe:~# kate=20
kate: cannot connect to X server =20
root@pepe:~# export DISPLAY=3D:0=20
root@pepe:~# kate=20
Xlib: connection to ":0.0" refused by server=20
Xlib: No protocol specified=20
=20
kate: cannot connect to X server :0=20
root@pepe:~# xauth merge /home/user/authfile =20
root@pepe:~# kate &=20
root@pepe:~# xauth list =20
maq033.imae.fceia.unr.edu.ar/unix:0 MIT-MAGIC-COOKIE-1 =20
73df0129397a17256f13dcdc55f9f150=20
=20
=20
=46inalmente anduvo, y sin necesidad de abrir mi display al mundo. Puedo=20
conectarme a la X sin problemas. Este archivo podr=EDa copiarlo a otras=20
m=E1quinas de mi red interna, importarlo con xauth y conectarme desde ahi.=
=20
=20
=46inalmente, unas aclaraciones y/o recomendaciones:=20
* El m=E9todo no es una panacea de seguridad, ya que la cookie se transmite=
en=20
texto plano en las conexiones de red.=20
* Si realmente somos paranoicos (al menos yo lo soy) deberemos directamente=
=20
deshabilitar la conexi=F3n a la X mediante tcp (la opcion es -nolisten tcp =
en=20
el comando que lanza la X), aunque esto nos impide conectarnos desde otra=20
m=E1quina.=20
* Si lo hacemos todo localmente, podr=EDamos directamente, como root, haber=
=20
apuntado la "base de datos" de cookies a la del usuario en cuesti=F3n:=20
=20
root@pepe:~# XAUTHORITY=3D/home/usuario/.Xauthority kate &=20
=20
y tambi=E9n andar=EDa (aunque es un m=E9todo un tanto rudo para el usuario,=
sobre=20
todo si no es el mismo que el root !!!). Para mi gusto este ser=EDa el cons=
ejo=20
r=E1pido y sucio para darle a alguien en vez del "xhost +".=20
* Si no andamos muy peleados con el ingl=E9s, leer las p=E1ginas de manual =
de=20
X(7), xdm(1), Xsecurity(7), Xserver(1), xhost(1) y xauth(1). Y si, ya se qu=
e=20
son muchas, pero como dice un viejo preoverbio chino "Sigue el sagrado cami=
no=20
del RTFM, peque=F1o saltamontes ..."=20
* En http://tldp.org/HOWTO/Remote-X-Apps.html esta el howto que me hizo ver=
=20
el tema este del xhost vs xauth.=20
* Leer el c=F3digo fuente de startx(1) es instructivo al respecto , sobre t=
odo=20
la parte final.=20
* La =FAltima: en algunos sistemas (p.ej *BSD), el resolver de hosts es muy=
=20
puntilloso en cuanto a los nombres de archivo y como se resuelven a IPs. Si=
=20
algunos andan con problemas de delays para que se le lancen las aplicacione=
s=20
X, puede ser que haya un problema de este tipo y hay que esperar el timeout=
=20
de la consulta para ir a la IP directamente. Asegurense que su nombre de=20
host siempre se resuelva bien, sea mediante /etc/hosts o DNS.=20
=20
Espero que ayude.
=2D-=20
Sebasti=E1n D. Criado - scriado{en}ciudad.com.ar
L.U.G.R.o - http://www.lugro.org.ar
GNU/Linux Registered User # 146768
=2D------------------------------------------------------------------
"Si el Universo fuera un programa estar=EDa hecho en C, y correr=EDa sobre
un sistema UNIX"
An=F3nimo.
=09
--nextPart1711385.ab0g0GcTLE
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQBFbe5a8hmHQ8ZCg0IRArrXAJ9u7+l3NHtU1gKZP7Clm1NbVBpCmACglv81
oxihA8SH17eegUBnuGdAqFg=
=6t16
-----END PGP SIGNATURE-----
--nextPart1711385.ab0g0GcTLE--