Acabo de leer un interesante artículo en SomosLibres.org donde su autor nos hace ver la posibilidad de que GNU/Linux también tenga una puerta trasera para la NSA. La cuestión es, y cito textualmente un fragmento de dicho artículo: A grandes rasgos, hay un elemento privativo -es decir, de código cerrado, sin la posibilidad de ser analizado- en Linux, creado por Intel e impuesto en el kernel por el mismo Linus Torvalds, en contra de la opinión de Matt Mackall.
Comentarios
un paloooo!!!
Me parece que hay bastante de bulo en esto del generador de números aleatorios de linux.
http://lamiradadelreplicante.com/2013/09/09/backdoor-en-linux-de-la-nsa-no-invente-senora/
#0 Siempre se puede pasar a OPEN BSD, que no admite blobs binarios ni código no libre en su sistema.
http://www.openbsd.org/
#2 Pues, si el código libre no comienza ni termina con linux, camarero!!, camarero!! otro fork de GNU por favor!!
#3 Open BSD no es GNU, de hecho Open BSD si es UNIX, no como GNU.
#4 No hay nada que auditar. El backdoor esta en un BLOB binario proporcionado por Intel, 0 código fuente.
http://es.wikipedia.org/wiki/Blob_binario
#7 Ese blob binario no está desde hace mas de un año y solo estuvo de de julio del 2011 a julio del 2012.
#7 lo se lo se, ¿pero como podremos vivir sin san richard de gnu? por eso pido otro frok de gnu
#3 #7 http://trisquel.info/en/forum/duda-sobre-el-kernel-linux-libre
"que no admite blobs binarios ni código no libre en su sistema."
¿Estas seguro? El instalador me permite bajar firmware. No se cuán de libre será.
http://firmware.openbsd.org/firmware/
En la base no lo baja, desde luego, pero por si acaso, mejor mantener los dos. OpenBSD y Linux-libre. Debian sirve, si metes el repo de josexf y purgas el kernel instalado al principio.
O Trisquel, si quieres algo 100% libre desde el inicio.
#2 Las puertas traseras más escandalosas
Las puertas traseras más escandalosas
securitybydefault.com#8 No está demostrado.. El tema saltó en el 2010 y hasta ahora no se ha dicho nada más, quizá solo ha sido más FUD sobre el SL..
Jason Wright, answered the posting from de Raadt saying,
"Every urban lengend is made more real by the inclusion of real names, dates, and times. I will state clearly that I did not add backdoors to the OpenBSD operating system or the OpenBSD crypto framework (OCF). The code I touched during that work relates mostly to device drivers to support the framework. I don't believe I ever touched isakmpd or photurisd (userland key management programs), and I rarely touched the ipsec internals (cryptodev and cryptosoft, yes). However, I welcome an audit of everything I committed to OpenBSD's tree. I demand an apology."
http://www.linuxjournal.com/content/allegations-openbsd-backdoors-may-be-true
#1 #2 No es ningún blob binario, es una instrucción de hardware de los procesores intel que se llama desde el kernel. Y los BSD también lo hacen:
OpenBSD
http://www.openbsd.org/53.html
En el changelog: Add i386/amd64 support for the rdrand instruction found in recent Intel processors.
FreeBSD
Cambio que añadió el soporte: http://svnweb.freebsd.org/base?view=revision&revision=240135
Y nadie ha demostrado que esa instrucción de hardware no sea segura, de momento es simple suposición. En Linux si quieres desactivas el generador de números aleatorios de la arquitectura y listo, problema resuelto ya no se usa la instrucción. Concretamente es la clave CONFIG_ARCH_RANDOM por si alguien quiere hacerlo.
#12 Tienes razón, gracias por la aclaración.
Joder con esto de los blobs binarios más de uno lo pasaría mal desarrollando con métodos tipo caja negra.
En caso de que se confirme, ok ese chacho de código no se puede leer y modificar ¿se puede eliminar? entonces el problema no es tan grabe, al menos si no usamos intel.
#1 Será grave porque el agujero estaba ahí y nadie se había dado cuenta.
Ahora quién garantiza que no hay otro? Se van a auditar una por una todas las líneas de código? Con pares para estar seguros de que no hay alguien de la NSA en la auditoría?