LinuxParty

Jeremy Allison: Sam es un ingeniero distinguido en CIQ, creador de Rocky Linux. Publicó una entrada de blog respondiendo a las promesas de las distribuciones de Linux "seleccionando cuidadosamente sólo los parches de código abierto más pulidos y prístinos del kernel de Linux de código abierto sin procesar para crear el kernel de distribución seguro del que depende en su negocio".

Pero , ¿ los parches de software cuidadosamente seleccionados (aplicados a un conocido kernel de Linux "congelado") realmente aportan mayor seguridad? "Después de mucho trabajo duro y análisis de datos por parte de mis colegas de ingeniería del kernel de CIQ, Ronnie Sahlberg y Jonathan Maple, finalmente tenemos una respuesta a esta pregunta. Es no".Los datos muestran que los kernels de Linux de proveedores "congelados", creados mediante la bifurcación de un punto de lanzamiento y luego utilizando un equipo de ingenieros para seleccionar parches específicos para retroportar a esa rama, tienen más errores que el kernel de Linux "estable" ascendente creado por Greg. Kroah-Hartman. ¿Cómo puede ser esto? Si desea conocer todos los detalles, el enlace al documento técnico está aquí. Pero los resultados del análisis no podrían ser más claros.

- Un kernel de proveedor "congelado" es un kernel inseguro. Un kernel de proveedor lanzado más adelante en el calendario de lanzamiento lo es doblemente.
- El número de errores conocidos en un kernel de proveedor "congelado" crece con el tiempo. El crecimiento del número de errores incluso se acelera con el tiempo.
- Hay demasiados errores abiertos en estos núcleos como para que sea factible analizarlos o incluso clasificarlos...

Pensar que estás tomando una decisión más segura al utilizar un núcleo de proveedor "congelado" no es una lujo que todavía podemos permitirnos creer. Como dijo explícitamente Greg Kroah-Hartman en su charla "Desmitificando el proceso de seguridad del kernel de Linux": "Si no estás utilizando el último kernel estable/a largo plazo, tu sistema es inseguro".

CIQ describe su informe como "un recuento de todos los errores conocidos de un kernel anterior que se introdujeron, pero que nunca se solucionaron en RHEL 8".Para los kernels RHEL 8 más recientes, al momento de escribir este artículo, estos recuentos son: RHEL 8.6: 5034 RHEL 8.7: 4767 RHEL 8.8: 4594 En RHEL 8.8 tenemos un total de 4594 errores conocidos con correcciones que existen en el sentido anterior, pero para los cuales Las correcciones conocidas no se han adaptado a RHEL 8.8. La situación es peor para RHEL 8.6 y RHEL 8.7, ya que cortaron la portabilidad anterior a RHEL 8.8 pero, por supuesto, eso no impidió que se descubrieran y corrigieran nuevos errores en el sentido anterior....

Este documento técnico no pretende ser una crítica al ingenieros que trabajan en cualquier proveedor de Linux y que se dedican a producir un trabajo de alta calidad en sus productos en nombre de sus clientes. Este problema es extremadamente difícil de resolver. Sabemos que esto es un secreto a voces entre muchos en la industria y nos gustaría incluir cifras concretas que describan el problema para fomentar el debate. Nuestra esperanza es que los proveedores de Linux y la comunidad en su conjunto se unan detrás de los kernels estables de kernel.org como la mejor solución compatible a largo plazo. Como ingenieros, preferiríamos que esto nos permitiera dedicar más tiempo a corregir errores específicos de los clientes y enviar mejoras de funciones en sentido ascendente, en lugar de la interminable rutina de respaldar los cambios en los núcleos de los proveedores, una práctica que puede introducir más errores de los que corrige.

ZDNet lo llama "un secreto a voces en la comunidad Linux".No basta con utilizar una versión de soporte a largo plazo. Debe utilizar la versión más actualizada para estar lo más seguro posible. Lamentablemente casi nadie hace eso. Sin embargo, como explicó el ingeniero del kernel de Linux de Google, Kees Cook, "Entonces, ¿qué debe hacer un proveedor? La respuesta es simple: si es dolorosa: actualizar continuamente a la última versión del kernel, ya sea principal o estable". ¿Por qué? Como explicó Kroah-Hartman, "Cualquier error tiene el potencial de ser un problema de seguridad a nivel del kernel..."

Aunque los programadores [de CIQ] examinaron RHEL 8.8 específicamente, este es un problema general. Habrían encontrado los mismos resultados si hubieran examinado SUSE, Ubuntu o Debian Linux. Las distribuciones de Linux de lanzamiento continuo, como Arch, Gentoo y OpenSUSE Tumbleweed, lanzan constantemente las últimas actualizaciones, pero no se utilizan en las empresas.

La publicación de Jeremy Allison señala que "el kernel de Linux utilizado por los dispositivos Android se basa en el kernel ascendente y también tiene una ABI de kernel interna estable, por lo que este no es un problema insuperable..."

Whatsapp