¿Qué es UEFI Secure Boot?

UEFI Secure boot es un mecanismo de verificación para garantizar que el código lanzado por el firmware es de confianza.

El uso correcto y seguro de UEFI Secure Boot requiere que cada binario cargado en el arranque se valide con claves conocidas, ubicadas en el firmware, que denotan proveedores y fuentes de confianza para los binarios, o binarios específicos de confianza que se pueden identificar mediante hash criptográfico.

La mayoría del hardware x86 viene de fábrica con claves de Microsoft precargadas. Esto significa que generalmente podemos confiar en el firmware de estos sistemas para confiar en los binarios firmados por Microsoft, y la comunidad Linux confía en gran medida en este supuesto para que funcione el Arranque seguro. Este es el mismo proceso utilizado por Red Hat y SUSE, por ejemplo.

Muchas arquitecturas ARM y otras también admiten el arranque seguro UEFI, pero es posible que no sean claves de carga previa en el firmware. En estas arquitecturas, puede ser necesario volver a firmar las imágenes de arranque con un certificado cargado en el firmware por el propietario del hardware.

Plan de implementación inicial: Plan de implementación.

Arquitecturas compatibles

• amd64: Un binario shim firmado por Microsoft y un binario grub firmado por Canonical se proporcionan en el archivo principal de Ubuntu como firmado por shim o firmado por grub-efi-amd64.

• arm64: A partir de 20.04 (‘focal’), un binario shim firmado por Microsoft y un binario grub firmado por Canonical se proporcionan en el archivo principal de Ubuntu como firmado por shim o firmado por grub-efi-arm64. Hay un error de GRUB bajo investigación que necesita ser resuelto antes de que funcione de principio a fin.

Probar el arranque seguro de UEFI

Si está interesado en probar el arranque seguro en su sistema, consulte las instrucciones aquí: UEFI/SecureBoot/Testing.

Cómo funciona el arranque seguro de UEFI en Ubuntu

En Ubuntu, todos los binarios prediseñados destinados a ser cargados como parte del proceso de arranque, con la excepción de la imagen initrd, están firmados por el certificado UEFI de Canonical, que a su vez es de confianza implícita al estar incrustado en el cargador de shim, a su vez firmado por Microsoft.

En arquitecturas o sistemas donde los certificados de firma precargados de Microsoft no están disponibles o no están cargados en el firmware, los usuarios pueden reemplazar las firmas existentes en shim o grub y cargarlas como deseen, verificándolas con sus propios certificados importados en el firmware del sistema.

A medida que el sistema arranca, el firmware carga el binario shim como se especifica en las variables de arranque del firmware. Ubuntu instala su propio BootEntry en el momento de la instalación y puede actualizarlo en cualquier momento en que se actualice el gestor de arranque GRUB. Dado que el binario shim está firmado por Microsoft; es validado y aceptado por el firmware cuando se verifica con certificados ya presentes en el firmware. Dado que el binario shim incorpora un certificado Canónico, así como su propia base de datos de confianza, otros elementos del entorno de arranque pueden, además de estar firmados por uno de los certificados aceptables precargados en el firmware, estar firmados por la clave UEFI de Canonical.

Lo siguiente que carga shim es la imagen de la segunda etapa. Esto puede ser una de dos cosas: GRUB, si el sistema arranca normalmente; o MokManager, si se requiere administración de claves, según lo configurado por variables de firmware (generalmente cambiadas cuando el sistema se estaba ejecutando anteriormente).

Si arranca normalmente; el binario GRUB (grub*.efi) se carga y se intenta su validación en todas las fuentes de confianza conocidas anteriormente. El binario GRUB para Ubuntu está firmado por la clave canónica UEFI, por lo que se valida con éxito y el proceso de arranque continúa.

Si se inicia para continuar con las tareas de administración de claves, el binario de MokManager (mm*.efi) está cargada. Shim confía explícitamente en este binario al estar firmado por una clave efímera que solo existe mientras se construye el binario shim. Esto significa que solo se permitirá ejecutar el binario de MokManager construido con un binario shim en particular y limita la posibilidad de compromiso del uso de herramientas comprometidas. MokManager permite a cualquier usuario presente en la consola del sistema inscribir claves, eliminar claves de confianza, inscribir hashes binarios y alternar la validación de arranque seguro a nivel de cuña, pero la mayoría de las tareas requieren que se ingrese una contraseña establecida previamente para confirmar que el usuario en la consola es de hecho la persona que solicitó los cambios. Dichas contraseñas solo sobreviven a través de una sola ejecución de shim / MokManager; y se borran tan pronto como se completa o cancela el proceso. Una vez que se completa la administración de claves, el sistema se reinicia y no simplemente continúa con el arranque, ya que los cambios de administración de claves pueden ser necesarios para completar con éxito el arranque.

Una vez que el sistema continúa arrancando a GRUB, el proceso GRUB carga cualquier configuración requerida (normalmente cargando la configuración desde la partición del sistema ESP (EFI System Partition), apuntando a otro archivo de configuración en la partición raíz o de arranque), que lo dirigirá a la imagen del núcleo para cargarla.

Aplicaciones EFI hasta este punto, al tener acceso completo al firmware del sistema, incluido el acceso a variables de firmware de confianza cambiantes, el núcleo a cargar también debe validarse con la base de datos de confianza. Los núcleos oficiales de Ubuntu están firmados por la clave canónica UEFI, se validan con éxito y el control se entrega al núcleo. Las imágenes Initrd no están validadas.

En el caso de núcleos no oficiales, o núcleos construidos por usuarios, se deben tomar pasos adicionales si los usuarios desean cargar dichos núcleos mientras conservan todas las capacidades de Arranque seguro de UEFI. Todos los núcleos deben estar firmados para que GRUB pueda cargarlos cuando se habilite el Arranque seguro UEFI, por lo que el usuario deberá proceder con su propia firma. Alternativamente, los usuarios pueden desear deshabilitar la validación en shim mientras se inicia con Arranque seguro habilitado en un núcleo oficial utilizando ‘sudo mokutil disable disable-validation’, proporcionando una contraseña cuando se le solicite y reiniciando; o deshabilitar el arranque seguro en firmware por completo.

Hasta este punto, cualquier error al validar una imagen para cargarla se resuelve con un error crítico que detiene el proceso de arranque. El sistema no continuará arrancando, y puede reiniciarse automáticamente después de un período de tiempo dado que otras variables de arranque pueden contener rutas de arranque válidas y de confianza.

Una vez cargado, los núcleos validados deshabilitarán los Servicios de arranque del firmware, eliminando así los privilegios y cambiando efectivamente al modo de usuario; donde el acceso a las variables de confianza está limitado a solo lectura. Dados los amplios permisos otorgados a los módulos del núcleo, cualquier módulo que no esté integrado en el núcleo también deberá validarse al cargarse. Los módulos construidos y enviados por Canonical con los núcleos oficiales están firmados por la clave Canónica UEFI y, como tal, son de confianza. Los módulos personalizados requerirán que el usuario tome las medidas necesarias para firmar los módulos antes de que el núcleo les permita cargarlos. Esto se puede lograr usando el comando’ kmodsign’.

Los módulos sin firmar son simplemente rechazados por el núcleo. Cualquier intento de insertarlos con insmod o modprobe fallará con un mensaje de error.

Dado que muchos usuarios requieren módulos de terceros para que sus sistemas funcionen correctamente o para que algunos dispositivos funcionen; y dado que estos módulos de terceros requieren la construcción local en el sistema para ajustarse al núcleo en ejecución, Ubuntu proporciona herramientas para automatizar y simplificar el proceso de firma.

¿Cómo puedo hacer la firma no automatizada de controladores?

Algunos proyectos pueden requerir el uso de controladores de kernel personalizados que no están configurados de tal manera que funcionen con DKMS. En estos casos, las personas deben hacer uso de las herramientas incluidas en el paquete firmado por shim: el script update-secureboot-policy está disponible para generar un nuevo MOK (si ningún módulo construido por DKMS ya ha activado la generación de uno).

Use el siguiente comando para inscribir una clave existente en shim:

sudo update-secureboot-policy --enroll-key

Si no existe MOK, el script saldrá con un mensaje a tal efecto. Si la clave ya está inscrita, el script se cerrará sin hacer nada. Si la clave existe pero no se muestra inscrita, se solicitará al usuario una contraseña para usar después del reinicio, de modo que se pueda inscribir la clave.

Se puede generar un nuevo MOK usando el siguiente comando:

sudo update-secureboot-policy --new-key

Y luego inscribir la clave recién generada en shim con el comando mencionado anteriormente para esa tarea.

Los módulos del núcleo se pueden firmar con el comando kmodsign (véase UEFI/SecureBoot/Signing) como parte de su proceso de compilación.

Implicaciones de seguridad en la administración de claves del Propietario de la máquina

El MOK generado en el momento de la instalación o en la actualización es específico de la máquina, y solo el núcleo o shim permite firmar módulos del núcleo, mediante el uso de un OID de uso de claves específico (1.3.6.1.4.1.2312.16.1.2) que denota las limitaciones del MOK.

Las versiones recientes de shim incluyen lógica para seguir las limitaciones de las claves de solo firma de módulos. Se permitirá que estas claves se inscriban en el firmware de la base de datos de confianza de shim, pero se ignorarán cuando shim o GRUB validen imágenes para cargarlas en el firmware. La función verify() de Shim solo validará con éxito las imágenes firmadas por claves que no incluyan el OID de «Solo firma de módulos» (1.3.6.1.4.1.2312.16.1.2) keyUsage. Los núcleos de Ubuntu utilizan la base de datos global trust (que incluye tanto shim como el firmware) y aceptarán cualquiera de las claves incluidas como claves de firma al cargar los módulos del núcleo.

Dadas las limitaciones impuestas al MOK generado automáticamente y el hecho de que los usuarios con acceso de superusuario al sistema y acceso a la consola del sistema para ingresar la contraseña requerida al inscribir claves ya tienen acceso de alto nivel al sistema; la clave MOK generada se mantiene en el sistema de archivos como archivos regulares propiedad de root con permisos de solo lectura. Esto se considera suficiente para limitar el acceso al MOK para la firma por parte de usuarios o scripts maliciosos, especialmente dado que no existe MOK en el sistema a menos que requiera controladores de terceros. Esto limita la posibilidad de compromiso desde el mal uso de una clave MOK generada hasta la firma de un módulo de núcleo malicioso. Esto es equivalente al compromiso de las aplicaciones de usuario que ya sería posible con el acceso de superusuario al sistema, y asegurar esto está fuera del alcance del Arranque seguro UEFI.

Los sistemas anteriores pueden haber tenido desactivada la validación de arranque seguro en shim. Como parte del proceso de actualización, estos sistemas se migrarán para volver a habilitar la validación de arranque seguro en shim e inscribir una nueva clave MOK cuando corresponda.

Proceso de generación y firma de MOK

El proceso de generación y firma de claves es ligeramente diferente en función de si estamos tratando con una instalación nueva o una actualización del sistema que anteriormente ejecutaba Ubuntu; estos dos casos están claramente marcados a continuación.

En todos los casos, si el sistema no arranca en modo UEFI, no se realizarán pasos especiales de firma de módulos del núcleo ni generación de claves.

Si el Arranque seguro está deshabilitado, la generación y la inscripción de MOK siguen ocurriendo, ya que el usuario puede habilitar posteriormente el arranque seguro. El sistema debe funcionar correctamente si ese es el caso.

El usuario instala Ubuntu en un nuevo sistema

El usuario pasa por el instalador. Al principio, al prepararse para la instalación y solo si el sistema requiere módulos de terceros para funcionar, se solicita al usuario una contraseña del sistema que se marca claramente como necesaria después de que se complete la instalación, y mientras se instala el sistema, se genera automáticamente un nuevo MOK sin interacción adicional del usuario.

Los controladores o módulos de kernel de terceros requeridos por el sistema se compilarán automáticamente cuando se instale el paquete, y el proceso de compilación incluye un paso de firma. El paso de firma utiliza automáticamente el MOK generado anteriormente para firmar el módulo, de modo que se puede cargar inmediatamente una vez que se reinicia el sistema y el MOK se incluye en la base de datos de confianza del sistema.

Una vez que se completa la instalación y se reinicia el sistema, en el primer arranque se presenta al usuario el programa MokManager (parte del cargador de cuñas instalado), como un conjunto de paneles de modo de texto que todo el usuario debe inscribir al MOK generado. El usuario selecciona «Inscribir MOK», se muestra una huella digital del certificado para inscribirse y se le solicita que confirme la inscripción. Una vez confirmado, el nuevo MOK se ingresará en el firmware y se le pedirá al usuario que reinicie el sistema.

Cuando el sistema se reinicia, los controladores de terceros firmados por el MOK recién inscrito se cargarán según sea necesario.

El usuario actualiza un sistema Ubuntu habilitado para UEFI a una nueva versión donde el sistema requiere controladores de terceros

Al actualizar, se actualizan los paquetes shim y shim firmados. Las tareas posteriores a la instalación del paquete firmado por shim proceden a generar un nuevo MOK y solicitan al usuario una contraseña que se menciona claramente como necesaria una vez que se completa el proceso de actualización y se reinicia el sistema.

Durante la actualización, se actualizan los paquetes del núcleo y los módulos de terceros. Los módulos de terceros se reconstruyen para los nuevos núcleos y su proceso posterior a la compilación procede a firmarlos automáticamente con el MOK.

Después de la actualización, se recomienda al usuario reiniciar su sistema.

En el reinicio, el usuario se presenta con el programa MokManager (parte del cargador de shim instalado), como un conjunto de paneles de modo de texto que todo el usuario para inscribir el MOK generado. El usuario selecciona «Inscribir MOK», se muestra una huella digital del certificado para inscribirse y se le solicita que confirme la inscripción. El usuario también recibe un mensaje para volver a habilitar la validación de arranque seguro (en el caso de que se encuentre deshabilitado); y MokManager nuevamente requiere la confirmación del usuario. Una vez confirmados todos los pasos, se vuelve a habilitar la validación de shim, se ingresará el nuevo MOK en el firmware y se le pedirá al usuario que reinicie el sistema.

Cuando el sistema se reinicia, los controladores de terceros firmados por el MOK recién inscrito se cargarán según sea necesario.

En todos los casos, una vez que el sistema se esté ejecutando con UEFI Secure Boot habilitado y una versión reciente de shim, la instalación de cualquier nuevo módulo DKMS (controlador de terceros) procederá a firmar el módulo construido con el MOK. Esto sucederá sin la interacción del usuario si existe una clave MOK válida en el sistema y parece que ya está inscrita.

Si no existe MOK o el MOK existente no está inscrito, se creará automáticamente una nueva clave justo antes de firmar y se le pedirá al usuario que inscriba la clave proporcionando una contraseña que se requerirá al reiniciar el sistema.