Il faut soit désactiver le démarrage sécurisé, soit signer le module du noyau.

Personnellement, je désactive le démarrage sécurisé dans le bios.

Voir https://wiki.ubuntu.com/SecurityTeam/SecureBoot

Ou pour signer manuellement le module du noyau, voir

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

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

SOMMAIRE

• Vue d'ensemble.
• Configuration de la signature des modules.
• Génération de clés de signature.
• Les clés publiques dans le noyau.
• Signer manuellement les modules.
• Modules signés et dépouillement.
• Chargement des modules signés.
• Signatures non valides et modules non signés.
• Administrer/protéger la clé privée.

\======== VUE D'ENSEMBLE

La fonction de signature des modules du noyau signe les modules de manière cryptographique. pendant l'installation, puis vérifie la signature au chargement du module. module. Cela permet d'augmenter la sécurité du noyau en interdisant le chargement de modules non signés ou signés avec une fausse signature. modules non signés ou signés avec une clé invalide. La signature des modules augmente la sécurité en rendant plus difficile le chargement d'un module malveillant dans le noyau. La vérification de la signature du module est module est effectuée par le noyau de sorte qu'il n'est pas nécessaire de disposer de bits bits de confiance en espace utilisateur.

Cette fonction utilise les certificats standard X.509 de l'UIT-T pour coder l'adresse de l'utilisateur. clés publiques concernées. Les signatures ne sont pas elles-mêmes codées dans aucun type de norme industrielle. L'installation ne supporte actuellement que la norme de chiffrement à clé publique RSA (bien qu'elle soit enfichable et permette d'en utiliser d'autres). Les algorithmes de hachage possibles qui peuvent être sont SHA-1, SHA-224, SHA-256, SHA-384 et SHA-512 (l'algorithme est sélectionné par les données est sélectionné par les données de la signature).

\========================== CONFIGURATION CONFIGURATION DE LA CONFIGURATION DE LA SIGNATURE D'UN MODULE

La fonction de signature de module est activée en allant dans la section "Enable Loadable Module Support" de la configuration du noyau et en cliquant sur le bouton "Signer le module". en activant

CONFIG_MODULE_SIG "Vérification de la signature d'un module".

Il existe un certain nombre d'options disponibles :

(1) "Exiger que les modules soient valablement signés" (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) "Signer automatiquement tous les modules" (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/fichier de signature

(3) "Avec quel algorithme de hachage les modules doivent-ils être signés ?"

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

CONFIG_MODULE_SIG_SHA1 "Signer les modules avec SHA-1". CONFIG_MODULE_SIG_SHA224 "Signer les modules avec SHA-224". CONFIG_MODULE_SIG_SHA256 "Signer les modules avec SHA-256". CONFIG_MODULE_SIG_SHA384 "Signer les modules avec SHA-384". CONFIG_MODULE_SIG_SHA512 "Signer les modules avec 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) "Nom de fichier ou URI PKCS#11 de la clé de signature du module". (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) "Clés X.509 supplémentaires pour le trousseau de clés du système par défaut". (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.

Notez que l'activation de la signature de module ajoute une dépendance sur les paquets OpenSSL aux processus de construction du noyau pour l'outil qui effectue la signature. la signature.

\======================= GÉNÉRATION DE CLÉS DE SIGNATURE

Les paires de clés cryptographiques sont nécessaires pour générer et vérifier les signatures. Une clé privée est utilisée pour générer une signature et la clé publique correspondante est utilisée pour générer une signature. publique correspondante est utilisée pour la vérifier. La clé privée n'est nécessaire que pendant la construction, après quoi elle peut être supprimée ou stockée en toute sécurité. Le site clé publique est intégrée au noyau afin de pouvoir être utilisée pour vérifier les les signatures au fur et à mesure que les modules sont chargés.

Dans des conditions normales, lorsque CONFIG_MODULE_SIG_KEY est inchangé par rapport à sa valeur par défaut, la compilation du noyau génère automatiquement une nouvelle nouvelle paire de clés en utilisant openssl si elle n'existe pas dans le fichier :

certs/key_signature.pem

lors de la construction de vmlinux (la partie publique de la clé doit être construite dans vmlinux) en utilisant des paramètres dans le fichier :

certs/x509.genkey

(qui est également généré s'il n'existe pas déjà).

Il est fortement recommandé de fournir votre propre fichier x509.genkey.

Plus particulièrement, dans le fichier x509.genkey, la section req_distinguished_name doit être modifiée par rapport à la valeur par défaut :

[ req_distinguished_name ] #O = Entreprise non spécifiée CN = Temps de construction clé de noyau autogénérée #emailAdress = unspecified.user@unspecified.company

La taille de la clé RSA générée peut également être définie avec :

[ req ] default_bits = 4096

Il est également possible de générer manuellement les fichiers de clés privées/publiques. à l'aide du fichier de configuration de génération de clés x509.genkey dans le nœud root de l'arborescence des sources du noyau Linux et de la commande openssl. Le site suivant est un exemple de génération des fichiers de clés publiques/privées :

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

Le nom de chemin complet du fichier kernel_key.pem résultant peut alors être être spécifié dans l'option CONFIG_MODULE_SIG_KEY, et le certificat et la clé qu'il contient seront utilisés à la place d'une paire de clés autogénérée.

\========================= CLÉS PUBLIQUES DANS LE NOYAU

Le noyau contient un anneau de clés publiques qui peuvent être consultées par root. Elles sont dans un trousseau appelé ".system_keyring" qui peut être vu par :

[root@deneb ~]# cat /proc/keys ... 223c7853 I------ 1 perm 1f030000 0 0 porte-clés .system_keyring : 1 302d2d52 I------
1 perm 1f010000 0 0 asymmetri Clé de signature du noyau de Fedora : d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 [] ...

Au-delà de la clé publique générée spécifiquement pour la signature du module, des certificats de confiance supplémentaires peuvent être fournis dans un fichier codé PEM. référencé par l'option de configuration CONFIG_SYSTEM_TRUSTED_KEYS.

En outre, le code d'architecture peut prendre les clés publiques d'un matériel et les ajouter également (par exemple, à partir de la base de données de clés UEFI).

Enfin, il est possible d'ajouter des clés publiques supplémentaires en faisant :

keyctl padd asymmetric "" [.system_keyring-ID] <[key-file]

par exemple :

keyctl padd asymmetric "" 0x223c7853

Notez cependant que le noyau n'autorisera l'ajout de clés que dans les cas suivants .system_keyring si le wrapper X.509 de la nouvelle clé est valablement signé par une clé qui réside déjà dans le trousseau de clés .system_keyring au moment où la clé a été ajoutée.

\========================= MODULES DE SIGNATURE MANUELLE

Pour signer manuellement un module, utilisez l'outil scripts/sign-file disponible dans le module l'arbre des sources du noyau Linux. Le scripts requiert 4 arguments :

1. L'algorithme de hachage (par exemple, sha256)
2. Le nom de fichier de la clé privée ou l'URI PKCS#11
3. Le nom de fichier de la clé publique
4. Le module du noyau à signer

Voici un exemple pour signer un module de noyau :

scripts/sign-file sha512 kernel-signkey.priv \ kernel-signkey.x509 module.ko

L'algorithme de hachage utilisé ne doit pas nécessairement correspondre à celui qui a été configuré, mais si ce n'est pas le cas, vous devez vous assurer que l'algorithme de hachage est soit intégré au noyau ou qu'il peut être chargé sans être nécessaire.

Si la clé privée nécessite une phrase de passe ou un code PIN, elle peut être fournie dans le formulaire de demande d'accès. dans la variable d'environnement $KBUILD_SIGN_PIN.

\============================ MODULES SIGNÉS ET DÉPOUILLÉS

Un module signé possède une signature numérique simplement ajoutée à la fin. La chaîne de caractères "~Signature du module apposée~." à la fin du fichier du module confirme la présence d'une signature mais ne confirme pas que la signature est valide !

Les modules signés sont BRITTLE car la signature est en dehors du conteneur ELF défini. conteneur ELF. Ainsi, ils NE PEUVENT PAS être dépouillés une fois que la signature est calculée et attachée. Notez que le module entier est la charge utile signée, y compris toutes les informations de débogage présentes au moment de la signature. signature.

\====================== CHARGEMENT DE MODULES SIGNÉS

Les modules sont chargés avec insmod, modprobe, init_module() ou finit_module(), exactement comme pour les modules non signés car aucun traitement n'est n'est effectué dans l'espace utilisateur. La vérification de la signature est entièrement effectuée dans le noyau.

\========================================= SIGNATURES NON VALIDES ET MODULES NON SIGNÉS

Si CONFIG_MODULE_SIG_FORCE est activé ou si module.sig_enforce=1 est fournie sur la ligne de commande du noyau, le noyau ne chargera que les modules valides pour lesquels il dispose d'une clé publique. Sinon, il chargera également les modules non signés. Tout module pour lequel le noyau dispose d'une clé, mais dont la signature ne correspond pas, ne sera pas chargé. autorisé à être chargé.

Tout module dont la signature est indéchiffrable sera rejeté.

\========================================= ADMINISTRER/PROTÉGER LA CLÉ PRIVÉE

Comme la clé privée est utilisée pour signer les modules, les virus et les logiciels malveillants pourraient utiliser la clé privée pour signer des modules et compromettre le système d'exploitation. d'exploitation. La clé privée doit être soit détruite, soit déplacée dans un sécurisé et ne pas être conservée dans le nœud racine de l'arbre source du noyau.