Descontento sobre la gestión de seguridad de los núcleos Linux

En los últimos meses se han descubierto diversas vulnerabilidades en los núcleos Linux que, gracias a ser un sistema Open Source, han sido solucionadas, en la mayor parte de los casos, en cuestión de horas. Es decir, que los administradores preocupados han podido encontrar parches solucionando las vulnerabilidades en un corto espacio de tiempo.

No obstante, en algunos casos, esas correcciones no han estado disponibles en actualizaciones “oficiales” de los kernel hasta meses después. Esto es así porque la tendencia hasta ahora ha sido el integrar esos parches en la versión en desarrollo de los kernel, cuya fecha de publicación puede estar a semanas o meses vista.

Muchos miembros de la comunidad, incluyendo Hispasec, reclamamos que:

1. Los problemas de seguridad del kernel Linux deben ser solucionados en el menor plazo posible, una vez descubiertos. Tanto si se trata de vulnerabilidades accesibles desde el exterior como si requieren acceso local, ya que se utilizan muchos sistemas Linux para dar servicio usuarios no confiables.

2. Las actualizaciones de seguridad deben aplicarse tanto a los kernel en desarrollo en este momento, como a los kernel en producción.

3. Se debe publicar una actualización de los kernel en producción, solucionando exclusivamente las vulnerabilidades descritas, en el menor plazo posible.

Es decir, si se descubre un problema de seguridad en la versión 2.4.28 del núcleo Linux, no debe ser necesario esperar a la versión 2.4.29 del mismo para solucionar el problema, que puede suponer semanas o meses. Antes bien, debe publicarse una versión 2.4.28.1 del kernel, solucionando exclusivamente el problema en cuestión, sin tener que esperar un nuevo ciclo de desarrollo completo del núcleo.

El propio Linus Torvalds aboga porque los problemas de seguridad de los kernel se discutan de forma pública, para reducir al mínimo los retrasos y las “excusas” a la hora de publicar una actualización. En ese sentido, Linus es un defensor a ultranza del “Full Disclosure” de vulnerabilidades.

Solo queda esperar ver cómo evolucionan los acontecimientos, a la luz de futuras vulnerabilidades.