¿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 sencillas 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 Canonical Livepatch Service 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 invierten y de las que ganan 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, 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 descontrolados, 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 . Actualizaciones del núcleo son otra cosa Las actualizaciones son núcleos completamente nuevos. Los parches son actualizaciones de partes del kernel, 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 así como "Instalar lo antes posible". En la misma página habrá una versión de "Si no lo hace, será vulnerable a las vulnerabilidades que hemos parcheado que ahora todos conocen". acerca de. Que tengas un buen 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 Paraíso? ¿Cuál es el problema?
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 manipular 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 bloquear un sistema. (Este mensaje en la página de kpatch github se lee como algo del manual del operador de un martillo de vapor:'ADVERTENCIA:¡Usar con precaución! ¡Pueden ocurrir fallas del 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 libre y de código abierto de Linux. Para mí, esto 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 funcionan los 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 tosca analogía de cambio de freno anterior ilustra dos estrategias opuestas implementadas por proveedores de software de parches en vivo.
- Detenga todo y realice todas las correcciones de una sola vez.
- Espere a que los componentes individuales se detengan y luego cámbielos. Repita hasta que termine.
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 del marco del módulo del kernel cargable de Linux. 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, la aplicación de parches en vivo no puede reasignar datos o memoria entre parches; solo puede alterar definiciones de funciones.
Estas deficiencias no impidieron que Ksplice se convirtiera en el primero en el campo de los 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 (que se describe en la siguiente sección) hizo que Kpatch de Red Hat y Kgraft de SUSE se unieran 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 mediante el marco ftrace del kernel para cambiar las funciones modificadas 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 el software dinámicamente para compensar la falta de funcionalidad del hardware. Un año después, Microsoft presenta una idea para actualizar un sistema (Windows) sin interrupciones.
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, tal vez dos palabras te hagan pensar de nuevo:Meltdown y Spectre).
En 2008, Jeff Arnold anuncia Ksplice, un software para parchear kernels de Linux sin reiniciarlos. Es el primero de su tipo para Linux. Y tenemos que agradecérselo 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 artículo que lo describe, 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 cadena de pesadillas. Oracle asimila Ksplice por completo, haciendo 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, CloudLinux, productores 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 ABI de parches en vivo se está abriendo camino en la línea principal del kernel, viendo la luz del día en el lanzamiento 4.0 bajo el nombre de Livepatch. 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 de Canonical Livepatch Service (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 empezar
- Asegúrese de que su sistema esté actualizado y respaldado.
- Regístrese para obtener una cuenta de Livepatch o Ubuntu One.
- Para el servidor 20.04 LTS, obtenga una clave y anótela. (Esto no es necesario en la edición de escritorio).
Instalación de Livepatch en escritorio Ubuntu 20.04 LTS
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 instalación nueva 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.
- Haga clic en 'Configurar Livepatch...'
- En la pantalla "Cuenta de inicio de sesión único de Ubuntu", inicie sesión con su cuenta Livepatch o Ubuntu One.
- 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
- Abra 'Software y actualizaciones' y vaya a la pestaña 'Livepatch'.
- Inicia sesión.
- Después de iniciar sesión, haga clic en Continuar cuando aparezca la ventana emergente que confirma que ha iniciado sesión.
- Eso es todo. El parche en vivo está configurado en su escritorio Ubuntu 20.04.
Errores en Ubuntu 20.04 con Livepatch
Es posible que encuentre el siguiente error al habilitar 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 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>
Consejos
- El segundo comando devuelve un token de máquina. No sirve para nada y no hay necesidad de registrarlo.
- Haga un seguimiento 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, hay 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 usuario de Ksplice, es posible que desee probar el script de migración de Ksplice a KernelCare en dos pasos).
Antes de empezar
- Asegúrese de que su sistema esté actualizado y respaldado.
- Obtenga una clave de prueba gratuita desde aquí.
Instalación de KernelCare en escritorio y servidor Ubuntu 20.04 LTS
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.
Consejos
- 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 gratis 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, se aplican tarifas anuales por servidor.
Si ejecuta muchas versiones de Linux, pero no quiere aprender diferentes productos o suscribirse a diferentes contratos de soporte, eche un vistazo a KernelCare. Es unas cinco veces más barato cuando se suscribe anualmente y ofrecen suscripciones mensuales flexibles.