Habiendo instalado recientemente un controlador que requería que el módulo se firmara manualmente, resultaba confuso qué estaba haciendo realmente ese módulo y por qué tenía que hacerse.
Hay otras preguntas sobre el proceso aquí, pero son más técnicas. ¿Cuál es una explicación simple de lo que hace la firma de módulos y por qué es necesaria, así como cuáles son las alternativas (aparentemente, dkms puede firmar módulos automáticamente)?
Respuesta1
El kernel se puede configurar para que simplemente le avise cuando se utilizan módulos sin firmar o firmados incorrectamente (mediante un mensaje de registro + estableciendo un indicador de contaminación en el kernel), o para rechazar por completo cualquier módulo del kernel que no tenga una firma en el kernel. puede validar.
Cuando se utiliza un proceso de arranque estilo BIOS, o cuando se usa UEFI con el arranque seguro deshabilitado, esto es esencialmente solo un procedimiento de seguridad adicional opcional. Hará algo más difícil para los intrusos agregar módulos malignos del kernel (como rootkits basados en el kernel, para ocultar las herramientas y acciones del intruso) al sistema.
Pero cuando se utiliza UEFI con el Arranque seguro habilitado, es parte de los requisitos de Arranque seguro. El "espíritu" del arranque seguro es no permitir la carga de código que no es de confianza en el espacio del kernel. El firmware UEFI comprueba la presencia de una firma válida (o un hash SHA256 incluido en la lista blanca) en el gestor de arranque; se requiere que el gestor de arranque verifique lo mismo en el kernel del sistema operativo; y se supone que el kernel debe extender este requisito a todo el código que se ejecutará en el espacio del kernel.
Por supuesto, en la práctica el kernel del sistema operativo puede fácilmente excluirse de este requisito. Pero las organizaciones que desarrollaron el Arranque Seguro han decidido que esta opción de no participar debería al menos requerir una acción definitiva por parte del administrador del sistema: lo predeterminado debería ser hacer cumplir el requisito de firma.
(Por cierto, esto también es parte de la razón por la que Windows moderno requiere que todos los controladores instalados estén firmados de forma predeterminada. Si desea instalar controladores no firmados, debe cambiar explícitamente una configuración que requiera acceso de administrador).
Una herramienta que pudiera iniciarse en un sistema de arranque seguro y permitiría la ejecución de código de espacio del kernel sin firmar "listo para usar" se llamaríaDispositivo de elusión de arranque seguroy sería clasificable como malware.
Microsoft es el firmante de arranque seguro más conocido y solo firmará versiones del shimx64.eficargador de arranque shim que aplicarán el requisito de firma.
Un firmware UEFI compatible con arranque seguro tendrá la capacidad incorporada de verificar firmas en archivos binarios que usan el formato binario Microsoft PE+, que es lo que *.efiusan los archivos. Pero el mundo Linux generalmente no usa ese formato binario: en su lugar se usa el formato binario ELF.
Tanto los módulos del kernel de Linux como los módulos del gestor de arranque GNU GRUB se basan en el formato ELF. Esto requiere que el gestor de arranque y el kernel proporcionen sus propios algoritmos de verificación de firmas para los binarios ELF, pero aparentemente el Foro UEFI (el consorcio de la industria que administra las especificaciones UEFI y Secure Boot) ha decidido que está bien hacerlo siempre que se cumpla el requisito predeterminado. para firmas válidas se mantiene.
Por supuesto, esto no funciona como se esperaba si usa DKMS para crear y firmar automáticamente los módulos del kernel: significa que habrá un certificado con su clave privada presente que se puede usar para producir automáticamente una firma válida, por lo que un intruso también puede Úselo también para firmar cualquier módulo del kernel maligno. No es menos seguro que un sistema sin arranque seguro, pero tampoco mucho más seguro.
Si tiene varios sistemas, podría obtener algún beneficio de seguridad al tener la clave privada para el certificado de firma de su módulo solo en un host (presumiblemente el que esté menos amenazado por los atacantes) y usarlo para construir núcleos y/o módulos personalizados. que pueda necesitar y distribuirlos desde allí a cualquier otro host que los necesite. De esa manera, los otros hosts solo necesitarían la parte pública del certificado de firma del módulo, que solo puede usarse para validar firmas existentes, no para crear otras nuevas.