Seguridad del kernel ahora: el método único de Linux para proteger el código
En la Open Source Summit Japan, el desarrollador de Linux Greg Kroah-Hartman recapitula el estado actual y los desafíos futuros de la seguridad del kernel, incluido el espectro de la regulación gubernamental y el dolor esencial de las actualizaciones incesantes.
Greg Kroah-Hartman, de la Fundación Linux, pronunció una charla exhaustiva esta semana sobre el estado actual y los desafíos futuros de la seguridad del kernel de Linux. Hablando en la Cumbre de Código Abierto (OSS) Japón 2023, Kroah-Hartman, mantenedor del kernel estable de Linux y miembro destacado del equipo de seguridad del kernel de Linux, arrojó luz sobre el panorama cambiante de la seguridad del software de código abierto, los desafíos regulatorios y La respuesta del kernel de Linux a estos problemas.
Apenas pasa un día sin que surja un problema de seguridad del software, y los gobiernos ahora están tratando de orientar cómo las empresas y organizaciones deben mitigar los problemas de seguridad. Sólo hay un problema: los gobiernos apenas entienden cómo utilizar el software, y mucho menos cómo los desarrolladores de código abierto crean software.
Por ejemplo, la Ley de Resiliencia Cibernética (CRA) propuesta por la Unión Europea está llena de buenas intenciones, pero no encaja bien con cualquiera que cree software de código abierto. Si bien la versión más reciente es mucho mejor, como señaló Kroah-Hartman, todavía significa que dado que "todo el mundo vende sus dispositivos y productos en la UE, esto definirá sus requisitos de seguridad".
¿Estamos preparados para hacer frente a esta nueva ola de regulación? No, no lo somos.
En cuanto a la comunidad Linux, Kroah-Hartman ha dicho que el equipo de seguridad del kernel de Linux es fundamentalmente reactivo, a diferencia de otros equipos de seguridad que adoptan una postura proactiva. Desde su creación formal en 2005, el equipo ha operado de manera informal, sin afiliaciones ni contratos corporativos. Esto permite la neutralidad y la flexibilidad al abordar las cuestiones de seguridad. Este enfoque ha fomentado la confianza entre las empresas y ha gestionado y clasificado eficazmente los problemas de seguridad.
"Hay otros grupos, equipos de seguridad del kernel y otros proyectos", añadió, "que son proactivos. Pero eso no es lo que hacemos. Simplemente reaccionamos ante los problemas".
Y hay muchos problemas que resolver. Por ejemplo, Kroah-Hartman destacó los desafíos actuales con la seguridad del hardware, particularmente a raíz de vulnerabilidades como Spectre y Meltdown. De hecho, como señaló, han pasado más de tres años desde que aparecieron esos graves errores de CPU y, aunque "siguen intentando solucionarlos en el hardware, hace unas horas se anunció otro. Así que esto no tendrá fin en el corto plazo". ".
Esto subraya las complejidades de lidiar con embargos de hardware y los ciclos de desarrollo de hardware más largos en comparación con los de software. Idealmente, Kroah-Hartman quiere que las empresas de hardware "se pongan manos a la obra más rápido", sentimiento del que se hacen eco los gobiernos y los organismos reguladores.
Kroah-Hartman también señaló que "mucha gente [hoy] no se da cuenta de que, si bien el modelo de distribución comercial de Linux no está muerto, ya no es ni mucho menos la mayoría. El 80% de los servidores y sistemas del mundo funcionan de forma gratuita y proyectos de código abierto basados en Debian, Fedora u openSUSE", no Red Hat Enterprise Linux (RHEL) o SUSE Linux Enterprise Server (SLES).
Esa realidad ha complicado los desafíos de seguridad porque, explicó Korah-Hartman, "las comunidades que trabajan con estos proyectos de código abierto no pueden firmar un acuerdo de confidencialidad (NDA) porque los miembros de su comunidad viven en otros países o trabajan para diferentes empresas. "
En cambio, el equipo de seguridad de los desarrolladores del kernel de Linux es un "grupo informal ad hoc" sin contrato. Kroah-Hartman continuó: "Y eso fue lo mejor que nos pudo pasar para preparar el escenario para que podamos hacer esto de una manera neutral para la empresa y el gobierno. Nos ha ahorrado muchos problemas".
Cómo funciona: las personas envían informes de seguridad a los miembros del grupo. Ni siquiera hay una lista de correo electrónico. Sólo hay un pequeño grupo que no representa a ninguna empresa. Kroah-Hartman añadió: "Todo se mantiene en silencio y, desde 2005, nunca hemos tenido filtraciones".
Lo que hacen, continuó Kroah-Hartman, "es clasificar los informes, descubrir qué está mal y atraer a los desarrolladores adecuados, si aún no están en la lista, para crear la solución lo antes posible. Luego se lanza este parche". incluido en la rama estable de Linux. Eso es todo."
Cuando dicen "lo antes posible", lo dicen en serio. "Una vez que tengamos una solución, lo máximo que esperaremos serán siete días. Esto es", continuó Kroah-Hartman, "después de que tengamos una solución. Cuando recibimos un informe, comenzamos a trabajar en ello lo antes posible". Recibimos algunas correcciones que tardaron más de un año. Hemos tenido algunos problemas de red. Creo que tardamos 18 meses en solucionarlo correctamente, pero una vez que lo solucionamos, se solucionó.
El grupo tampoco hace anuncios sobre correcciones de seguridad. "No anunciamos nada. No decimos nada especial. Simplemente lo insertamos para que parezca una corrección de error normal".
Sí, eso enoja a la gente. Pero, explicó Kroah-Hartman, "para las personas del equipo de seguridad, un error es un error. No hay nada especial en las correcciones de seguridad. Y si calificamos las correcciones de seguridad como especiales, eso implica que otras correcciones no son especiales". ".
Eso es un error porque, según Kroah-Hartman, "cualquier error tiene el potencial de ser un problema de seguridad a nivel del núcleo". Una pequeña corrección de errores que había realizado hace años en TTY, un subsistema menor en Linux hoy, resultó tener un agujero de seguridad mortal. Permitió que cualquiera pudiera obtener root en los sistemas RHEL. Nunca se sabe dónde o cuándo surgirá un problema de seguridad.
Kroah-Hartman también observó que si bien el "kernel de Linux tiene alrededor de 30 millones de líneas de código, sólo usas alrededor de dos millones de líneas en tu servidor, 4 millones en tu teléfono y un millón y medio en tu televisor. Pero nosotros no No sabemos lo que estás usando. Linux está en todas partes, en tus autos, en los satélites y en las máquinas de ordeñar vacas. No sabemos tu caso de uso. No sé cuál es el modelo de seguridad". Por tanto, todo y cualquier cosa debe considerarse esencial.
Entonces, ¿qué puedes hacer al respecto para protegerte? Kroah-Hatman enfatizó que siempre se debe usar el último kernel estable a largo plazo (LTS).
Desafortunadamente, muy pocas distribuciones de Linux hacen eso. Criticó a las empresas que no actualizan sus núcleos con regularidad. Los sistemas obsoletos, desde su punto de vista, son inherentemente inseguros.
Esta no es sólo su opinión. Después de años de estudio, Kroah-Hartman citó al equipo de seguridad de Google Android, que descubrió que los kernels estables de Linux habían solucionado todos los problemas de seguridad recientes conocidos antes de que fueran reportados. Tienen pruebas documentadas de que adoptar núcleos estables siempre funciona y que sus sistemas estarán seguros. Como ingeniero del kernel de Linux de Google, Kees Cook dijo: "Entonces, ¿qué debe hacer un proveedor? La respuesta es simple, aunque dolorosa: actualizar continuamente a la última versión del kernel, ya sea principal o estable".