¿Qué pasó con la promesa de parchear en vivo los núcleos de Linux? Este artículo analiza su historia, sus problemas y las formas más baratas y sencillas de hacerlo en Ubuntu Focal Fossa (20.04 LTS).
Introducción
El ‘Live patching’ es el acto de actualizar un programa sin detener el sistema en el que se está ejecutando. Primero se hizo con soldadura y alambre, más tarde, con tijeras y pegamento: no es nada nuevo. Hoy en día, parchear en vivo los núcleos de Linux es mucho menos pegajoso.
En este artículo, explicaré qué es, cómo funciona (en términos no técnicos) y de dónde viene. Terminaré mostrando cómo automatizar las actualizaciones de seguridad del núcleo en Ubuntu 20.04 LTS (Focal Fossa) con Servicio Livepatch de Canonical y KernelCare.
¿Qué es el Live Patching?
En el ámbito del software, un parche es un pequeño fragmento de código rectificador. Parchear es reparar o mejorar una pequeña parte de un programa sin interrumpir el funcionamiento o las especificaciones del conjunto. Parchear en vivo (o en caliente) significa cambiar un programa en ejecución sin detenerlo.
Imagina que estás atrapado en un coche en marcha y tienes que arreglar una bombilla. No está tan mal, dirás, si está en el interior, un poco más complicado en el exterior. Ahora imagina que reparas un árbol de levas, sustituyes un vástago de pistón o sellas un bloque agrietado.
Esto es parecido a lo que el live patching intenta hacer en el núcleo de Linux. Se trata de reparar las piezas de algo en movimiento, sin cambiarlo ni romperlo, pero sobre todo, sin detenerlo. El núcleo es la única parte de un sistema Linux que necesita un apagado y un reinicio para aplicar una actualización. Cuando un proveedor lanza una actualización del kernel, los administradores de sistemas no tienen más remedio que programar un reinicio de un servidor.
¿Qué tiene de malo reiniciar?
Un reinicio significa cosas diferentes para distintas personas, según estén en el sistema o a cargo de él. Muchos administradores de sistemas consideran que los reinicios regulares son un signo de buena salud, como la defecación regular. Otros tantos no lo hacen, ya que se resisten a cualquier interrupción de las aplicaciones en las que han invertido y con las que ganan dinero, aplicaciones como las siguientes, por ejemplo
- servidores web, con usuarios ocupados y activos en muchas zonas horarias
- juegos multijugador en línea
- transmisión de vídeo en directo o grabado de pago por visión
- minería de criptomonedas
- servicios de videovigilancia y grabación a distancia, 24 horas al día, 7 días a la semana
Para mí, la razón más comprensible es el miedo a que el sistema no sea el mismo después, y que las aplicaciones críticas (que generan dinero) no se pongan en marcha. Creo que es esto, y no las visiones de usuarios desbocados, lo que hace que muchos administradores de sistemas pospongan las actualizaciones del núcleo, incluso las más importantes, las de seguridad.
(Aquí sólo hablo de actualizaciones. Núcleo actualizaciones son otra cosa. Las actualizaciones son núcleos completamente nuevos. Los parches son actualizaciones de partes del kernel, normalmente correcciones de errores que no pueden esperar porque tienen implicaciones de seguridad u otras de gran alcance).
Cuando un proveedor de Linux publica un parche para el núcleo, suele ser para solucionar un problema de seguridad. La nota de aviso asociada dirá algo así como: «Instálalo lo antes posible», y en la misma página habrá una versión de: «Si no lo haces, serás vulnerable a los exploits que hemos parcheado y que ahora todo el mundo conoce. Que tengas un buen día».
Estas notas escritas de forma tan insensible ponen de manifiesto el dilema que impulsa la llegada de los parches en vivo: ¿debes mantener a los usuarios «doloridos pero seguros», o «compuestos pero expuestos»? El parcheo en vivo promete ser la isla paradisíaca entre la roca y el lugar duro. El parcheo en vivo promete ayudar a mantener tus servidores seguros y con los últimos niveles de seguridad, sin afectar al tiempo de inactividad, y sin afectar a los servicios.
¿Isla del Paraíso? ¿Cuál es el truco?
Aunque el código fuente del software de live patching es de libre acceso, los parches no lo son. La dulce promesa de la aplicación de parches en vivo se agria cuando tienes que escribir tus propios parches. Tu presión sanguínea se alivia con menos administración, pero vuelve a subir al manejar código complejo del núcleo.
Aunque es técnicamente posible hacer tus propios parches, requiere mucho trabajo y muchos conocimientos especializados. Y es arriesgado: un parche mal escrito puede colapsar un sistema. (Este mensaje en la página de página de github de kpatch parece sacado del manual de un martillo de vapor: «ADVERTENCIA: ¡Utilícelo con precaución! Pueden producirse fallos del kernel, reinicios espontáneos y pérdida de datos»)
Los proveedores de Linux saben lo difícil que es hacer parches en vivo correctamente, y han desarrollado ofertas de servicios rentables para aprovechar este hecho. Cada una de las principales distribuciones de Linux tiene un enfoque de parcheo en vivo que es gratuito de instalar, pero no de usar. Los parches, sin los cuales toda la idea es inútil, deben pagarse.
Aun así, los beneficios de los parches en vivo del núcleo son tan convincentes que estos modelos de negocio prosperan en el ecosistema de software predominantemente libre y de código abierto de Linux. Para mí, esto es una señal de que la tecnología tiene un significado y un papel importante en el futuro de los sistemas basados en Linux.
Cómo funciona el Live Patching
Si sigues atrapado en ese coche imaginario, que ahora va cuesta abajo hacia una pila imaginaria de cajas de cartón (con suerte) vacías, ¿cómo arreglarías los frenos? ¿Construir un gato rodante temporal sobre el que hacer el trabajo? ¿Inclinarte sobre tres ruedas, esperar a que una se detenga, quitártela, repetirlo hasta terminar?
Los programadores del núcleo de Linux deben haber utilizado el mismo tipo de pensamiento al abordar el problema de los parches en vivo. Percibo el mismo tipo de aparato conceptual (suspensión, intercambio, uso de estructuras de soporte temporales) en sus soluciones. Mi burda analogía del cambio de frenos anterior ilustra dos estrategias opuestas aplicadas por los proveedores de software de parcheo en vivo.
- Parar todo y hacer todas las correcciones de una sola vez.
- Esperar a que los componentes individuales se detengan, y luego cambiarlos. Repetir hasta que se acabe.
Esta división explica por qué cada proveedor ha ideado enfoques diferentes para resolver el mismo problema. Lo que sí comparten, sin embargo, es el uso del módulo del kernel módulo del núcleo cargable de Linux. El software que orquesta e implementa el proceso de parcheo es un módulo del núcleo de Linux. Eso significa que es fácil añadir la funcionalidad de parcheo a los núcleos compatibles, e igualmente fácil eliminarla.
Antes de dejarnos llevar, debo mencionar las advertencias.
Hay un límite en el alcance y la escala de los parches de software que puedes aplicar a los sistemas en funcionamiento. Por un lado, los núcleos personalizados, optimizados o no estándar hacen que sea difícil o imposible parchear en vivo un núcleo. Por otro, el parcheo en vivo no puede reasignar datos o memoria entre parches; sólo puede alterar las definiciones de las funciones.
Estas deficiencias no impidieron que Ksplice se convirtiera en el primero en el campo del parcheo en vivo de Linux. Funciona comparando el código fuente antiguo y el nuevo, a partir del cual crea un parche binario. Congela el sistema, averigua qué funciones hay que cambiar y edita sus cabeceras. Cuando se llaman, las funciones se desvían a las nuevas versiones. Si el parche está bien escrito, el control procede como si no hubiera pasado nada.
Un acontecimiento sísmico (descrito en la siguiente sección) hizo que el Kpatch de Red Hat y el Kgraft de SUSE se unieron a la escena con sus propias interpretaciones sobre los problemas centrales del parcheo en vivo.
Kpatch compara el código fuente antiguo y el nuevo para hacer parches. Al igual que Ksplice, funciona redirigiendo las llamadas a funciones utilizando el kernel ftrace para cambiar las funciones modificadas de una sola vez.
Kgraft funciona de forma diferente. Utiliza dos conjuntos concurrentes de funciones, las antiguas y las nuevas, con un módulo orquestador que decide cuándo redirigir las funciones en función de dónde haya llegado la ejecución. Es imposible predecir en qué punto de una función se encuentra un puntero de programa en un momento dado, por lo que la transición es gradual, no instantánea.
Los orígenes del Live Patching
¿Cómo llegó la idea de arreglar el software sin que nadie se diera cuenta a ese monolito siempre cambiante del esfuerzo humano que es el núcleo de Linux?
Aunque el concepto se remonta a los primeros días de la computación programable, para nuestros fines el rastro comienza en 2001, cuando Hewlett Packard patentó una forma de actualizar dinámicamente el software para compensar la falta de funcionalidad del hardware. Un año después, Microsoft presenta una idea para actualizar un sistema (Windows) sin interrupción.
Ninguno de los dos menciona a Linux, pero las aplicaciones son amplias, y cada una describe cómo remediar problemas de software o hardware en un ordenador sin interrumpir los procesos que se ejecutan en él. (Si la idea no te parece especialmente útil, quizá dos palabras te hagan recapacitar: Meltdown y Spectre.)
En 2008, Jeff Arnold anuncia Kspliceun software para parchear los núcleos de Linux sin reiniciarlos. Es el primero de este tipo para Linux. Y hay que agradecérselo a un hacker desconocido y sin nombre.
Para ver por qué, déjame que te lleve a los días de estudiante de Jeff en el MIT. Es miembro de un grupo de voluntarios que administra servidores para la comunidad estudiantil. Uno de los servidores necesita un parche de seguridad. No quiere echar a sus usuarios, así que lo deja pasar unos días.
En esos pocos días, antes de que pueda actualizarlo, alguien hackea el sistema. La única forma de volver a ponerlo en línea es reinstalarlo completamente desde cero. Supongamos que sus compañeros se dan cuenta. Incluso suponiendo que no sufran, me imagino a Jeff pasando el resto del semestre asándose lentamente sobre las cenizas de la burla de los estudiantes.
Si la historia es apócrifa, considérala una fábula, un recordatorio de que el parcheo en vivo es hijo de la seguridad, no de la conveniencia. Y como toda buena fábula, tiene un final feliz.
El incidente inspira a Jeff a estudiar cómo instalar los parches del núcleo de Linux sin demora y sin interrupción. Hace de este problema el tema de su tesis de máster de 2006. La solución viene en forma de un software llamado Ksplice. Con un colega, escribe un artículo que lo describe, titulado «Ksplice: Actualizaciones automáticas del núcleo sin reinicio».
Jeff y tres de sus colegas estudiantes forman una empresa y, en mayo de 2009, ganan el premio del Concurso de Emprendedores del MIT de 100.000 dólares. Lanzan un servicio comercial en 2010. Otro año después, en el tipo de cierre kármico con el que sueña todo desarrollador de software, Oracle compra Ksplice Inc.
El karma está muy lejos de la mente de los usuarios y clientes de esta nueva utilidad asombrosamente útil. Para ellos, es el comienzo de una larga y agotadora cadena de pesadillas. Oracle asimila Ksplice por completo, haciendo que la herramienta sea gratuita sólo para los clientes de sus propias versiones de Linux, financiadas por el soporte.
Esta sacudida sísmica empuja a SUSE y a Red Hat a desarrollar sus propias soluciones, sin que ninguno de los dos le diga al otro sus intenciones o arquitecturas de solución. Trabajan de forma aislada de 2011 a 2014, lanzando sus propios enfoques distintos con semanas de diferencia. Y en mayo de 2014 CloudLinuxproductores de una variante de Linux muy conocida en el ámbito del alojamiento web, lanza un servicio comercial de parcheo en vivo del núcleo de Linux con el nombre de KernelCare.
Al mismo tiempo, un parcheo en vivo ABI se abre paso en la línea principal del núcleo, viendo la luz en la versión 4.0 con el nombre de Livepatch. En octubre de 2016, Canonical, los creadores de Ubuntu, lo utilizan como base para un servicio comercial bajo el nombre descaradamente apropiado de «Canonical Livepatch Service». Canonical lo lanzó primero para la versión 16.04 LTS, y luego para la 14.04 LTS, y en ambos casos requería una configuración en la línea de comandos. En la 18.04 LTS, se ha hecho más visible, más fácil de usar y mejor integrado en la experiencia del escritorio de Ubuntu, y ahora está disponible para la 20.04 LTS.
Cómo hacerlo: Actualizaciones de seguridad del kernel automatizadas en Ubuntu 20.04 LTS
Ahora es el momento de verlo en acción. Hay dos soluciones de parcheo en vivo para Ubuntu, que se tratan en las dos siguientes secciones.
Instalación del Servicio Canonical Livepatch (CLS)
CLS es gratuito para personas no comerciales, para un máximo de tres máquinas. Requiere registro, pero puedes utilizar una cuenta de Ubuntu One si tienes una. Si quieres instalarlo en más de tres máquinas, tendrás que comprar un contrato de servicio de soporte de tipo empresarial.
Antes de empezar
- Asegúrate de que tu sistema está actualizado y tiene una copia de seguridad.
- Inscríbete en un Livepatch o Ubuntu One de Ubuntu.
- Para el servidor 20.04 LTS, obtén una clave y anótala. (Esto no es necesario en la edición Desktop).
Instalar Livepatch en Ubuntu 20.04 LTS Desktop
Ubuntu 20.04 LTS Desktop tiene una configuración de la GUI para activar el CLS. Puedes hacerlo durante la configuración posterior a la instalación, o más tarde, abriendo el Software y Actualizaciones y yendo a la pestaña Livepatch.
En una instalación nueva de Ubuntu
Tras el primer reinicio de una instalación nueva, fíjate en la segunda pantalla del cuadro de diálogo «Novedades de Ubuntu». Esto te permite configurar el Livepatch.
- Haz clic en «Configurar Livepatch…».
- En la pantalla «Cuenta de inicio de sesión único de Ubuntu», inicia sesión con tu cuenta de Livepatch o de Ubuntu One.
- Si utilizas la interfaz gráfica de instalación basada en texto, en «Snaps de servidor destacados», selecciona canonical-livepatch.
En una instalación de Ubuntu existente
- Abre «Software y actualizaciones» y ve a la pestaña «Livepatch».
- Inicia sesión.
- Una vez iniciada la sesión, haz clic en Continuar cuando aparezca la ventana emergente confirmando que has iniciado la sesión.
- Ya está. El livepatch está instalado en tu escritorio de Ubuntu 20.04.
Errores en Ubuntu 20.04 con Livepatch
Es posible que te encuentres con el siguiente error al activar el Livepatch en Ubuntu 20.04 Focal Fossa:
Failed to enable Livepatch: cannot enable machine: this machine ID is already enabled with a different key or is non-unique. Either "sudo canonical-livepatch disable" on the other machine, or regenerate a unique /etc/machine-id on this machine with "sudo rm /etc/machine-id /var/lib/dbus/machine-id && sudo systemd-machine-id-setup" server response: Conflicting machine-id
Para solucionar el error, escribe los siguientes comandos en el terminal:
cp /etc/machine-id /etc/machine-id.original
cp /var/lib/dbus/machine-id /var/lib/dbus/machine-id.original
nano /etc/machine-id (to remove the existing value)
systemd-machine-id-setup
> Initializing machine ID from D-Bus machine ID.
cat /etc/machine-id
Instalación de Livepatch en Ubuntu 20.04 LTS Server
Este es el método de línea de comandos para las versiones estándar del servidor sin un sistema de ventanas instalado. También funciona en las versiones 16.04 LTS, 14.04 LTS y 18.04 LTS.
Abre un terminal e introduce estos dos comandos:
sudo snap install canonical-livepatch
sudo canonical-livepatch enable <your key>
Consejos
- El segundo comando devuelve un token de máquina. No sirve para nada y no es necesario registrarlo.
- Lleva la cuenta de las máquinas que registras. Si pierdes el rastro o te deshaces de una máquina o VM antes de darla de baja, estarás tirando una de tus tres licencias gratuitas. (Hay ayuda aquí.)
- Para dar de baja un servidor, utiliza este comando:
sudo canonical-livepatch disable <your key>
- Para comprobar el estado del servicio, utiliza este comando:
sudo canonical-livepatch status --verbose
Instalación de KernelCare
KernelCare utiliza una configuración de línea de comandos; no hay interfaz gráfica de usuario. Es compatible con una amplia gama de sistemas operativos, como CentOS, RHEL, Oracle Linux, Debian, Ubuntu y otros. También es compatible con la antigua línea de kernel 2.6.32.
A diferencia de CLS, está totalmente automatizado y comprobará si hay lanzamientos de parches cada cuatro horas, instalándolos sin supervisión si hay alguno disponible. Si necesitas anular esa capacidad o vincular los servidores a parches de fecha fija, existe una utilidad de línea de comandos (kcarectl) que te permite hacer esto y otras cosas.
KernelCare es gratuito para las organizaciones sin ánimo de lucro, o hay una prueba gratuita de 30 días para el resto de nosotros. (Si eres usuario de Ksplice, quizá quieras probar el script de migración de Ksplice a KernelCare en dos pasos de dos pasos.)
Antes de empezar
- Asegúrate de que tu sistema está actualizado y tiene una copia de seguridad.
- Consigue una clave de prueba gratuita en aquí.
Instalación de KernelCare en Ubuntu 20.04 LTS Desktop y Server
Abre un terminal e introduce estos dos comandos:
sudo wget -qq -O - https://repo.cloudlinux.com/kernelcare/kernelcare_install.sh | bash
sudo /usr/bin/kcarectl --register KEY
Estos comandos también funcionan en las versiones 16.04 LTS, 14.04 LTS y 18.04 LTS.
Consejos
- Para dar de baja un servidor, utiliza este comando:
sudo kcarectl --unregister
- Para comprobar el estado del servicio, utiliza este comando:
sudo kcarectl --info
Conclusión
La aplicación de parches en vivo en Linux era demasiado útil para seguir siendo gratuita durante mucho tiempo.
Con la versión 20.04 LTS de Ubuntu, es más fácil disfrutar de las ventajas del parcheado de seguridad en vivo de los núcleos de Linux, y es gratuito hasta para tres hosts. Después, las cuotas anuales por servidor por servidor por servidor.
Si ejecutas muchos sabores de Linux, pero no quieres aprender diferentes productos o suscribirte a diferentes contratos de soporte, echa un vistazo a KernelCare. Es unas cinco veces más más barato si te suscribes anualmente, y ofrecen suscripciones mensuales flexibles.