☰

======== RESUMEN

tag-icon • tag-icon 16.04 drivers
======== RESUMEN

¿Cómo puedo instalar cualquier módulo en Ubuntu 16.04 sin firmar o sin editar ninguna configuración del kernel? ¿Es posible? Cualquier ayuda será apreciada.

Respuesta1

O deshabilita el arranque seguro o firma el módulo del kernel.

Personalmente, desactivo el arranque seguro en la BIOS.

Verhttps://wiki.ubuntu.com/SecurityTeam/SecureBoot

O para firmar manualmente el módulo del kernel, consulte

https://www.kernel.org/doc/Documentation/module-signing.txt

      ==============================          KERNEL MODULE SIGNING FACILITY
      ==============================

CONTENIDO

  • Descripción general.
  • Configuración de la firma del módulo.
  • Generación de claves de firma.
  • Claves públicas en el kernel.
  • Firmar módulos manualmente.
  • Módulos firmados y desmontaje.
  • Cargando módulos firmados.
  • Firmas no válidas y módulos sin firmar.
  • Administrar/proteger la clave privada.

======== RESUMEN

La función de firma del módulo del kernel firma criptográficamente los módulos durante la instalación y luego verifica la firma al cargar el módulo. Esto permite una mayor seguridad del kernel al no permitir la carga de módulos sin firmar o módulos firmados con una clave no válida. La firma de módulos aumenta la seguridad al dificultar la carga de un módulo malicioso en el kernel. La verificación de la firma del módulo la realiza el kernel, por lo que no es necesario tener bits de espacio de usuario confiables.

Esta instalación utiliza certificados estándar X.509 ITU-T para codificar las claves públicas involucradas. Las firmas no están codificadas en ningún tipo estándar industrial. Actualmente, la instalación solo admite el estándar de cifrado de clave pública RSA (aunque es conectable y permite utilizar otros). Los posibles algoritmos hash que se pueden utilizar son SHA-1, SHA-224, SHA-256, SHA-384 y SHA-512 (el algoritmo se selecciona según los datos de la firma).

========================== CONFIGURACIÓN DE LA FIRMA DEL MÓDULO

La función de firma del módulo se habilita yendo a la sección "Habilitar soporte de módulo cargable" de la configuración del kernel y activando

CONFIG_MODULE_SIG "Verificación de firma del módulo"

Esto tiene varias opciones disponibles:

(1) "Requerir que los módulos estén firmados válidamente" (CONFIG_MODULE_SIG_FORCE)

 This specifies how the kernel should deal with a module that has a
 signature for which the key is not known or a module that is unsigned.

 If this is off (ie. "permissive"), then modules for which the key is not
 available and modules that are unsigned are permitted, but the kernel will
 be marked as being tainted, and the concerned modules will be marked as
 tainted, shown with the character 'E'.

 If this is on (ie. "restrictive"), only modules that have a valid
 signature that can be verified by a public key in the kernel's possession
 will be loaded.  All other modules will generate an error.

 Irrespective of the setting here, if the module has a signature block that
 cannot be parsed, it will be rejected out of hand.

(2) "Firmar automáticamente todos los módulos" (CONFIG_MODULE_SIG_ALL)

 If this is on then modules will be automatically signed during the
 modules_install phase of a build.  If this is off, then the modules must
 be signed manually using:

scripts/archivo de firma

(3) "¿Con qué algoritmo hash se deben firmar los módulos?"

 This presents a choice of which hash algorithm the installation phase will
 sign the modules with:

CONFIG_MODULE_SIG_SHA1 "Firmar módulos con SHA-1" CONFIG_MODULE_SIG_SHA224 "Firmar módulos con SHA-224" CONFIG_MODULE_SIG_SHA256 "Firmar módulos con SHA-256" CONFIG_MODULE_SIG_SHA384 "Firmar módulos con SHA-384" CONFIG_MODULE_SIG_SHA512 módulos con SHA-512"

 The algorithm selected here will also be built into the kernel (rather
 than being a module) so that modules signed with that algorithm can have
 their signatures checked without causing a dependency loop.

(4) "Nombre de archivo o URI PKCS#11 de la clave de firma del módulo" (CONFIG_MODULE_SIG_KEY)

 Setting this option to something other than its default of
 "certs/signing_key.pem" will disable the autogeneration of signing keys
 and allow the kernel modules to be signed with a key of your choosing.
 The string provided should identify a file containing both a private key
 and its corresponding X.509 certificate in PEM form, or — on systems where
 the OpenSSL ENGINE_pkcs11 is functional — a PKCS#11 URI as defined by
 RFC7512. In the latter case, the PKCS#11 URI should reference both a
 certificate and a private key.

 If the PEM file containing the private key is encrypted, or if the
 PKCS#11 token requries a PIN, this can be provided at build time by
 means of the KBUILD_SIGN_PIN variable.

(5) "Claves X.509 adicionales para el conjunto de claves predeterminado del sistema" (CONFIG_SYSTEM_TRUSTED_KEYS)

 This option can be set to the filename of a PEM-encoded file containing
 additional certificates which will be included in the system keyring by
 default.

Tenga en cuenta que habilitar la firma del módulo agrega una dependencia de los paquetes de desarrollo OpenSSL a los procesos de compilación del kernel para la herramienta que realiza la firma.

======================== GENERACIÓN DE CLAVES DE FIRMA

Se requieren pares de claves criptográficas para generar y verificar firmas. Se utiliza una clave privada para generar una firma y la clave pública correspondiente para verificarla. La clave privada sólo es necesaria durante la compilación, después de lo cual se puede eliminar o almacenar de forma segura. La clave pública se integra en el kernel para que pueda usarse para verificar las firmas a medida que se cargan los módulos.

En condiciones normales, cuando CONFIG_MODULE_SIG_KEY no cambia su valor predeterminado, la compilación del kernel generará automáticamente un nuevo par de claves usando openssl si no existe uno en el archivo:

certificados/signing_key.pem

durante la construcción de vmlinux (la parte pública de la clave debe integrarse en vmlinux) usando parámetros en:

certificados/x509.genkey

archivo (que también se genera si aún no existe).

Se recomienda encarecidamente que proporcione su propio archivo x509.genkey.

En particular, en el archivo x509.genkey, la sección req_distiowned_name debe modificarse respecto del valor predeterminado:

[ req_distiowned_name ] #O = Compañía no especificada CN = Clave del kernel generada automáticamente en el momento de la compilación #emailAddress = [correo electrónico protegido]

El tamaño de la clave RSA generada también se puede configurar con:

[req] bits_predeterminados = 4096

También es posible generar manualmente los archivos públicos/privados de claves utilizando el archivo de configuración de generación de claves x509.genkey en el nodo raíz del árbol de fuentes del kernel de Linux y el comando openssl. El siguiente es un ejemplo para generar los archivos de clave pública/privada:

openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \ -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem

La ruta completa para el archivo kernel_key.pem resultante se puede especificar en la opción CONFIG_MODULE_SIG_KEY, y el certificado y la clave que contiene se utilizarán en lugar de un par de claves generado automáticamente.

========================= CLAVES PÚBLICAS EN EL KERNEL

El kernel contiene un anillo de claves públicas que el root puede ver. Están en un conjunto de claves llamado ".system_keyring" que puede verse mediante:

[root@deneb ~]# cat /proc/keys ... 223c7853 I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1 302d2d52 I------
1 perm 1f010000 0 0 firma asimétrica del kernel de Fedora clave: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 []...

Más allá de la clave pública generada específicamente para la firma del módulo, se pueden proporcionar certificados confiables adicionales en un archivo codificado con PEM al que hace referencia la opción de configuración CONFIG_SYSTEM_TRUSTED_KEYS.

Además, el código de arquitectura puede tomar claves públicas de una tienda de hardware y agregarlas también (por ejemplo, de la base de datos de claves UEFI).

Finalmente, es posible agregar claves públicas adicionales haciendo:

keyctl padd asimétrico "" [.system_keyring-ID] <[archivo-clave]

p.ej:

keyctl padd asimétrico "" 0x223c7853

Sin embargo, tenga en cuenta que el kernel solo permitirá agregar claves a .system_keyringsiEl contenedor X.509 de la nueva clave está firmado válidamente por una clave que ya reside en .system_keyring en el momento en que se agregó la clave.

========================= FIRMAR MÓDULOS MANUALMENTE

Para firmar manualmente un módulo, utilice la herramienta scripts/sign-file disponible en el árbol de fuentes del kernel de Linux. El guión requiere 4 argumentos:

  1. El algoritmo hash (por ejemplo, sha256)
  2. El nombre del archivo de clave privada o URI PKCS#11
  3. El nombre del archivo de clave pública
  4. El módulo del kernel a firmar

El siguiente es un ejemplo para firmar un módulo del kernel:

scripts/archivo de signos sha512 kernel-signkey.priv \ kernel-signkey.x509 module.ko

El algoritmo hash utilizado no tiene que coincidir con el configurado, pero si no es así, debe asegurarse de que el algoritmo hash esté integrado en el kernel o se pueda cargar sin necesidad de hacerlo.

Si la clave privada requiere una frase de contraseña o PIN, se puede proporcionar en la variable de entorno $KBUILD_SIGN_PIN.

============================= MÓDULOS FIRMADOS Y DESMONTAJE

Un módulo firmado tiene una firma digital simplemente adjunta al final. La cadena "~Firma del módulo adjunta~". al final del archivo del módulo confirma que hay una firma pero no confirma que la firma sea válida.

Los módulos firmados son FRÁGILES ya que la firma está fuera del contenedor ELF definido. Por lo tanto NO PUEDEN ser eliminados una vez computada y adjuntada la firma. Tenga en cuenta que todo el módulo es la carga útil firmada, incluida toda la información de depuración presente en el momento de la firma.

======================= CARGANDO MÓDULOS FIRMADOS

Los módulos se cargan con insmod, modprobe, init_module() o finit_module(), exactamente igual que los módulos sin firmar, ya que no se realiza ningún procesamiento en el espacio de usuario. La verificación de firmas se realiza dentro del kernel.

========================================= FIRMAS NO VÁLIDAS Y MÓDULOS SIN FIRMAR

Si CONFIG_MODULE_SIG_FORCE está habilitado o module.sig_enforce=1 se proporciona en la línea de comando del kernel, el kernel solo cargará módulos firmados válidamente para los cuales tenga una clave pública. De lo contrario, también cargará módulos que no estén firmados. No se permitirá la carga de ningún módulo para el cual el kernel tenga una clave, pero que demuestre que tiene una firma que no coincide.

Cualquier módulo que tenga una firma no analizable será rechazado.

========================================= ADMINISTRACIÓN/PROTECCIÓN DE LA CLAVE PRIVADA

Dado que la clave privada se utiliza para firmar módulos, los virus y el malware podrían utilizar la clave privada para firmar módulos y comprometer el sistema operativo. La clave privada debe destruirse o trasladarse a una ubicación segura y no guardarse en el nodo raíz del árbol de fuentes del kernel.

Respuesta2

Tuve el mismo problema al cargar el controlador. Simplemente pasé module.sig_enforce=0la línea de comando de mi kernel grub linux.

Estos son los pasos:

Agregar permanentemente un parámetro de arranque del kernel

  • Inicie sesión en el sistema e inicie una ventana de terminal (Aplicaciones→Accesorios→Terminal).

  • Cuando $se le solicite, ingrese el comando:

    sudo gedit /etc/default/grub

  • Ingrese su contraseña cuando se le solicite [sudo].

Si el archivo /etc/default/grubparece estar vacío o no existe, consulte las instrucciones anteriores para versiones anteriores.

  • En la ventana del editor, use las teclas de flecha para mover el cursor a la línea que comienza con y GRUB_CMDLINE_LINUX_DEFAULTluego edite esa línea, agregando sus parámetros al texto dentro de las comillas dobles después de las palabras quiet splash. Yo añadí module.sig_enforce=0. (Asegúrese de agregar un ESPACIO splashantes de agregar su nuevo parámetro).

  • Haga clic en elAhorrarbotón

  • Cierra la ventana del editor.

  • En la ventana de terminal cuando $se le solicite, ingrese:

    sudo update-grub

  • Reinicie el sistema.

Intente cargar su módulo y funcionó para mí.

Respuesta3

Ubuntu 16.04 admite pci_set_dma_mask en lugar de pci_dma_supported para crear controladores PCI. El uso incorrecto de la API imprimirá un error de discrepancia en la clave de inicio segura al cargar el controlador.

Respuesta4

En el kernel v5.4, puede desactivar el indicador MODULE_SIG_FORCEy luego reconstruir el kernel.

información relacionada