Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Multiples vulnerabilidades en el kernel de linux

very happy's Diary
Por very happy
departamento Actualizando que es gerundio , Sección Diarios
Puesto a las Sun Jul 25th, 2004 at 11:08:16 AM CET
Como podemos ver en esta noticia o en esta otra ( resumen en castellano ) se han descubierto multiples fallos en el kernel de linux cuya gravedad va desde la posibilidad de sufrir un ataque DoS hasta la posibilidad de cambiar los permisos de /proc y es por ello que se recomienda actualizar en cuanto se pueda el kernel

 


< Un vistazo a PHP5 (I) (8 comments) | Lenguajes de Desarrollo Libre y Puestos de Trabajo (14 comments) >
Enlaces Relacionados
· esta noticia
· o en esta otra
· resumen en castellano
· More on very happy's Diary
· Also by very happy

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Multiples vulnerabilidades en el kernel de linux | 11 comentarios (11 temáticos, editoriales, 0 ocultos)
Todo son presiones. (4.50 / 2) (#4)
por toomany a las Mon Jul 26th, 2004 at 09:14:50 AM CET
(Información Usuario) http://www.toomany.net

Pues eso; presión presión presión.
Presión de las empresas que están invirtiendo muchísimo en el sistema GNU/Linux, presión de los cientos de personas que colaboran activamente con el kernel Linux, presión por la adopción acelerada de nuevas características que deberían madurar mucho más, así como drivers para dispositivos que tendrían que seguir por el mismo camino.

Todo lo anteriormente mencionado, y muchas más cosas que a buen seguro me dejo en el tintero, son cosas que, cuando trabajas con otros sistemas open source, como es el FreeBSD en mi caso, durante más de dos años vas viendo una vez detrás de otra.

¿Sería buena idea que el desarrollo del kernel Linux esté mucho más controlado a como lo está ahora, al estilo de como está en FreeBSD?
¿No sería buena idea dejar que el kernel vaya haciéndose hueco "a su paso", sin forzar la situación, y que los nuevos drivers y características del mismo vayan adaptándose con tranquilidad "y buen paso"?

Si todo lo expuesto anteriormente funciona bien para FreeBSD, hablando de estabilidad y seguridad, creo que debería ser bueno también para Linux.
Desde hace muchos años estos dos magníficos proyectos se van alimentando uno del otro, con muchísima más armonía entre desarrolladores de "un bando" y otro de lo que la gente se podría imaginar. Los flames suelen ocurrir solamente fuera de los "cores" fuertes de desarrollo de un sistema y el otro kernel; basicamente existe un gran respeto entre desarrolladores de un lado y del otro. ¿Por qué no intentar, ni que sea en una parte sola del kernel, una manera de trabajar al estilo del core de FreeBSD, y, si van bien, ir probando sobre otras areas del mismo?
Este tipo de vulnerabilidades, y su cantidad, suelen ser unos pedazos de torpedos directos a la linea de flotación del kernel Linux, y es oportunidad que no pierden los que preferirían no tener a este/os tipo/s de sistema/s operativo/s en el mercado robándoles clientela una vez tras otra.

Ya sé que existen los dos tipos de desarrollo; "catedral" y "bazar", y que para unos es mejor uno que el otro. Pero creo que dejando de lado que no dejan de ser más que meras opiniones, pienso que en una etapa puede ser buena una opción, y luego la otra opción. Osea, ya que puedes elegir y no hay nadie que te obligue, ¿porqué razón no adoptar el modelo que más beneficie en un determinado momento?

Por otra parte, es probable que acabe de decir una sarta de tonterias, o bien que no termine de enterarme de qué va el tema. Pero creo que, a riesgo de pecar de pedantería supina, después de más de 10 años en este mundo del Software Libre y GNU/Linux, algo se me debe haber quedado ¿no? :-p


Have a nice day ;-) TooManySecrets


 
Me pregunto (none / 0) (#1)
por melenas a las Sun Jul 25th, 2004 at 12:47:15 PM CET
(Información Usuario)

Me pregunto si quizás si el núcleo de Linux está en crisis debido a su arquitectura monolítica y difícilmente mantenible. Quizás si sigue avanzando es por la fuerza bruta de miles de programadores que programan, revisan y envían parches y nuevas características.

¿Quizás sea la hora de volver al núcleo microkernel? ¿una oportunidad para Hurd? ¿o volverá Tanembaum a vender licencias de Minix a 160$?


FDO. ER_MELENAS No te preguntes sólo que puede hacer el S.L. por ti sino también que puedes hacer tú por él.


Recurrente el microkernel (none / 0) (#2)
por ridiculum a las Sun Jul 25th, 2004 at 08:43:14 PM CET
(Información Usuario)

Linux nunca ha sido microkernel, por mucho que tenga la posibilidad de cargar y descargar modulos, asi que dificilmente puede volver a algo que nunca ha sido.

[ Padre ]


Ya lo sé (none / 0) (#3)
por melenas a las Mon Jul 26th, 2004 at 01:56:49 AM CET
(Información Usuario)

Yo me refería que a finales de los ochenta y principio de los noventa parecía que se imponían los núcleos microkernel, estaba el proyecto Hurd (que no termina de salir) y el propio Minix, además de que por la mitad de esa misma década otros sistemas operativos como OS/2, Windows NT y un proyecto fracasado del que ya nadie se acuerda llamado Freedows 98 también lo utilizaba (o trataba de hacerlo) y que quizás Linux fuera en su época un paso atrás tecnológico.

Por ello digo que quizás Tanembaum tenía razón al decir que un núcleo monolítico es difícilmente mantenible frente al diseño de microkernel y a los últimos fallos de seguridad me remito, estamos plagados de ellos y aunque se resuelven rápidamente gracias a la infraestructura que provee el software libre, ésto hace que nos pensemos si no debemos volver la mirada a los núcleos microkernel.

Si sendmail está siendo sustituido por postfix y/o qmail, mucho más seguros y menos complejos y bind sustituido en varias ocasiones por djbdns (aunque no tanto debido al cerramiento de Bernstain en algunas cuestiones), puede que no esté lejos la hora de que la gente se ponga en serio con el Hurd o con otro proyecto paralelo de parecidas características.


FDO. ER_MELENAS No te preguntes sólo que puede hacer el S.L. por ti sino también que puedes hacer tú por él.
[ Padre ]


Pues sí que te salen microkernels :) (none / 0) (#7)
por man ls a las Tue Jul 27th, 2004 at 01:33:12 AM CET
(Información Usuario)

Según Tanenbaum, aunque los de Microsoft vendieron que NT estaba basado en en un microkernel, era mentira cochina:
Microsoft afirmaba que Windows NT 3.51 era un microkernel. No lo era. Ni se parecía siquiera. Hasta ellos dejaron de decirlo con NT 4.0.
Lo mismo dicen de NeXT y Mac OS X: supuestamente basado en el microkernel Mach, en la práctica han tomado tantas cosas de FreeBSD que ya no tiene sentido decirlo. Los *BSD no usan microkernel ninguno de ellos, ¿verdad? Luego Tanenbaum sigue:
Algunos microkernels han tenido bastante éxito, como QNX y L4. No soy capaz de ver por qué la gente arma tanto ruido por una pérdida de rendimiento del 20% que puede causar un microkernel, cuando programan en lenguajes como Java y Perl que a menudo te hace perder rendimiento por un factor de 20x. ¿Qué problema hay con convertir un PC a 3.0 GHz en un PC a 2.4 GHz por un microkernel? Seguramente has tenido un sistema más lento que eso y estabas tan contento con él. Yo daría un 20% de rendimiento a cambio de un sistema robusto, estable, y sin muchos de los males que vemos en los sistemas operativos masivos de hoy.
No sé, no sé: los microkernels no acaban de despegar fuera de algunos sistemas en tiempo real, parece. Cuando todo el mundo se mueve en la misma dirección, algo debe haber, no sé si bueno o malo. Melenas, Linux (el kernel) será un paso tecnológico hacia atrás, pero compara con como van los de Hurd -- si hubiéramos tenido que esperar a que estuviera listo para usar un sistema operativo decente, a estas alturas estaríamos todos con algún *BSD, y leyendo *BSDToday, *BSDWN, escompos*bsd. Y a lo mejor, tan agusto :)

[ Padre ]


Panaceas (5.00 / 1) (#8)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Tue Jul 27th, 2004 at 11:24:26 AM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

Yo daría un 20% de rendimiento a cambio de un sistema robusto, estable, y sin muchos de los males que vemos en los sistemas operativos masivos de hoy.
Tanenbaum puede decir lo que quiera, pero yo no me creo esto de las panaceas. Si piensa que porque sea un nucleo tenga una arquitectura microkernel, automáticamente va a ser más robusto, estable y sin bugs, es que no vive en el mundo real.

La arquitectura y las decisiones de diseño pueden ayudar, pero no van a evitar jamás que haya bugs.

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]


 
WNT es microkernel en la línea de Mach (none / 0) (#9)
por jorginius ("jorginius" en Google Mail) a las Tue Jul 27th, 2004 at 03:17:49 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Depende del cristal con que lo miras. Si consideras a Mach un microkernel entonces supongo que WNT deberías ponerlo en el mismo saco.

Por problemas de eficiencia (de propagación las interrupciones), Mach incluye en el nucleo los manejadores de dispositivos, además de la comunicación entre procesos, el manejo de las interrupciones y el soporte del diagrama de estados. En teoría ningún microkernel debería incluir tal cosa.

El WNT original incluye los drivers, igual que Mach, y además el subsistema de control de objetos (seguir la pista a los recursos y control de acceso de los mismo) y el sistema de archivos.

Por otra parte, si lo que quieres es un Linux microkernel existen implementaciónes servidor Mach (MkLinux), de NT (coLinux) o de L4 (L4Linux)

[ Padre ]


 
Stallman dijo en Valencia... (none / 0) (#5)
por pbenavent a las Mon Jul 26th, 2004 at 04:37:42 PM CET
(Información Usuario) http://www.benavent.org

Stallman dijo en Valencia...que los desarrolladores del microkernel pensaban tomar otro rumbo y abandonar Hurd en favor de otro microkernel.

Invito a la audiencia del congreso de Lliurex a que colaboraran en el proyecto, pero advirtió a los que quisiesen sumarse que hay qu ser muy buen programador (melenudo sí, tonto no)

Hay dinero de empresas en OSDL, y por eso se mueve, pero ¿lo hay en Hurd? ultimamente estoy escéptico con algunas cosas, detras de grandes desarrollos hay desarrolladores, detras de ellos alguién pagandoles la jornada completa ... y eso lo hacen empresas que legítima y loablemente apoyan el desarrollo de Linux. (Ir a la portada y leer el hilo sobre el fork de Gnome)

Si todos tomasen en consideración la firma de melenas no sería a veces tan necesario el apoyo de las empresas.

En cualquier caso: lo que me gusta de esto es la libertad, aún ando buscando hardware y tiempo -más lo segundo- para echarle un tiento a OpenBSD para frontal de mi LAN doméstica, aunque me asusta un poco la sintaxis para las reglas del firegüal.

--
"El hombre es la medida de todas las cosas"
Protágoras
[ Padre ]


Sintaxis de pf (5.00 / 1) (#10)
por ridiculum a las Wed Jul 28th, 2004 at 12:49:42 AM CET
(Información Usuario)

Que ese detalle no te tire para atras. A mi juicio, la sintaxis del pf.conf es una maravilla. Es tremendamente simple comparada con, lo que a mi juicio es, el follon de iptables. En la faq de pf tienes practicamente todo lo necesario para poder hacer un fw bastante decente, QoS incluido.

[ Padre ]


Sintaxis de pf (none / 0) (#11)
por iarenaza a las Thu Jul 29th, 2004 at 02:02:14 AM CET
(Información Usuario) http://www.escomposlinux.org/

Aun estando de acuerdo en que la sintaxis de pf es bastante buena, sin embargo echo en falta algo que con iptables se puede hacer: usar toda las posibilidades del lenguaje de programación del shell a la hora de crear las reglas. Algo como lo siguiente es imposible de hacer con pf (no la funcionalidad, sino el escribirlo de forma tan condensada):

for port in 22 80 443
do
     iptables -A INPUT -p tcp --dport $port -j ACCEPT
done
Si bien es cierto que en las ultimas versiones de pf se pueden definir variables, la excesiva rigidez de su formato (primero variables y solo variables, luego reglas de nat/rdr y solo nat/rdr y por ultimo reglas de filtrado) hacen que para mi sea menos "mantenible" el conjunto de reglas si esta es amplia (en mi caso alrededor de las 100 reglas en total, entre NAT/RDR y filtrado), al no tener todos los aspectos "logicos" de una misma accion juntos.

Supongo que tendrá su razón de ser, pero se me escapa.

Saludos. Iñaki.

[ Padre ]


 
Sin miedo hombre!! (none / 0) (#6)
por toomany a las Mon Jul 26th, 2004 at 07:10:49 PM CET
(Información Usuario) http://www.toomany.net

Verás cómo te alegras enormemente de haber instalado el OpenBSD. Es una auténtica maravilla donde las haya... Y si es por el tema de la documentación, podrás comprobar (mejor manera que esta ninguna) por tí mismo como, después de ver la documentación del OpenBSD, o de cualquier otro BSD, la documentación existente alrededor de GNU/Linux te parecerá corta, vieja y un puro caos.
Si quieres, me lo dices y te paso links para que no tengas problemas algunos con el sistema de filtrado PF.
¡¡Aaaahhh!! ¡Que increible la familia *BSD! XDDD


Have a nice day ;-) TooManySecrets
[ Padre ]


 
Multiples vulnerabilidades en el kernel de linux | 11 comentarios (11 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda