[LUG.ro] problema con kedit

[luciano]

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.                                                  
>    root@pepe:~# kate 
>    kate: cannot connect to X server  
>    root@pepe:~# export DISPLAY=:0 
>    root@pepe:~# kate 
>    Xlib: connection to ":0.0" refused by server 
>    Xlib: No protocol specified 
>     
>    kate: cannot connect to X server :0 
>    root@pepe:~#  
>   
> 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. 
>  
>    root@pepe# 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.                                                  
>    root@pepe:~# kate 
>    kate: cannot connect to X server  
>    root@pepe:~# export DISPLAY=:0 
>    root@pepe:~# kate 
>    Xlib: connection to ":0.0" refused by server 
>    Xlib: No protocol specified 
>  
>    kate: cannot connect to X server :0 
>    root@pepe:~# xauth merge /home/user/authfile  
>    root@pepe:~# kate & 
>    root@pepe:~# 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: 
>  
>    root@pepe:~# 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.
>
>