Boletín Semanal de Gentoo: 14 de Febrero, 2005Foros Gentoo sobre una nueva plataforma de Hardware y Software Como anticipamos hace tres semanas en un artículo de Mirando al futuro, los foros Gentoo se han cambiado a una nueva plataforma de hardware, además de actualizar la versión de phpBB que utilizan, de manera que ahora funcionan sobre una base de código limpio, normalizando todos los parches que habían sido aplicados a la versión anterior, y con más características que aquella. Entre las mejoras implementadas están: mejor soporte para los foros de habla no inglesa, nuevos estilos de URI con enlaces absolutos que permite a los spiders de los motores de búsqueda indexar todo el Foro, y unas cuantas cosas más que no son tan visibles, como la nueva capacidad de los moderadores para unir hilos (mover posts de hilos que estaban fuera de contexto hacia otros más apropiados no era posible previamente). Aparte de contratiempos menores, la transición fue tan bien realizada que ninguno de los usuarios se dió cuenta hasta que ésta ya había culminado. ¡Felicitaciones a Christian Hartmann y Lance Albertson por la excelente migración llevada a cabo!. Calendario de eventos de Gentoo para Febrero/Marzo de 2005 A nuestros evangelistas de Gentoo les esperan días ocupados: Su agenda no había estado tan copada con exhibiciones, conferencias y presentaciones durante las próximas cuatro semanas. Les presentamos una lista de los eventos venideros, con un último recordatorio para la LWE de Boston que comienza mañana.
Equipo de Seguridad de Gentoo -- Entrevista con Thierry Carrez Si tienes el hábito de mirar cómo se siguen y enfrentan los problemas de seguridad en mundo de Linux, es probable que hayas notado que las alertas y respuestas de Gentoo a problemas de seguridad se siguen rápidamente después del descubrimiento de éstas. De hecho, los Anuncios de Seguridad de Gentoo Linux (GLSAs) frecuentemente se citan como un recurso para notificaciones de seguridad y estado de arreglo aún fuera de la comunidad de Gentoo. Esta reputación de tener rápida y positiva capacidad de respuesta es extraordinaria para una comunidad que no tiene apoyo comercial que dé soporte a un centro de respuestas de seguridad dedicado. Thierry Carrez (koon), uno de los Administradores Operacionales del Equipo de Seguridad de Gentoo, se tomó algunos minutos para explicarnos algunas de las prácticas que han permitido que el equipo sean tan eficiente en identificar y responder a problemas de seguridad. ¿Podrías repasar el proceso involucrado de identificar y reparar errores de seguridad? ¿Cuáles son los pasos? ¿Quién los lleva a cabo? ¿Cuáles herramientas se utilizan? Seguimos la Política de Tratamiento de Vulnerabilidades para manejar los errores de seguridad. Brevemente, las vulnerabilidades públicas son enviadas por usuarios, nuestros "exploradores" de seguridad o los desarrolladores de seguridad, quien quiera que las encuentre primero. A veces, nos notifican por canales confidenciales (la lista vendor-sec o contacto directo de los desarrolladores principales o auditores). Luego, el error de seguridad pasa por el estado upstream, (donde esperamos una solución de los mantenedores del programa); estado ebuild, (donde le pedimos al mantenedor del paquete en Gentoo que corrija el ebuild); estado estable, (donde pedimos que se pruebe el paquete reparado en las arquitecturas soportadas y marcamos el paquete reparado como estable); y, finalmente, estado glsa, cuando publicamos un GLSA, si es necesario. A veces, el proceso se para en uno de los estados intermedios, y tenemos que hacer un parche por nosotros mismos. Otras veces, no encontramos una solución y enmascaramos el paquete porque sería un riesgo de seguridad dejarlo en el árbol portage sin repararlo. El manejo de los errores de seguridad es principalmente llamar a la persona correcta a la hora correcta para continuar con el proceso. Esta tarea es hecha por los coordinadores del GLSA, y no es automatizada. Dependemos fuertemente de los otros desarrolladores de Gentoo para realizar los parches y probar. ¿Dónde averiguan acerca de los errores de seguridad? ¿Listas de correo? ¿Alertas? ¿Probamos nosotros mismos? Dependemos en nuestra base de usuarios para que envíen tantas vulnerabilidades públicas como puedan. El equipo de seguridad trata de encontrar los que pasan desapercibidos. Las fallas de seguridad vienen de listas de correo públicas como BugTraq o Full-Disclosure, más los avisos de seguridad preliminares o los de otras distribuciones. Estamos siendo cada vez más aceptados como parte de la comunidad general de seguridad en Linux, por eso nos avisan de algunas vulnerabilidades antes de que se hagan públicas. Para contribuir a la comunidad, recién hemos iniciado un sub-proyecto de Auditoría de Seguridad para encontrar errores por nosotros mismos, y nuestros mantenedores de los paquetes también encuentran bastantes errores en sus pruebas. Cuando se identifica un error, ¿cómo se documenta? La mayoría de las veces sólo copiamos la informacion del aviso público, y luego procedemos en verificar que ésta afecte a Gentoo, y clasificamos su gravedad. Esta gravedad determina la prioridad, ya que tratamos de respetar los plazos de retraso indicados en la Política de Tratamiento de Vulnerabilidades. ¿Hay un proceso formal de asignar un error a alguien? ¿Cómo se clasifican las prioridades? ¿Cómo se documenta y prueba la solución? Cada coordinador del GLSA puede ser asignado a un error para averiguar que el trabajo continúe. Pero, si el error se atasca, cada desarrollador puede intervenir y destrancarlo. Se decide la prioridad por la gravedad, según las reglas en la Política de Tratamiento de Vulnerabilidades. Cuando está disponible una corrección, ¿Cómo se documenta?, ¿Quién escribe el anuncio GLSA?, ¿Cómo se transmiten los anuncios? y ¿Cómo se almacenan o guardan los anuncios?. Documentamos la corrección en un borrador del GLSA, el cual debe ser tener al menos 2 comentarios positivos antes de que se publique. Usamos una herramienta llamada GLSAMaker que nos ayuda a asegurar la consistencia entre todos los anuncios GLSA. El anuncio GLSA es escrito por el coordinador de GLSA o algunas veces por alguno de nuestros Aprendices de Seguridad (Coordinadores de GLSA en fase de entrenamiento). Los anuncios GLSA se envían por correo electrónico a gentoo-announce y otras listas de seguridad, aparecen de forma automática en un feed RDF, y en la Página de Seguridad de Gentoo. Finalmente, los moderadores de los foros los copian para que aparezcan como anuncios en los foros. Las fuentes XML de los anuncios GLSA son parte del árbol portage (están en metadata/glsa) y se sincronizan en todas las máquinas de los usuarios, para permitir el uso de la herramienta (experimental por ahora) glsa-check (que es parte del paquete gentoolkit). ¿Qué otros consumidores hay de los anuncios GLSA? Aparte de los usuarios, ¿hay otras organizaciones que sean alertadas? Le avisamos a linuxsecurity.com de manera que incluyan GLSAs en su página de avisos. El diccionario CVE MITRE también incluye referencias a GLSA. ¿Hay herramientas automáticas o scripts que use el equipo para hacer estas tareas? Usamos GLSAMaker, una herramienta escrita por Tim Yamin (plasmaroo), para ayudar a escribir el código XML del GLSA y su contraparte en formato de texto simple. ¿Cuál es el estado de la funcionalidad "emerge security" para identificar y corregir problemas de seguridad usando portage? La funcionalidad "emerge security" está actualmente bajo una fase de pruebas con la herramienta "glsa-check", la cual es parte del paquete gentoolkit. Ésta nos permite identificar qué GLSAs afectan nuestro sistema y reparar automáticamente los paquetes vulnerables. Cuando esté terminada, el equipo de portage la integrará en alguna de sus herramientas como emerge. Alentamos a que nuestros usuarios usen la última versión de glsa-check y reporten cualquier error usando bugzilla. ¿Dónde pueden conseguir los usuarios información sobre el equipo de seguridad? Nuestra página principal es el portal de Seguridad en Gentoo en security.gentoo.org. Éste contiene enlaces a documentos relacionados a nuestra política de seguridad, los últimos anuncios GLSA y mucha información útil. Las personas que les gustaría unirse al proyecto de Seguridad en Gentoo deberían leer la página Web del Proyecto de Seguridad, y en particular la guía de Coordinadores GLSA y la página de padawans en Seguridad para que tengan una visión de lo que necesitamos. ¿Cuáles son algunas de las iniciativas recientes que ha tomado el equipo de seguridad? El año pasado, establecimos adecuadamente los procedimientos de manera que todas las reglas no escritas que seguía el equipo, tengan una referencia en el documento de políticas. También formamos un nuevo equipo que asegurará que mantengamos todo el tiempo la vigilancia en temas relativos a seguridad. ¿Qué olvidamos preguntar y que deberíamos conocer? Quizás nuestra estructura de administración. Kurt Lieber (klieber) es el administrador estratégico, Sune Kloppenborg Jeppesen (jaervosz) y yo somos los administradores operacionales. Open-Xchange (OX) es el servidor de groupware de código abierto en el cual está basado el SuSE Linux Openexchange Server (SLOX) de Novell. Open-Xchange fue de código cerrado hasta el 30 de Agosto de 2004 cuando fue publicado bajo la Licencia Pública GNU. OX une la tecnología popular para servidores de código abierto mediante la integración de proyectos existentes (SMTP, IMAP, LDAP, Apache, Tomcat, y PostgreSQL) para proporcionar un poderoso entorno de colaboración y mensajería. Algunas características de interés incluyen e-mail, gestión de proyectos, almacén de versiones de documentos, calendario compartido, y base de datos de conocimientos. Se puede acceder con una interfaz web, o bien mediante clientes como Evolution, la suite de Mozilla (Thunderbird y Sunbird) y algunas otras aplicaciones de terceros que soportan WebDAV. Actualmente, Open-Xchange está en desarrollo con una versión candidata a estable (v0.8) en Marzo de 2005. Si quieres ver qué es OX antes de ponerte manos a la obra con la a veces desalentadora instalación, puedes probarla utililizando la demo en línea. Instalación y soporte Actualmente hay dos maneras de instalar OX en Gentoo Linux: utilizando el ebuild de Bugzilla (no está actualmente en el árbol de Portage), o instalándolo manualmente. Una página de Wiki explica la instalación utilizando el ebuild, pero para la mayoría de los pasos necesarios para tener OX funcionando correctamente, un COMO de la instalación manual cubre las las configuraciones previas también, así como la extensión y mejoras de Open-Xchange. Para preguntas específicas de Gentoo hay un hilo del Foro de Gentoo con algunos cientos de mensajes, que tiene la mayoría de las respuestas que hay disponibles hasta el momento. Si todavía no estás familiarizado con los servidores que utilizan OX, prepárate para una empinada curva de aprendizaje, y para leer un montón. La mayoría de los problemas experimentados comprenden la configuración LDAP, la integración Apache/Tomcat, y la autenticación SASL. Todos los servidores que van a incorporar OX necesitan estar configurados apropiadamente y funcionando antes de que puedas comenzar con la instalación de Open-Xchange.
OpenMotif: Vulnerabilidades múltiples en libXpm La librería libXpm, incluida en OpenMotif, contiene vulnerabilidades múltiples que pueden potencialmente permitir la ejecución remota de código arbitrario.(NE: Esta es la misma vulnerabilidad que se solucionó el pasado Noviembre en xorg-x11) Más información en el Anuncio GLSA PostgreSQL: Alteración de privilegios locales El servidor PostgreSQL puede ser engañado por un atacante local de manera que pueda ejecutar código arbitrario. Más información en el Anuncio GLSA Python: Ejecución de código arbitrario a través de SimpleXMLRPCServer Los servidores XML-RPC basados en Python son potencialmente vulnerables a la ejecución remota de código arbitrario. Más información en el Anuncio GLSA pdftohtml: Vulnerabilidades en el código procedente de Xpdf pdftohtml incluye código vulnerable de Xpdf para el manejo de archivos PDF, posibilitando la ejecución de código arbitrario al convertir un archivo PDF malicioso. Más información en el Anuncio GLSA Mailman: Vulnerabilidad en el cambio de directorio Mailman falla al limpiar adecuadamente la entrada proveniente de un usuario, lo que lleva a divulgación de información. Más información en el Anuncio GLSA Webmin: Filtrado de información en el paquete binario Gentoo El paquete binario Webmin construido mediante Portage accidentalmente incluye un archivo que contiene la clave local cifrada del superusuario. Más información en el Anuncio GLSA Perl: Vulnerabilidades en el envoltorio perl-suid Se han descubierto vulnerabilidades en el envoltorio perl-suid que potencialmente pueden llevar a la sobreescritura de archivos y la ejecución de código con privilegios elevados. Más información en el Anuncio GLSA mod_python: Vulnerabilidad en el Manejador de Publicación mod_python continen una vulnerabilidad en el manejador de publicación que puede potencialmente permitir divulgación de información. Más información en el Anuncio GLSA Quitar las banderas USE de tipo no [inserte su característica aquí] del árbol portage Michiel de Bruijne escribe: "Hay bastantes ebuilds en el árbol portage que hacen uso de la bandera USE no [inserte su característica aquí]. Así que, básicamente al desactivar el uso de la bandera USE se obtienen más características. Ganar dependencias extra al desactivar la bandera USE es una posibilidad. Pero esto tiene peligrosos efectos secundarios ...". La siguiente discusión nos muestra bien por qué no son buenas esas banderas USE. Estabilización automática de paquetes Apróximadamente cada 6 meses sale a flote la misma discusión: ¿Cómo mantener actualizados los paquetes en portage? Una aproximación ingenua sería una estabilización automática después de cierto periodo de tiempo. Este hilo nos muestra por qué para la mayoría esto no parece ser una buena idea ... ¿Cerrar o resolver un error, qué es esto? Marius Mauch escribe: "He notado una reciente tendencia introducida por unos pocos nuevos desarrolladores: Cambiar el estado de un error de RESUELTO a CERRADO. Personalmente, encuentro esto molesto y completamente inútil. ¿Podemos acordar en no hacer eso a menos que exista una razón técnica para ello?. No ve beneficio alguno en esto, sólo significa que los errores cerrados ahora están divididos en dos "categorías" sin mucha diferencia". EE.UU.: Evento Gentoo Bugday en el GUL de la Universidad Estatal de Oregon Los Gentoo Bugdays se llevan a cabo normalmente el primer sábado de cada mes, los desarrolladores y usuarios de todas partes se reunen en irc y revisan el bugzilla de Gentoo en busca de cualquier cosa que necesite ser reparada. El 5 de Febrero, el Grupo de Usuarios de Linux de la Universidad Estatal de Oregon tomó la oportunidad y convirtió el evento virtual en un real. Doce miembros del OSLUG se reunieron en el Weatherford Hall, el edificio residencial de la Universidad Estatal de Oregon. Ayudados por una lista precompilada de errores preparada para esta ocasión por los organizadores del evento, se corrigieron errores desde las 9:00 hasta las 16:00 , se esperaba que el canal oficial de IRC #gentoo-bugs estuviera lleno y habían computadores dispersos sin ningún orden en la sala, cada uno con un decidido cazador de errores de Gentoo en frente de la pantalla.
Alemania: Herramienta de almacenamiento para Gentoo Linux Las versiones comerciales de aplicaciones de Linux con soporte oficial fuera del reino de RedHat/SuSE/Mandrake son bien escasas. Una compañía alemana, SEP AG, anunció que se encuentra disponible su producto de administración de almacenamiento "SEP sesam" para Gentoo Linux. "Tradicionalmente estuvimos atados a SuSE Linux, pero teníamos a Gentoo en nuestro radar desde que vimos la impresionante instalación que Lars Weiler hizo en un clúster Proliant de HP el año pasado en la LinuxTag en Karlsruhe", recuerda el gerente de ventas de SEP, Johann Krahfuss (ve también el Reporte del BSG del 28 de Junio de 2004 (en inglés). "Así que cuando nuestros primeros clientes nos pidieron una adaptación de SEP sesam a Gentoo Linux, no nos tomó por sorpresa". La institución de investigación federal alemana Fraunhofer Gesellschaft fue la primera en pedir la instalación de SEP sesam dentro de un ambiente con Gentoo Linux, "y ya que no encontramos problemas, sentimos que está lista para lanzarla oficialmente", nos dice Krahfuss. Una versión de prueba por 30 días (incluyendo soporte) está disponible para descargar desde el sitio Web corporativo. SEP sesam está diseñado para administrar el almacenamiento de datos en redes heterogéneas, incluyendo Linux, BSD, Solaris, TRU/64, OpenVMS, Windows y MAC OS X. La compañía estará presente en la exposición de la próxima semana Días de Solución de Almacenamiento CRN 2005 en Neuss (enlace sólo en alemán). Newsforge (8 y 9 de febrero de 2005) Newsforge publicó un artículo en dos partes sobre cómo usar MySQL como referencia para medir el desempeño de Sistemas Operativos, escrito por Tony Bourke. Las pruebas de desempeño se concentraron en los Sistemas Operativos de servidor Open-, Net- y FreeBSD, Solaris 10 y Linux como plataformas de ejecución de la base de datos MySQL, y "entre una multitud de distribuciones" Gentoo fue seleccionado para representar a Linux, usando las versiones del kernel 2.4 y 2.6 (gentoo-sources) con ReiserFS. "Con Gentoo fue relativamente fácil instalar NPTL, lo cual usé para las pruebas del kernel 2.6," comenta Tony Bourke, "aún cuando no hubo ninguna diferencia con los resultados del kernel 2.6 sin NPTL." La primera parte del artículo explica únicamente las herramientas y metodología, mientras que el estudio de desempeño fue publicado en un artículo por separado - con resultados asombrosos, Gentoo Linux claramente ganó todas las pruebas individuales. Curiosamente, el sobresaliente desempeño de Gentoo provocó quejas sobre la "ventaja injusta" de usar una distribución Linux basada en código fuente, y posiblemente optimizada para el procesador usado en las comparaciones. El presidente de Sun Jonathan Schwartz aplaudió el esfuerzo OpenSolaris de Gentoo en una entrevista publicada por CNET la semana pasada. Mientras explicaba el modelo regulatorio de OpenSolaris a su entrevistador Stephen Shankland, afirmó que "Solaris es ahora oficialmente un sistema neutral en cuanto a la plataforma se refiere" y prevé que aparezcan "diez o más" distribuciones OpenSolaris independientes de Sun en el mercado. Security Focus (2 de Febrero de 2005) El columnista Jason Miller afirma que el manejo de la seguridad en el kernel Linux es defectuoso "y necesita ser reparado inmediatamente". El artículo en securityfocus.com, una publicación leída principalmente por profesionales de la seguridad, es severamente crítico de la forma en que se da seguimento a los errores de seguridad en el kernel Linux. Pero el autor, auto-proclamado un "gran seguidor de los sistemas operativos basados en BSD", también tiene buenas noticias: "Una vez que empezamos a considerar a las distribuciones de Linux como Sistemas Operativos completos, encontramos algunas con personas oficialmente encargadas de la seguridad, así como con páginas relativas a la seguridad similares a las que proporcionan los principales sistemas basados en BSD. Gentoo Linux es un buen ejemplo de esto". Réseaux & Télécoms (3 de Febrero de 2005, en francés) Como una respuesta directa a la columna de Jason Miller en Security Focus, la revista francesa de redes y telecomunicaciones mira más allá del kernel en cuestiones de seguridad: Tanto las fallas en aplicaciones individuales que no dependen del kernel, como la diseminación de información relativa a la seguridad, se identifican como áreas de actividad igualmente importantes para los "cazadores de errores en los programas de código abierto." El artículo "Noyau Linux : Mais où est la sécurité ?" concuerda con la conclusión de Miller de que "las cosas están cambiando rápidamente y en la dirección correcta", y elogia a Thierry Carrez (ver entrevista) como un ejemplo de "trabajo impresionante." Con el actual ritmo de discusión sobre la estructura del manejo de la seguridad y la diseminación de información, es tiempo de "mostrar un poco de optimismo," dice el autor Marc Olanie, y señala que a Microsoft le tomó dieciocho años estandarizar sus procedimientos de seguridad -- "si es que ya lo hicieron." Blogs de Sun (31 de Enero de 2005) Eric Boutilier, un ingeniero de Sun, Inc. se está preparando para hacer desarrollo Gentoo sobre OpenSolaris, y publicó en su blog en el sitio de Sun sus primeros intentos de familiarizarse con Portage en Linux. Su elección de material de instalación es peculiar - Vidalinux, un clon de Gentoo, en lugar de una instalación estándar, y una laptop Portégé con cinco años a cuestas - pero rápidamente se sincronizó con el comportamiento normal de los usuarios de Portage frente a largas compilaciones: "Ni modo. Lo dejé compilando felizmente y me fui a trabajar." La comunidad Gentoo usa Bugzilla (bugs.gentoo.org) para registrar y seguir errores, notificaciones, sugerencias y otras interacciones con el equipo de desarrollo. Entre el 06 de Febrero de 2005 y el 13 de Febrero de 2005, la actividad en el sitio tuvo como resultado:
De los 8036 errores abiertos actualmente: 102 están etiquetados como 'blocker', 243 como 'critical', y 600 como 'major'. Los desarrolladores y equipos con más errores cerrados durante este periodo son:
Los desarrolladores y equipos con más errores nuevos asignados durante este periodo son:
Magia en portage: Identificar paquetes obsoletos El desarrollador de Gentoo Brian Harring ha diseñado un sistema muy eficaz para identificar esos paquetes que tenemos instalados cuyos ebuilds ya no existen en el árbol de Portage (ya sean del árbol oficial o del PORTDIR_OVERLAY). Usando las maravillosas opciones de empaquetar código que ofrece Python, el método cabe en una sóla línea:
Veamos qué hace exactamente. Por ejemplo, si tenemos instalado un paquete -digamos foo-1.2.3- pero ya no se encuentra disponible en el árbol, este script nos lo dirá. Un chequeo simple para paquetes que ya no están disponibles (sin importar la versión) quedaría como sigue:
Finalmente, si quieres ignorar el paquete foo-1.2.3 aunque ya no exista en el árbol pero sí una revisión foo-1.2.3-r1, el siguiente script ignorará el paquete teniendo en cuenta solamente aquellos paquetes que hayan desaparecido completamente de Portage.
Para terminar, cabe señalar que ningún script de los explicados tiene en cuenta los paquetes 'inyectados' (package.provided) sino sólo aquellos que fueron realmente instalados desde un árbol de Portage existente. Pero si se quiere ignorar también los inyectados, esto servirá:
Sí, sabíamos que esto te iba a gustar. Todo lo explicado funciona también para paquetes individuales que tienes en el árbol overlay, por ejemplo /usr/local/portage. Estos se evalúan al mismo tiempo que los oficiales. Prueba estos scripts, no puedes romper nada con ellos, simplemente informan de lo que encuentran y dejan al usuario la decisión de qué hacer con dicha información. Los siguientes desarrolladores dejaron recientemente el equipo de Gentoo:
Los siguientes desarrolladores se unieron recientemente al equipo de Gentoo Linux:
Los siguientes desarrolladores recientemente cambiaron de rol dentro del proyecto Gentoo Linux:
¿Interesado en contribuir al Boletín Semanal de Gentoo? Envíanos un correo electrónico. 11. Opiniones y/o comentarios al BSG Por favor, envíanos tus opiniones y/o comentarios y ayuda a hacer mejor el BSG. 12. Información de subscripción al BSG Para subscribirte al Boletín Semanal de Gentoo (en inglés), envía un correo electrónico en blanco a gentoo-gwn-subscribe@gentoo.org. Para desubscribirte del Boletín Semanal de Gentoo, envía un correo electrónico en blanco a gentoo-gwn-unsubscribe@gentoo.org desde la dirección de correo electrónico con la cual estás subscrito. El Boletín Semanal de Gentoo también está disponible en los siguientes idiomas:
|
|
