Andamos otra vez a vueltas con la seguridad en Linux, y todo a raíz de un artículo publicado ayer en The Washington Post en que se cuestionaba la fiabilidad del sistema del pingüino en ese aspecto.
Aunque se ve que el periodista no controla demasiado del tema –llega a echar a Linux la culpa de hacking de Ashley Madison porque corría en sus servidores…–, el artículo es interesante porque participan varios expertos de seguridad, además del propio Linus Torvalds, que se defiende de las acusaciones de tener un enfoque demasiado pasivo, casi indiferente en ese aspecto.
Los que seguimos a Torvalds desde hace tiempo, sabemos que lo que realmente le preocupa es la calidad del código (tiene momentos de ira legendarios debido a eso) y que se rebela ante lo que el llama el «circo de la seguridad» y algunos charlatanes que anidan en esa industria.
Para Linus la seguridad nunca va a ser perfecta y ese aspecto es solo uno más de los que constituyen el sistema operativo (en ese punto coincido con el…para mi es igual de hacker uno que domina Krita que el que juega con nmap y metasploit…sin necesidad de ser un tarado social como el de Mr. Robot), y todo debe moverse en el justo equilibrio de permitir que el sistema se pueda utilizar con comodidad.
Linux es robusto, bien construido pero no inmune a tener sus bugs o fallos de seguridad, por una mala implementación de código en un momento dado.
Si nos fijamos en lo que ha sido su desarrollo desde que apenas tenía 10 000 lineas de código a los 20 millones de ahora, siempre ha respondido a cualquier fallo con el clásico «fallo detectado / vamos a parchear lo antes posible» (en la mayoría de dispositivos Android ni eso…pero eso ya es culpa de los fabricantes principalmente).
Lo normal y correcto, me diréis…bueno en realidad no tanto, las cosas se pueden hacer todavía mejor. Por ejemplo vemos que en el espacio del usuario se dispone de una segunda capa de seguridad (SELinux o AppArmor) provista por el propio kernel, por si algunas de las aplicaciones se desmadra y tienen comportamientos no deseados.
Algo parecido es lo que se pretende hacer ahora en el núcleo, adelantarse a los acontecimientos y no depender de que en un momento dado, y en ocasiones dependiendo de la suerte, se descubra una vulnerabilidad, para corregirla y ser inmune a ella.
Para ello se acaba de lanzar un proyecto llamado Kernel Self Protection Project, que pretende endurecer Linux, luchando de forma genérica contra los métodos de explotación y clases de errores más habituales, automatizando mucho más todo el tema de la seguridad..
Algo similar se había intentado antes con proyectos como PaX y Grsecurity, que no tuvieron la acogida esperada entre los principales desarrolladores del Kernel.
En este caso es diferente ya que el Kernel Self Protection Project, estará bajo los auspicios de la Core Infrastructure Initiative, una iniciativa de la Fundacion Linux que cuenta con el patrocinio de algunas de las principales empresas tecnológicas –Amazom, Google, Facebook, Dell, IBM,…– y que ya ha dado soporte económico a varios proyectos como: openSSL, GnuPG, ntp, la gente que trabaja en los reproducible builds, etc…
Además vemos que cuenta con el beneplacito de gente muy influyente en linux como Greg Kroak-Hartman, que ya ha felicitado públicamente al impulsor del proyecto, un desarrollador que trabaja para Google llamado Kees Cook.
Podéis encontrar más información sobre todo esto, en la wiki del Kernel Self Protection Project.
Si ya Linux es lo bastante robusto, con esto la cosa se les va aponer más dificl todavía a los que quieran trastear donde no deben en servidores y workstations que trabajen con Linux.
Pues si…de todas maneras el problema pienso que no es tanto el kernel, sino que a veces otros proyectos que inciden en la seguridad del software libre y de rebote en GNU/Linux están inframantenidos, como pasó hace poco con lo Heartbleed o Shellshock.
Por eso es importante que las grandes empresas que se benefician del software libre se impliquen en su mantenimiento con iniciativas como las la Fundación Linux.
Para mi, 80% del tiempo, el problema tiene dos patas y se sienta en una silla:
Mi empresa se dedicó a fortalecer un sistema, asegurarse de que cumpliera el fedRAMP, hacer tests con Metasploit, ataques con VMs maliciosas, etc..
Una semana después de producción tuvieron un ataque, la razón: Un sysadmin deshabilitó las claves ssh y habilitó passwords de texto para «facilitar» las operaciones y además dejó un puerto abierto directo a internet para conectarse desde casa sin VPN.
^ o ^ ;;;;; Adivina hacia que dirección cayo la «mierda».
Si vale. Los sysadmin descuidados son bastante molestos. Aunque a veces puede pasar al revés, cómo cuando quise reforzar la seguridad de la red en unos hoteles 4 estrellas donde daba trabajaba, pero los ejecutivos fueron los que negaron la propuesta porque les apreció «demasiado complicada» >:(
Si hay que endurecer, se endurece. Yo ya la tengo dura…
.
.
.
.
Tengo dura la seguridad, claro, que es de lo que estamos hablando.
eso en un linuxero se da por supuesto XD
Google, Facebook, no se no se. Igual hay que pasarse a Hurd en un tiempo 😀
Facebook es el horror, te enteraste de la última?
Bloquea todas las publicaciones que lleven a Tsu.co (una red social nueva) de forma automática, para no darle publicidad
Mantengo la página del blog porque hay gente que lo sigue por ahí, pero a nivel personal le puede dar bastante por saco…
Por cierto amigos, ahora también ando por quitter (GNU/Social) y le puse el botoncito al blog para compartir los post
Ya te sigo en GNUSocial, soy @liberadalinux@quitter.se
@dalmemail En realidad no es que lleven a tsu.co basta con que aparezca el termino «tsu.co» en algo que publiques, para que lo bloqueen
Creo que habría que hacer una nota aquí que ni PaX ni GrSecurity están muertos y de hecho es lo que usa cualquiera que prioritice la seguridad sobre otros factores en sistemas linux.
Si que es cierto que no están integrados (y dudo que lo estén) entre otras cosas por el conflicto que surgió hace ya bastante tiempo entre spender y Torvalds.
Ya si queréis mirar porque este proyecto surge ahora, igual esta carta del proyecto grsecurity tiene algo que ver: https://grsecurity.net/announce.php
Mucho de esos fallos son típicos de programar en C cuando a lo mejor se puede evolucionar a un lenguage más parecido a Java donde el propio lenguage ayude a tenerlos bajo control.
¡¿JAVA?!… ¡¡Asco!!… java es el lenguaje mas ineficiente e inestable que he conocido en mi vida. No me gusta para nada, desde que lo probe alla en 1998 con IE 6.0. Desde entonces he visto lo terrible que puede ser usarlo, JAVA nunca debió existir, es el Diablo de los lenguajes de programación. Te tienta con su belleza y te hace sufrir con su horrible rendimiento y inestabilidad! XD
SI ese es tu solucion que sigan trabajando en C, C es vida!!:D