Problema X en debian

[Juan Martínez]

El sáb, 03-06-2006 a las 01:10 -0700, Carlos Manuel Duclos Vergara
escribió:
> Holas,
> 
> > Me extraña su respuesta Sr. profesor.
> > Si nadie reporta este tipo de cosas, como hacer que avance el proyecto?
> 
> se supone que el proyecto existe para brindar un cierto nivel de 
> "tranquilidad" a los usuarios. Sobretodo si estaba en stable, o en testing 
> (que se supone ahora que tambien tiene updates desde security).

Testing hace mucho tiempo (al menos 3 años)

> > Es una pequeñez esto que toco, pero precisamente aqui es donde va el
> > caracter principal del software libre, en la colaboracion de la comunidad.
> > Me imagino que Ud. lo tiene muy claro...espero.
> 
> lo cual no excluye la responsabilidad del autor. No porque sea un proyecto 
> open source se te van a filtrar ranas por todos lados

Sin duda. Pero por favor. Yo creo que estas mal usando el lenguaje. Un
error de ese tipo no creo que signifique "ranas por todos lados".

> > Cada uno ciertamente tiene sus preferencias. No por un comentario me voy a
> > alejar del proyecto que creo, a mi parecer, es uno de los mejores.
> > Es normal cometer errores. Y arreglarlos a tiempo es la gracia de
> > cualquier proyecto. No veo irresponsabilidad alguna con la seguridad como
> > usted afirma.
> 
> el problema es que no es un tema menor el del sticky bit. Puede llevar a 
> serias complicaciones para el usuario. Sobretodo si el pobre angelito 
> encuentra en google soluciones como:
> 
> "chmod ugo+w /tmp"

Bueno. Es que si uno hace caso a todo lo que lee, estariamos intoxicados
con Cocacola o con Pepsi...Quizas al usuario que pregunto se conformo
con la primera pagina que encontro del tema. No profundizo. Es no creo
que sea problema de la distro tambien, o si? (Creo que debian va a tener
que tener voceros autorizados para escribir howtos, FAQ y cuanto
documento de ayuda para los usuarios!)

> que claramente pueden llevar a problemas serios. Un solo ejemplo (inventado, 
> apliquenlo a la situacion que se les ocurra):
> 
> 1. /tmp con permisos ugo+w
> 2. Un servicio establece un socket para comunicacion con procesos ayudantes en 
> el directorio tmp.
> 3. Un usuario "avanzado" se percata de la situacion, y se percata de que no 
> hay sticky bit y procede a borrar el socket y cambiarlo por un nuevo socket 
> adaptado a sus necesidades.
> 4. El "usuario avanzado" espera que uno de los procesos ayudantes se contacte 
> con el socket y voila!
> 
> Probablemente tomara unas 100 iteraciones dar con el momento exacto para 
> borrar el socket y cambiarlo por otro, pero no es nada que un script y un par 
> de cervezas no solucionen.
> 

Un poco rebuscado tu ejemplo. Creo que la probabilidad debe tender a 0.

> Pregunta: Que pasa si el proceso que abrio el socket, era un proceso de 
> autentificacion de usuarios?

En debian ningun socket se abre en /tmp. Para eso es /var/run

> En cambio, el sticky bit existe para garantizar que esa situacion no se de. A 
> no ser (y eso depende del sistema en cuestion, si utiliza sistemas mas 
> avanzados como SELinux), que seas root con lo cual el sticky bit puede ser 
> pasado a llevar.
> Esa clase de cosas, debiera ser revisada antes de que salga a la luz publica o 
> de lo contrario mas de un dolor de cabeza te vas a llevar.

Pero sin duda. Yo no estoy en contra de eso, el tema es que se caen los
aviones pues.

> A todo esto, no tengo ninguna intencion de criticar al mentado proyecto.

No? No me alcance a dar cuenta del proyecto que prefieres! :-)

>  Solo 
> quiero resaltar que lo que parece una "pequennez" puede convertirse en la 
> piedra angular de muchos problemas.

No estaras exagerando?

Las defensas coorporativas son como un poco innecesarias en estos
tiempos.

Por lo demas. Estamos hablando sin saber:

1. El sabor de debian que tiene el mentado usuario.
2. Si tiene todo al dia y desde repos. oficiales.
3. Cuales serian los posibles paquetes afectados.

Con respecto a lo que yo afirme, me falto especificar que fue hace unos
años y que fue en testing. Sorry.

Aun asi, es una piedra angular el directorio /tmp ?

Yo creo que no. Cualquier apps seria y bien construida, en la distro que
sea no usaria ese directorio para hacer cosas que necesiten algun grado
de seguridad. No se si en los proyectos que tu usas, eso ocurre.

-- 
Juan Martínez
Depto. Inf.
UMC