Problema X en debian

[Horst von Brand]

Juan Martínez <jeugenio en umcervantes.cl> wrote:
> El sáb, 03-06-2006 a las 01:10 -0700, Carlos Manuel Duclos Vergara dijo:

[...]

> > 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.

Eso es lo comun, y /precisamente/ por esa razon es que es responsabilidad
de la distribucion (o el paquete) evitar esas cosas. Y responsabilidad de
quienes mas saben del tema de culturizar a quienes no saben, o corregir
estos errores. Que es lo que intentamos hacer aca...

>                                                             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!)

Por /algo/ los tiene...

> > 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.

Cuando se habla de seguridad, las "probabilidades" cuentan pocazo, queremos
garantias (dentro de lo razonable).

Programas en uso comun que hacen algo asi incluyen screen(1).

Programas que crean archivos temporales en /tmp hay muchos, y dandoles
archivos pichicateados demas se pueden lograr efectos "interesantes" en
muchos casos...

Simplememente cambiar de nombre a archivos temporales de "otros" puede
llenar /tmp sin sobrepasar quotas

> > 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

Insisto: Hay programas que lo hacen. /var/run es para root unicamente, si
un programa para usuarios de a pie requiere algo asi, lo hara en /tmp. Echa
una mirada al FHS para la justificacion de /tmp y afines.

[...]

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

Se nota claramente que no has mirado el "como" de alguna intrusion mas
sofisticada. Y han habido ataques locales harto rebuscados tambien (Las
maneras "obvias" de hacer estas cosas generalmente ya se cerraron. Bueno,
eso es lo que estamos pidiendo aca...).

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

Excelente. Recuerdame nunca contratarte para nada que aun lejanamente tenga
alguna relevancia.

> 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.

1. No importa que distribucion es, es una demostracion clarisima de manejo
   irresponsable de la seguridad. Posiblemente perdonable en versiones de
   prueba para dementes terminales, pero aun asi...
2. Ver arriba.
3. No importa demasiado (obvio, si el culpable es un paquete que solo el
   desarrollador y dos usuarios mas instalan es un tanto menos critico que
   si es el paquete de bash quien se manda la gracia...

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

Eliminalo, y veras...
 
> 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.

Es bien comun requerir espacio temporal, y es comodo poder acceder a
espacio comun siempre en forma uniforme, incluso cuando estas en un
directorio en el que no tienes permisos y trabajando con archivos que solo
puedes leer.

>               No se si en los proyectos que tu usas, eso ocurre.

Scrolling del tty. Archivos temporales de less(1) cuando se invoca sobre un
pipe. Archivos temporales del compilador (preprocesado, assembler). Como ya
dije, sockets de screen(1). Estos son simplemente ejemplos variados de los
que me acuerdo en el momento, may muchisimos mas.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513