Lisandro Pardo
El universo Linux ha cambiado para siempre. Su tecnología dejó de ser «algo raro» en las charlas informáticas, y hoy se encuentra presente en millones de smartphones, tablets, módems, routers, dispositivos vestibles y vehículos, sin olvidar su dominio en el espacio de servidores. Con la llamada Internet de las Cosas golpeando la puerta, la seguridad del kernel Linux no podría continuar con su modelo actual, y múltiples voces recomiendan la implementación de una nueva estrategia que permita al kernel «protegerse a sí mismo», quedando un paso adelante de las vulnerabilidades.
A dos metros de mi escritorio junta polvo un smartphone con Android 2.3 que hoy cumple la función de linterna. Si bien todo lo que necesito hacer para que regrese a su papel original de smartphone es colocar un chip, la versión del sistema operativo es tan antigua que no sé si vale la pena correr el riesgo. En esa misma situación se encuentran millones de dispositivos con un kernel Linux en segundo plano. Son robustos, flexibles, y estables, pero al no recibir actualizaciones, se vuelven inseguros. Desarrolladores, fabricantes, distribuidores, proveedores de conectividad y usuarios, todos cargan con una pizca de culpa sobre los hombros, y si a esta situación le sumamos el potencial de la Internet de las Cosas, nos vemos obligados a hablar de millones de dispositivos adicionales completamente en riesgo. Se espera que algunos de esos gadgets funcionen durante cinco o diez años sin recibir un solo update, y con esa mecánica, el kernel Linux queda atrapado entre la espada y la pared.
Dicho de otro modo, el kernel Linux no puede seguir persiguiendo bugs. De acuerdo a Kees Cook, desarrollador en Google y encargado del Linux Kernel Self-Protection Project, el «tiempo de vida» de un bug en el kernel (o sea, desde su introducción hasta el parche) oscila entre los 3.3 y los 6.4 años. Estos vacíos se convirtieron en un parámetro inaceptable, y los atacantes observan con cuidado cada nuevo «commit» para detectar y explotar bugs. Eso perfila a la protección avanzada del kernel como una misión fundamental, sin embargo, existe otro inconveniente: El 85 por ciento de los bugs en el kernel no nacen de su núcleo, sino de los controladores integrados. El bajo control de calidad que demuestran algunos fabricantes es preocupante, y contribuye a la incertidumbre de seguridad que atraviesa al kernel.
Ahora… los desafíos no son solamente técnicos, sino también políticos. El ojo entrenado notará que este «conflicto» tiene mucho en común con el debate de «kernel monolítico vs. microkernel» que agitó a los entusiastas de Linux en más de una oportunidad, y que sigue siendo fuente de notables intercambios. Aún así, como dije al principio, el universo Linux ha cambiado para siempre. Nuevos problemas de seguridad requieren nuevas soluciones, y una especie de «inmunidad general» en el kernel no suena tan mal. Retirar a los controladores del kernel y volcar su funcionamiento hacia «userland» dista mucho de ser una solución mágica, pero ahí está el punto: No se necesitan soluciones mágicas, sino soluciones robustas que protejan el kernel a largo plazo. La charla de Kees Cook dura poco más de 45 minutos, y allí detalla algunos de los avances hechos por el Self-Protection Project, además de sugerencias adicionales para implementar en el futuro. Si este tema te atrae, vale la pena verla.
