Tout ce dont vous avez besoin est décrit ici
INSTALLATION DE SIGNATURE DU MODULE KERNEL
CONTENU
- Aperçu.
- Configuration de la signature du module.
- Génération de clés de signature.
- Clés publiques dans le noyau.
- Modules de signature manuelle.
- Modules signés et décapage.
- Chargement des modules signés.
- Signatures non valides et modules non signés.
- Administrer / protéger la clé privée.
APERÇU
La fonction de signature des modules du noyau signe cryptographiquement les modules pendant 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 afin qu'il ne soit pas nécessaire d'avoir des bits de l'espace utilisateur de confiance.
Cette fonction utilise des certificats standard X.509 UIT-T pour coder les clés publiques concernées. Les signatures ne sont elles-mêmes encodées dans aucun type de norme industrielle. L'installation ne prend actuellement en charge que la norme de chiffrement à clé publique RSA (bien qu'elle soit enfichable et permette l'utilisation d'autres). Les algorithmes de hachage possibles qui peuvent ê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).
CONFIGURER LA SIGNATURE DU MODULE
La fonction de signature de module est activée en accédant à la section «Activer la prise en charge du module chargeable» de la configuration du noyau et en activant
CONFIG_MODULE_SIG "Module signature verification"
Cela a un certain nombre d'options disponibles:
"Exiger que les modules soient valablement signés" (CONFIG_MODULE_SIG_FORCE)
Ceci spécifie comment le noyau doit traiter un module qui a une signature pour laquelle la clé n'est pas connue ou un module qui n'est pas signé.
Si cette option est désactivée (c'est-à-dire "permissive"), alors les modules pour lesquels la clé n'est pas disponible et les modules qui ne sont pas signés sont autorisés, mais le noyau sera marqué comme étant corrompu, et les modules concernés seront marqués comme corrompus, affichés avec le caractère «E».
Si cette option est activée (c'est-à-dire "restrictive"), seuls les modules ayant une signature valide qui peut être vérifiée par une clé publique en possession du noyau seront chargés. Tous les autres modules généreront une erreur.
Quel que soit le réglage ici, si le module a un bloc de signature qui ne peut pas être analysé, il sera rejeté d'emblée.
"Signer automatiquement tous les modules" (CONFIG_MODULE_SIG_ALL)
Si cette option est activée, les modules seront automatiquement signés lors de la phase modules_install d'une build. Si cette option est désactivée, les modules doivent être signés manuellement à l'aide de:
scripts/sign-file
"Avec quel algorithme de hachage les modules doivent-ils être signés?"
Cela présente un choix de l'algorithme de hachage dans lequel la phase d'installation signera les modules avec:
CONFIG_MODULE_SIG_SHA1 "Sign modules with SHA-1"
CONFIG_MODULE_SIG_SHA224 "Sign modules with SHA-224"
CONFIG_MODULE_SIG_SHA256 "Sign modules with SHA-256"
CONFIG_MODULE_SIG_SHA384 "Sign modules with SHA-384"
CONFIG_MODULE_SIG_SHA512 "Sign modules with SHA-512"
L'algorithme sélectionné ici sera également intégré au noyau (plutôt que d'être un module) afin que les modules signés avec cet algorithme puissent voir leurs signatures vérifiées sans provoquer de boucle de dépendance.
"Nom de fichier ou URI PKCS # 11 de la clé de signature du module" (CONFIG_MODULE_SIG_KEY)
Définir cette option sur autre chose que sa valeur par défaut "certs / signature_key.pem" désactivera la génération automatique des clés de signature et permettra aux modules du noyau d'être signés avec une clé de votre choix. La chaîne fournie doit identifier un fichier contenant à la fois une clé privée et son certificat X.509 correspondant sous forme PEM, ou - sur les systèmes où OpenSSL ENGINE_pkcs11 est fonctionnel - un URI PKCS # 11 tel que défini par RFC7512. Dans ce dernier cas, l'URI PKCS # 11 doit référencer à la fois un certificat et une clé privée.
Si le fichier PEM contenant la clé privée est chiffré, ou si le jeton PKCS # 11 requiert un code PIN, celui-ci peut être fourni au moment de la construction au moyen de la variable KBUILD_SIGN_PIN.
"Clés X.509 supplémentaires pour le trousseau de clés système par défaut" (CONFIG_SYSTEM_TRUSTED_KEYS)
Cette option peut être définie sur le nom de fichier d'un fichier encodé PEM contenant des certificats supplémentaires qui seront inclus par défaut dans le trousseau de clés système.
Notez que l'activation de la signature de module ajoute une dépendance des packages de développement OpenSSL aux processus de génération du noyau pour l'outil qui effectue la signature.
GÉNÉRATION DE CLÉS DE SIGNATURE
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 génération, après quoi elle peut être supprimée ou stockée en toute sécurité. 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 inchangé par rapport à sa valeur par défaut, la génération du noyau générera automatiquement une nouvelle paire de clés à l'aide d'openssl s'il n'y en a pas dans le fichier:
certs/signing_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
(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 = Unspecified company
CN = Build time autogenerated kernel key
#emailAddress = unspecified.user@unspecified.company
La taille de 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és privés / publics à l'aide du fichier de configuration de génération de clés x509.genkey 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 -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \
-config x509.genkey -outform PEM -out kernel_key.pem \
-keyout kernel_key.pem
Le chemin d'accès complet pour le fichier kernel_key.pem résultant peut ensuite ê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 générée automatiquement.
CLÉS PUBLIQUES DANS LE KERNEL
Le noyau contient un anneau de clés publiques qui peuvent être visualisées par root. Ils se trouvent dans un trousseau de clés appelé ".system_keyring" qui peut être vu par:
[root@deneb ~]# cat /proc/keys
...
223c7853 I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1
302d2d52 I------ 1 perm 1f010000 0 0 asymmetri Fedora kernel signing key: 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 des clés publiques d'une quincaillerie et les ajouter également (par exemple 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 <my_public_key.x509
Notez, cependant, que le noyau ne permettra d'ajouter des clés à .system_keyring que si l'encapsuleur X.509 de la nouvelle clé est valablement signé par une clé qui réside déjà dans le .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 l'arborescence des sources du noyau Linux. Le script nécessite 4 arguments:
1. The hash algorithm (e.g., sha256)
2. The private key filename or PKCS#11 URI
3. The public key filename
4. The kernel module to be signed
Voici un exemple pour signer un module du 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 l'algorithme de hachage est intégré au noyau ou peut être chargé sans nécessiter lui-même.
Si la clé privée nécessite une phrase secrète ou un code PIN, elle peut être fournie dans la variable d'environnement $ KBUILD_SIGN_PIN.
MODULES SIGNÉS ET DÉCAPAGE
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 qu'une signature est présente 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. Ainsi, ils NE PEUVENT PAS être supprimés une fois la signature calculée et attachée. Notez que l'ensemble du module est la charge utile 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 car aucun traitement n'est effectué dans l'espace utilisateur. La vérification de 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 forcemodulesig = 1 est fourni sur la ligne de commande du noyau, le noyau chargera uniquement les modules signés valablement pour lesquels il possède une clé publique. Sinon, il chargera également les modules non signés. Tout 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 ayant une signature non analysable sera rejeté.
ADMINISTRER / PROTÉGER LA CLÉ PRIVÉE
É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 non conservée dans le nœud racine de l'arborescence source du noyau.