Problema X en debian
Juan MartÃnez <[EMAIL PROTECTED]> 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 Us
Problema X en debian
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
Problema X en debian
Juan MartÃnez <[EMAIL PROTECTED]> wrote: > El Sab, 3 de Junio de 2006, 1:29 am, Horst von Brand escribió: > > Juan MartÃÂnez <[EMAIL PROTECTED]> wrote: > >> El vie, 02-06-2006 a las 10:54 -0400, [EMAIL PROTECTED] escribió: > [...] > >>> verifique que no hubiera problemas de espacio y estaba al 50% para la > >>> raiz, > >>> despues google y encontre que era un problemas de permisos de /tmp > >>> drwxr-xr-x 13 root root 4096 Jun 2 10:42 tmp > >>> los cambie con chmod ugo+w /tmp > >> Hubiera sido mas lindo con chmod 1777 /tmp :-) > > chmod a=rwx,+t /tmp # en castellano > En gustos... La version letrada es mucho mas flexible (permite dar/quitar permisos en forma independiente, etc). > >>> y listop pero la pregunta del millon es ÿquien cambio los permisos? > > > >> Mmm...a veces (en muy contadas veces) algunos paquetes pueden cometer > >> estos cambios. Cosa rara, pero me han pasado cosas similares. Incluso > >> las he reportado. > > > > Que pasen cosas como esas para mi seria razon suficiente para alejarme > > rapidamente de los paquetes del caso, y seguramente buscar una > > distribucion > > menos irresponsable con la seguridad. > Me extraña su respuesta Sr. profesor. Cambios de permisos de directorios del sistema al instalar es algo que a mas tardar quien arma el paquete debiera pillar. > Si nadie reporta este tipo de cosas, como hacer que avance el proyecto? Esta clase de cosas /nunca/ debieran salir de las manos del desarrllador. > 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. Yep. > Me imagino que Ud. lo tiene muy claro...espero. Y la parte de que como desarrollador soy responsable por lo que les ocurre a cientos de miles de usuarios tambien la tengo clara. > Cada uno ciertamente tiene sus preferencias. No por un comentario No es mi comentario (esos se los lleva el viento), es el cambio irresponsable de permisos lo que debiera preocuparte. 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. Cambio de permisos == seguridad, cambio de permisos de cosas criticas... PS: Echa una miradita a la diferencia en drwxrwxrwt y drwxrwxrwx en directorios como /tmp, piensa las implicancias, considera que el usuario de a pie /no/ sabra la diferencia... -- 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, ChileFax: +56 32 797513
Problema X en debian
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). > 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 > 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" 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. Pregunta: Que pasa si el proceso que abrio el socket, era un proceso de autentificacion de usuarios? 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. A todo esto, no tengo ninguna intencion de criticar al mentado proyecto. Solo quiero resaltar que lo que parece una "pequennez" puede convertirse en la piedra angular de muchos problemas. Xhau -- http://toolchains.com/personal/blog
Problema X en debian
El Sab, 3 de Junio de 2006, 1:29 am, Horst von Brand escribió: > Juan MartÃnez <[EMAIL PROTECTED]> wrote: >> El vie, 02-06-2006 a las 10:54 -0400, [EMAIL PROTECTED] escribió: [...] >>> verifique que no hubiera problemas de espacio y estaba al 50% para la >>> raiz, >>> despues google y encontre que era un problemas de permisos de /tmp >>> drwxr-xr-x 13 root root 4096 Jun 2 10:42 tmp >>> los cambie con chmod ugo+w /tmp > >> Hubiera sido mas lindo con chmod 1777 /tmp :-) > > chmod a=rwx,+t /tmp # en castellano En gustos... >>> y listop pero la pregunta del millon es ¿quien cambio los permisos? > >> Mmm...a veces (en muy contadas veces) algunos paquetes pueden cometer >> estos cambios. Cosa rara, pero me han pasado cosas similares. Incluso >> las he reportado. > > Que pasen cosas como esas para mi seria razon suficiente para alejarme > rapidamente de los paquetes del caso, y seguramente buscar una > distribucion > menos irresponsable con la seguridad. Me extraña su respuesta Sr. profesor. Si nadie reporta este tipo de cosas, como hacer que avance el proyecto? 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. 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. -- Juan Martinez Depto. Inf. UMC
Problema X en debian
Juan MartÃnez <[EMAIL PROTECTED]> wrote: > El vie, 02-06-2006 a las 10:54 -0400, [EMAIL PROTECTED] escribió: > > Hoy al encender mi computador no pude entrar a la seccion X con KDE como > > acostumbro y aparecia el siguiente error. > > /etc/gdm/PreSession/Default: Registering your session with wtmp and utmp > > /etc/gdm/PreSession/Default: running: /usr/bin/X11/sessreg -a -w > > /var/log/wtmp > > -u /var/run/utmp -x "/var/lib/gdm/:0.Xservers" -h "" -l ":0" "el_user" > > /etc/gdm/Xsession: Beginning session setup... > > mkdtemp: private socket dir: Permission denied > > > > verifique que no hubiera problemas de espacio y estaba al 50% para la raiz, > > despues google y encontre que era un problemas de permisos de /tmp > > drwxr-xr-x 13 root root 4096 Jun 2 10:42 tmp > > los cambie con chmod ugo+w /tmp > Hubiera sido mas lindo con chmod 1777 /tmp :-) chmod a=rwx,+t /tmp # en castellano > > y listop pero la pregunta del millon es ¿quien cambio los permisos? > Mmm...a veces (en muy contadas veces) algunos paquetes pueden cometer > estos cambios. Cosa rara, pero me han pasado cosas similares. Incluso > las he reportado. Que pasen cosas como esas para mi seria razon suficiente para alejarme rapidamente de los paquetes del caso, y seguramente buscar una distribucion menos irresponsable con la seguridad. -- 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, ChileFax: +56 32 797513 From [EMAIL PROTECTED] Fri Jun 2 23:07:06 2006 From: [EMAIL PROTECTED] (Claudio Bustos Bravo) Date: Fri Jun 2 23:34:25 2006 Subject: TV Card: NB-TV 100 (Kworld) Message-ID: <[EMAIL PROTECTED]> Saludos... Alguien ha usado esta tarjeta pcmcia en linux?... No he podido descubrir cual es el codigo de la tarjeta y del tuner a usar... Si alguien ha jugado con eso, agradecere sus comentarios. Reitero mis saludos, Claudio Bustos
