Lennart Pottering propuso una nueva arquitectura de arranque verificada de Linux

Lennart Poettering ha publicado una propuesta para modernizar el proceso de arranque de las distribuciones de Linux, destinada a resolver los problemas existentes y simplificar la organización de un arranque completamente verificado que confirme la confiabilidad del kernel y el entorno del sistema subyacente. Los cambios necesarios para implementar la nueva arquitectura ya están incluidos en el código base de systemd y afectan a componentes como systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase y systemd-creds.

Los cambios propuestos se reducen a la creación de una única imagen universal UKI (Unified Kernel Image), que combina la imagen del kernel de Linux, un controlador para cargar el kernel desde UEFI (UEFI boot stub) y el entorno del sistema initrd cargado en la memoria, utilizado para inicialización inicial en la etapa anterior al montaje del FS raíz. En lugar de una imagen de disco RAM initrd, todo el sistema se puede empaquetar en UKI, lo que le permite crear entornos de sistema completamente verificados cargados en RAM. La imagen UKI está formateada como un archivo ejecutable en formato PE, que se puede cargar no solo utilizando cargadores de arranque tradicionales, sino que también se puede llamar directamente desde el firmware UEFI.

La capacidad de llamar desde UEFI le permite utilizar una verificación de integridad de firma digital que cubre no solo el kernel, sino también el contenido del initrd. Al mismo tiempo, la compatibilidad con llamadas desde cargadores de arranque tradicionales le permite conservar funciones como la entrega de varias versiones del kernel y la reversión automática a un kernel que funcione si se detectan problemas con el nuevo kernel después de instalar la actualización.

Actualmente, en la mayoría de las distribuciones de Linux, el proceso de inicialización utiliza la cadena "firmware → capa de compensación de Microsoft firmada digitalmente → cargador de arranque GRUB firmado digitalmente por la distribución → kernel de Linux firmado digitalmente → entorno initrd no firmado → FS raíz". La falta de verificación initrd en las distribuciones tradicionales crea problemas de seguridad, ya que, entre otras cosas, en este entorno se recuperan las claves para descifrar el sistema de archivos raíz.

La verificación de la imagen initrd no es compatible ya que este archivo se genera en el sistema local del usuario y no se puede certificar con una firma digital del kit de distribución, lo que complica enormemente la organización de la verificación cuando se utiliza el modo SecureBoot (para verificar el initrd, el El usuario debe generar sus propias claves y cargarlas en el firmware UEFI). Además, la organización de arranque actual no permite el uso de información de los registros TPM PCR (Registro de configuración de plataforma) para controlar la integridad de los componentes del espacio de usuario distintos de shim, grub y el kernel. Entre los problemas existentes también se mencionan la complejidad de actualizar el gestor de arranque y la imposibilidad de restringir el acceso a las claves en el TPM para versiones anteriores del sistema operativo que se han vuelto irrelevantes después de instalar la actualización.

Los principales objetivos de introducir la nueva arquitectura de carga son:

  • Proporcionar un proceso de inicio completamente verificado que abarca desde el firmware hasta el espacio del usuario, confirmando la validez e integridad de los componentes que se inician.
  • Vincular recursos controlados a registros TPM PCR, separados por propietario.
  • Capacidad para calcular previamente los valores de PCR en función del kernel, initrd, configuración y ID del sistema local utilizado durante el arranque.
  • Protección contra ataques de reversión asociados con la reversión a una versión anterior vulnerable del sistema.
  • Simplifique y aumente la confiabilidad de las actualizaciones.
  • Compatibilidad con actualizaciones del sistema operativo que no requieren volver a aplicar ni aprovisionar localmente recursos protegidos por TPM.
  • El sistema está listo para la certificación remota para confirmar la corrección del sistema operativo y la configuración cargados.
  • La capacidad de adjuntar datos confidenciales a determinadas etapas de arranque, por ejemplo, extrayendo claves de cifrado para el sistema de archivos raíz del TPM.
  • Proporciona un proceso seguro, automático y sin usuarios para desbloquear claves para descifrar una unidad de partición raíz.
  • Uso de chips que soportan la especificación TPM 2.0, con capacidad de revertir a sistemas sin TPM.

Fuente: opennet.ru

Añadir un comentario