Comment installer le module module.ko sans la signature du noyau ou la reconstruction du noyau dans Ubuntu 16.04?
Comment puis-je installer n’importe quel module dans Ubuntu 16.04 sans signer ni modifier aucune configuration du noyau? C'est possible? Toute aide serait appréciée.
Vous pouvez 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 ==============================CONTENU
- Vue d'ensemble.
- Configuration de la signature du module.
- Génération de clés de signature.
- Clés publiques dans le noyau.
- Signature manuelle des modules.
- Modules signés et décapage.
- Chargement des modules signés.
- Signatures non valides et modules non signés.
- Administration/protection de la clé privée.
======== APERÇU
La fonction de signature de module de noyau signe de manière cryptographique les modules lors de l'installation, puis vérifie la signature lors du chargement du module. Cela permet une sécurité accrue du noyau en interdisant le chargement de modules non signés ou de modules signés avec une clé non valide. La signature de module 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 effectuée par le noyau, de sorte qu'il n'est pas nécessaire de disposer de bits d'espaces utilisateur de confiance.
Cette fonction utilise les certificats standard X.509 ITU-T pour coder les clés publiques impliquées. Les signatures ne sont elles-mêmes encodées dans aucun type de norme industrielle. Actuellement, l’installation ne prend en charge que la norme de cryptage à clé publique RSA (bien qu’elle soit connectable et permette l’utilisation d’autres). Les algorithmes de hachage possibles pouvant être utilisés sont SHA-1, SHA-224, SHA-256, SHA-384 et SHA-512 (l'algorithme est sélectionné par les données de la signature).
========================== CONFIGURATION DE LA SIGNATURE DE MODULE
La fonction de signature de module est activée en accédant à la section "Activer la prise en charge des modules chargeables" de la configuration du noyau et en l'activant.
CONFIG_MODULE_SIG "Vérification de la signature du module"
Cela a un certain nombre d'options disponibles:
(1) "Exiger que les modules soient validement 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-signe
(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 "Modules de signature avec SHA-1" CONFIG_MODULE_SIG_SHA224 "Modules de connexion avec SHA-224" CONFIG_MODULE_SIG_SHA256 "Modules de signature avec SHA-256" CONFIG_MODULE_SIG_SHA_SHA384 "
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 adresse URI PKCS # 11 de la clé de signature de 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 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 aux packages de développement OpenSSL aux processus de construction du noyau pour l'outil qui effectue la signature.
======================= GÉNÉRER DES CLÉS DE SIGNALISATION
Des 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 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 de manière sécurisée. La clé publique est intégrée au noyau afin de pouvoir être utilisée pour vérifier les signatures lors du chargement des modules.
Dans des conditions normales, lorsque CONFIG_MODULE_SIG_KEY est identique à celle par défaut, la construction du noyau génère automatiquement une nouvelle paire de clés à l'aide de openssl s'il n'en existe pas dans le fichier:
certs/signature_key.pem
lors de la construction de vmlinux (la partie publique de la clé doit être intégrée à vmlinux) en utilisant des paramètres dans:
certs/x509.genkey
fichier (qui est également généré s'il n'existe pas déjà).
Il est fortement recommandé de fournir votre propre fichier x509.genkey.
En particulier, dans le fichier x509.genkey, la section req_distinguished_name devrait être modifiée par rapport à la valeur par défaut:
[req_distinguished_name] #O = Société non spécifiée CN = Clé de noyau générée automatiquement au moment de la construction #emailAddress = [email protected]
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 clé privé/public à l'aide du fichier de configuration de génération de clé x509.genkey situé dans le nœud racine de l'arborescence des sources du noyau Linux et de la commande openssl. Voici un exemple pour générer les fichiers de clé publique/privée:
openssl req -nouveaux -nodes -utf8 -sha256-jours 36500 -batch -x509\-config x509.genkey -outform PEM -out clé_kernel.pem\-keyout clé_kernel_pile.pem
Le chemin complet du fichier kernel_key.pem résultant peut ensuite être spécifié dans l'option CONFIG_MODULE_SIG_KEY. Le certificat et la clé y figurant seront utilisés à la place d'une paire de clés générée automatiquement.
========================== CLEFS PUBLIQUES DANS LE KERNEL
Le noyau contient un anneau de clés publiques pouvant être visualisées par root. Ils sont dans un trousseau appelé ".system_keyring" qui peut être vu par:
[root @ deneb ~] # cat/proc/keys ... 223c7853 I ------ 1 perm 1f030000 0 0 trousseau de clés .system_keyring: 1 302d2d52 I ------
1 perm 1f010000 0 0 clé de signature du noyau Fedora asymétrique: d69a84e6bce3d216b979e9505b3e9ef7a7118079: 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 des clés publiques provenant d'un magasin de 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 effectuant:
keyctl padd asymétrique "" [.system_keyring-ID] <[fichier-clé]
par exemple.:
keyctl padd asymétrique "" 0x223c7853
Notez cependant que le noyau ne permettra que les clés soient ajoutées à .system_keyring si le wrapper X.509 de la nouvelle clé est valablement signé par une clé qui réside déjà dans .system_keyring au moment de l’ajout de la clé.
========================== SIGNING MANUELLEMENT DES MODULES
Pour signer manuellement un module, utilisez l'outil scripts/sign-file disponible dans l'arborescence des sources du noyau Linux. Le script nécessite 4 arguments:
- L'algorithme de hachage (par exemple, sha256)
- Le nom de fichier de la clé privée ou l'URI PKCS # 11
- Le nom de la clé publique
- 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 configuré, mais s'il ne le fait pas, vous devez vous assurer que cet algorithme est intégré au noyau ou peut être chargé sans être requis.
Si la clé privée nécessite une phrase secrète ou un code confidentiel, vous pouvez l'indiquer dans la variable d'environnement $ KBUILD_SIGN_PIN.
============================= MODULES SIGNÉS ET STRIPPING
Un module signé a une signature numérique simplement ajoutée à la fin. La chaîne "~ Signature du module ajoutée ~." à la fin du fichier du module confirme la présence d'une signature mais ne confirme pas la validité de la signature!
Les modules signés sont BRITTLE car la signature est en dehors du conteneur ELF défini. Ainsi, ils NE PEUVENT PAS être enlevés une fois que la signature est calculée et jointe. Notez que l'ensemble du module correspond à la charge signée, y compris toutes les informations de débogage présentes au moment de la 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, aucun traitement n'étant 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 fourni sur la ligne de commande du noyau, le noyau ne chargera que les modules signés valablement pour lesquels il possède une clé publique. Sinon, les modules non signés seront également chargés. Aucun module pour lequel le noyau a une clé, mais qui s'avère avoir une incompatibilité de signature ne sera pas autorisé à charger.
Tout module comportant une signature non analysable sera rejeté.
======================================= ADMINISTRER/PROTEGER LA CLE PRIVEE
Étant donné que la clé privée est utilisée pour signer des modules, les virus et les logiciels malveillants pourraient utiliser la clé privée pour signer des modules et compromettre le système d'exploitation. La clé privée doit être détruite ou déplacée vers un emplacement sécurisé et ne pas être conservée dans le nœud racine de l'arborescence source du noyau.
Ubuntu 16.04 prend en charge pci_set_dma_mask au lieu de pci_dma_supported pour la construction de pilotes PCI. Une mauvaise utilisation de l'API imprimera une erreur d'incompatibilité de clé d'amorçage sécurisée lors du chargement du pilote.