Parches en vivo del kernel de Linux en Ubuntu 20.04 LTS

¿Qué pasó con la promesa de parchear en vivo los kernels de Linux? Este artículo analiza su historia, sus problemas y las formas más baratas y fáciles de hacerlo en Ubuntu Focal Fossa (20.04 LTS).

Introducción

El ‘parcheo en vivo’ es el acto de actualizar un programa sin detener el sistema en el que se está ejecutando. Primero se hizo con soldadura y alambre, luego con tijeras y pegamento, no es nada nuevo. Hoy en día, la aplicación de parches en vivo a los kernels de Linux es mucho menos complicada.

En este artículo, explicaré qué es, cómo funciona (en términos no técnicos) y de dónde proviene. Terminaré mostrando cómo automatizar las actualizaciones de seguridad del kernel en Ubuntu 20.04 LTS (Focal Fossa) con Servicio Canónico Livepatch y KernelCare.

¿Qué es Live Patching?

En el software, un parche es una pequeña pieza de código de rectificación. Parchear es reparar o mejorar una pequeña parte de un programa sin interrumpir el funcionamiento o las especificaciones del todo. La aplicación de parches en vivo (o en caliente) significa cambiar un programa en ejecución sin detenerlo.

Imagina que estás atrapado en un automóvil en movimiento y necesitas arreglar una bombilla. No está mal, se podría decir, si está en el interior, un poco más complicado en el exterior. Ahora imagine reparar un árbol de levas, reemplazar una varilla de pistón o sellar un bloque agrietado.

Esto es similar a lo que los parches en vivo intentan hacer en el kernel de Linux. Es tratar de reparar las partes de algo en movimiento, sin cambiarlo o romperlo, pero lo más importante, sin detenerlo. El kernel es la única parte de un sistema Linux que necesita apagarse y reiniciarse para aplicar una actualización. Cuando un proveedor lanza una actualización del kernel, los administradores del sistema no tienen más remedio que programar un reinicio de un servidor.

¿Qué tiene de malo reiniciar?

Un reinicio significa diferentes cosas para diferentes personas, dependiendo de si están en el sistema o están a cargo de él. Muchos administradores de sistemas consideran que los reinicios regulares son un signo de buena salud, como los intestinos regulares. Al igual que muchos no lo hacen, resistiendo cualquier interrupción de las aplicaciones en las que están invirtiendo y ganando dinero, aplicaciones como estas, por ejemplo.

• servidores web, con usuarios ocupados y activos en muchas zonas horarias
• juegos multijugador en línea
• transmisión de video en vivo o grabado de pago por evento
• minería de criptomonedas
• servicios remotos de videovigilancia y grabación las 24 horas del día, los 7 días de la semana

Para mí, la razón más identificable es el temor de que el sistema no sea el mismo después, y que las aplicaciones críticas (que generan dinero) no se inicien. Creo que es esto, y no las visiones de usuarios alborotados, lo que hace que muchos administradores de sistemas pospongan las actualizaciones del kernel, incluso las más importantes, las actualizaciones de seguridad.

(Aquí, solo estoy hablando de actualizaciones. Núcleo actualizaciones son otra cosa Las actualizaciones son núcleos completamente nuevos. Los parches son actualizaciones de partes del núcleo, generalmente correcciones de errores que no pueden esperar porque tienen implicaciones de seguridad u otras de gran alcance).

Cuando un proveedor de Linux lanza un parche del kernel, generalmente es para solucionar un problema de seguridad. La nota de aviso asociada dirá algo como: ‘Instalar lo antes posible’. En la misma página habrá una versión de ‘Si no lo hace, será vulnerable a los exploits que hemos parcheado y que ahora todos conocen. Que tengas un lindo día.’

Tales notas escritas cruelmente resaltan el dilema que impulsa el advenimiento de los parches en vivo: ¿debería mantener a los usuarios ‘doloridos pero seguros’ o ‘compuestos pero expuestos’? El parcheo en vivo promete ser la Isla Paraíso entre Rock y Hard Place. La aplicación de parches en vivo promete ayudar a mantener sus servidores seguros y con los niveles de seguridad más recientes, sin afectar el tiempo de inactividad y sin afectar los servicios.

¿Isla del Paraiso? ¿Cuál es el truco?

Si bien el código fuente para el software de parches en vivo está disponible gratuitamente, los parches no lo están. La dulce promesa de parchear en vivo se agria cuando tienes que escribir tus propios parches. Su presión arterial se alivia con menos administración, pero vuelve a subir al manejar código kernel complejo.

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 el página de github kpatch se lee como algo del manual del operador de un martillo de vapor: ‘ADVERTENCIA: ¡Usar con precaución! ¡Pueden ocurrir fallas en el kernel, reinicios espontáneos y pérdida de datos!’)

Los proveedores de Linux saben lo difícil que es aplicar parches en vivo correctamente y han desarrollado ofertas de servicios rentables para aprovechar este hecho. Cada distribución principal de Linux tiene un enfoque de parches en vivo que es gratuito para instalar, pero no para usar. Los parches, sin los cuales toda la idea es inútil, hay que pagarlos.

Aún así, los beneficios de la aplicación de parches en vivo al kernel son tan atractivos que estos modelos comerciales prosperan en el ecosistema de software predominantemente gratuito y de código abierto de Linux. Para mí, esta es una señal de que la tecnología tiene importancia y un papel importante en el futuro de los sistemas basados ​​en Linux.

Cómo funciona la aplicación de parches en vivo

Todavía atrapado en ese auto imaginario, ahora tronando cuesta abajo hacia una pila imaginaria de (con suerte) cajas de cartón vacías, ¿cómo arreglarías los frenos? ¿Construir un gato rodante temporal sobre el cual hacer el trabajo? ¿Inclinarse sobre tres ruedas, esperar a que una se detenga, quitarla, repetir hasta terminar?

Los programadores del kernel de Linux deben haber usado el mismo tipo de pensamiento al abordar el problema de los parches en vivo. Siento el mismo tipo de aparato conceptual (suspensión, intercambio, el uso de estructuras temporales de soporte) trabajando en sus soluciones. Mi cruda analogía del cambio de frenos anterior ilustra dos estrategias opuestas implementadas por proveedores de software de parcheo en vivo.

• Detenga todo y haga todas las correcciones de una sola vez.
• Espere a que los componentes individuales se detengan y luego cámbielos. Repita hasta que esté listo.

Esta división explica por qué cada proveedor ha ideado diferentes enfoques para resolver el mismo problema. Lo que sí comparten, sin embargo, es el uso de Linux módulo de kernel cargable estructura. El software que organiza e implementa el proceso de aplicación de parches es un módulo del kernel de Linux. Eso significa que es fácil agregar la funcionalidad de parches a los kernels compatibles, y es igual de fácil eliminarlos.

Antes de dejarnos llevar, debo mencionar las advertencias.

Existe un límite para el alcance y la escala de los parches de software que puede aplicar a los sistemas en ejecución. Por un lado, los núcleos personalizados, optimizados o no estándar hacen que sea difícil o imposible aplicar parches en vivo a un núcleo. Por otro lado, los parches en vivo no pueden reasignar datos o memoria entre parches; solo puede alterar las definiciones de funciones.

Estas deficiencias no se detuvieron empalme de convertirse en el primero en el campo de parches 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, determina qué funciones deben cambiarse y edita sus encabezados. Cuando se llama, las funciones se desvían a las nuevas versiones. Si el parche está bien escrito, el control procede como si nada hubiera pasado.

Un evento sísmico (descrito en la siguiente sección) hizo que Red Hat parche y SUSE injerto unirse a la escena con sus propias interpretaciones sobre los problemas centrales de los parches en vivo.

Kpatch compara el código fuente antiguo y el nuevo para crear parches. Al igual que Ksplice, funciona redirigiendo las llamadas a funciones usando el kernel seguimiento framework para cambiar las funciones cambiadas de una sola vez.

Kgraft funciona de manera diferente. Utiliza dos conjuntos simultáneos de funciones, antiguo y nuevo, con un módulo orquestador que decide cuándo redirigir las funciones dependiendo de dónde haya llegado la ejecución. Es imposible predecir en qué parte 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 de la aplicación de parches en vivo

¿Cómo llegó la idea de arreglar el software sin que nadie lo notara a ese monolito en constante cambio del esfuerzo humano, el kernel de Linux?

Aunque el concepto se remonta a los primeros días de la computación programable, para nuestros propósitos el camino comienza en 2001 cuando Hewlett Packard patenta 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 menciona Linux, pero las aplicaciones son amplias y cada una describe cómo solucionar problemas de software o hardware en una computadora sin interrumpir los procesos que se ejecutan en ella. (Si la idea no te parece especialmente útil, quizás dos palabras te hagan pensar de nuevo: Fusión de un reactor y Espectro.)

En 2008, Jeff Arnold anuncia Ksplice, software para parchear kernels de Linux sin reiniciarlos. Es el primero de su tipo para Linux. Y tenemos que agradecerle a un hacker desconocido y sin nombre.

Para ver por qué, déjame llevarte a los días de estudiante del MIT de Jeff. 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 expulsar a sus usuarios, así que lo deja pasar unos días.

En esos pocos días, antes de que pueda actualizarlo, alguien piratea el sistema. La única forma de volver a ponerlo en línea es reinstalarlo completamente desde cero. Supongamos que sus colegas se dan cuenta. Incluso suponiendo que no sufran, me imagino a Jeff pasando el resto del semestre asándose lentamente sobre las cenizas de las burlas de los estudiantes.

Si la historia es apócrifa, entonces considérela una fábula, un recordatorio de que el parcheo en vivo es hijo de la seguridad, no de la conveniencia. Y como todas las buenas fábulas, hay un final feliz.

El incidente inspira a Jeff a estudiar cómo instalar los parches del kernel de Linux sin demora ni interrupción. Hace de este problema el tema de su tesis de maestría de 2006. La solución viene en forma de software llamado Ksplice. Con un colega, escribe un papel describiéndolo, titulado ‘Ksplice: Actualizaciones automáticas del kernel sin reinicio’.

Jeff y tres de sus colegas estudiantes forman una empresa y, en mayo de 2009, ganan el premio MIT $100K Entrepreneurship Competition. 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.

Karma está lejos de la mente de los usuarios y clientes de esta nueva utilidad increíblemente útil. Para ellos, es el comienzo de una larga y agotadora serie de pesadillas. Oracle asimila Ksplice por completo, lo que hace que la herramienta sea gratuita solo para los clientes de sus propias versiones de Linux financiadas con tarifas de soporte.

Este impacto sísmico impulsa a SUSE y Red Hat a desarrollar sus propias soluciones, sin decirle a la otra parte sus intenciones o arquitecturas de solución. Trabajan de forma aislada desde 2011 hasta 2014, lanzando sus propios enfoques distintos con semanas de diferencia. Y en mayo de 2014, NubeLinuxproductores de una variante de Linux muy conocida en las esferas de alojamiento web, lanza un servicio comercial de parches en vivo del kernel de Linux bajo el nombre de KernelCare.

Al mismo tiempo, un parche en vivo ITB se está abriendo camino en la línea principal del núcleo, viendo la luz del día en la versión 4.0 bajo el nombre de parche en vivo. En octubre de 2016, Canonical, los creadores de Ubuntu, lo utilizan como base para el servicio comercial bajo el nombre descaradamente apropiado de ‘Canonical Livepatch Service’. Canonical lo lanza primero para 16.04 LTS, luego para 14.04 LTS, ambos requieren configuración en la línea de comando. En 18.04 LTS, se ha vuelto más visible, más fácil de usar y mejor integrado en la experiencia de escritorio de Ubuntu y ahora está disponible para 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 parches en vivo para Ubuntu, cubiertas en las siguientes dos secciones.

Instalación del servicio Canonical Livepatch (CLS)

CLS es gratuito para personas no comerciales, para hasta tres máquinas. Requiere registro, pero puede usar una cuenta de Ubuntu One si tiene una. Si desea instalarlo en más de tres máquinas, deberá comprar un acuerdo de servicio de soporte de estilo empresarial.

Antes de que empieces

• Asegúrese de que su sistema esté actualizado y respaldado.
• Regístrese para un parche en vivo o Ubuntu Uno cuenta.
• Para el servidor 20.04 LTS, conseguir una llave y tome nota de ello. (Esto no es necesario en la edición de escritorio).

Instalación de Livepatch en Ubuntu 20.04 LTS Desktop

Ubuntu 20.04 LTS Desktop tiene una configuración de GUI para activar el CLS. Puede hacerlo durante la configuración posterior a la instalación o más tarde, abriendo Software y actualizaciones y yendo a la pestaña Livepatch.

En una nueva instalación de Ubuntu

Después del primer reinicio de una instalación nueva, tenga cuidado con la segunda pantalla de la ventana de diálogo ‘Novedades de Ubuntu’. Esto le permite configurar Livepatch.

1. Haga clic en ‘Configurar Livepatch…’
2. En la pantalla «Cuenta de inicio de sesión único de Ubuntu», inicie sesión con su cuenta Livepatch o Ubuntu One.
3. Si está utilizando la GUI de instalación basada en texto, en «Instantáneas de servidor destacadas», seleccione canonical-livepatch.

En una instalación de Ubuntu existente

1. Abra ‘Software y actualizaciones’ y vaya a la pestaña ‘Livepatch’.
2. Iniciar sesión.
3. Después de iniciar sesión, haga clic en Continuar cuando aparezca la ventana emergente que confirma que ha iniciado sesión.
4. Eso es todo. El parche en vivo está configurado en su escritorio Ubuntu 20.04.

Errores en Ubuntu 20.04 con Livepatch

Puede encontrar el siguiente error al habilitar Livepatch en Ubuntu 20.04 fosa focal:

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 corregir el error, escriba los siguientes comandos en la 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 el servidor Ubuntu 20.04 LTS

Este es el enfoque de línea de comandos para versiones de servidor estándar sin un sistema de ventanas instalado. También funciona en las versiones 16.04 LTS, 14.04 LTS y 18.04 LTS.

Abra una terminal e ingrese estos dos comandos:

sudo snap install canonical-livepatch
sudo canonical-livepatch enable <your key>

Puntas

• El segundo comando devuelve un token de máquina. No sirve para nada y no hay necesidad de grabarlo.
• Lleve un registro de las máquinas que está registrando. Si pierde el rastro o se deshace de una máquina o máquina virtual antes de cancelar el registro, en realidad está desechando una de sus tres licencias gratuitas. (Hay ayuda aquí.)
• Para cancelar el registro de un servidor, use este comando:

sudo canonical-livepatch disable <your key>

• Para verificar el estado del servicio, use 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. Admite una gama más amplia de sistemas operativos, incluidos CentOS, RHEL, Oracle Linux, Debian, Ubuntu y otros. También es compatible con la línea de kernel 2.6.32 más antigua.

A diferencia de CLS, está completamente automatizado y verificará los lanzamientos de parches cada cuatro horas, instalándolos sin supervisión si hay alguno disponible. Si necesita anular esa capacidad o vincular los servidores a parches de fecha fija, existe una utilidad de línea de comandos (kcarectl) que le permite hacer esto y otras cosas.

KernelCare es gratuito para organizaciones sin fines de lucro, o existe una prueba gratuita de 30 días para el resto de nosotros. (Si es un usuario de Ksplice, es posible que desee probar el Ksplice-to-KernelCare de dos pasos secuencia de comandos de migración.)

Antes de que empieces

• Asegúrese de que su sistema esté actualizado y respaldado.
• Obtenga una clave de prueba gratuita de aquí.

Instalación de KernelCare en Ubuntu 20.04 LTS Desktop y Server

Abra una terminal e ingrese 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.

Puntas

• Para cancelar el registro de un servidor, use este comando:

sudo kcarectl --unregister

• Para verificar el estado del servicio, use este comando:

sudo kcarectl --info

Conclusión

La aplicación de parches en vivo en Linux fue demasiado útil para permanecer libre por mucho tiempo.

Con la versión 20.04 LTS de Ubuntu, es más fácil disfrutar de las ventajas de los parches de seguridad en vivo de los kernels de Linux, y es gratis para hasta tres hosts. Después de eso, anualmente, por servidor Tarifa aplicar.

Si ejecuta muchas versiones de Linux, pero no quiere aprender diferentes productos o suscribirse a diferentes contratos de soporte, eche un vistazo a KernelCare. son unas cinco veces más económico al suscribirse anualmente, y ofrecen suscripciones mensuales flexibles.