Parches en vivo del kernel de Linux en Ubuntu 20.04 LTS

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.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *