Activer la vérification de signature des modules
Exige que le noyau en cours d'exécution soit compilé avec CONFIG_MODULE_SIG=y afin de pouvoir vérifier les signatures cryptographiques des modules chargeables.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
Sans CONFIG_MODULE_SIG=y, le noyau accepte n'importe quel module .ko quelle que soit son origine. Un attaquant capable de charger un module (root, un chemin setuid vulnérable, ou une substitution d'un fichier de module via la supply chain) peut injecter du code arbitraire directement en ring 0, contournant toutes les protections de l'espace utilisateur. La signature des modules force le noyau à vérifier cryptographiquement chaque module avec une clé de confiance, de sorte que seuls les modules construits et signés par une partie de confiance peuvent être chargés.
Ce que vérifie Pavois
Pavois lit la configuration de compilation du noyau en cours d'exécution, /boot/config-$(uname -r) et, en repli, /proc/config.gz exposé par le noyau actif. Utiliser uname -r et /proc/config.gz lie le contrôle au noyau réellement démarré, et non à un fichier de configuration qui pourrait décrire un noyau différent ou futur. Pavois attend CONFIG_MODULE_SIG=y.
describe command("C=/boot/config-$(uname -r); if [ -r \"$C\" ]; then cat \"$C\"; elif zcat /proc/config.gz 2>/dev/null | head -1 | grep -q .; then zcat /proc/config.gz; else echo PAVOIS_NO_KERNEL_CONFIG; fi | grep -E '^(CONFIG_MODULE_SIG=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_MODULE_SIG=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep '^CONFIG_MODULE_SIG=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep '^CONFIG_MODULE_SIG='). Sortie attendue : CONFIG_MODULE_SIG=y.
Inspecter et investiguer
L'activité des modules noyau est visible via dmesg | grep -i module et journalctl -k. Un module non signé rejeté produit des messages comme Loading of unsigned module is rejected. Listez les modules chargés avec lsmod.
Remédiation
Aucune remédiation automatique n'est disponible : il s'agit d'une option de compilation du noyau. Elle ne peut pas être basculée à l'exécution, elle nécessite un noyau compilé avec CONFIG_MODULE_SIG=y. Utilisez un noyau de distribution qui fournit déjà des modules signés (la plupart le font), ou recompilez le noyau avec cette option. À appliquer manuellement ; pavois harden apply ne peut pas modifier un paramètre compilé en dur.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| resource | kernel_build |
|---|
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
En l'absence de ce paramètre, le noyau chargera des modules malveillants ou altérés sans broncher, donnant à un attaquant un contrôle complet en ring 0. Précautions avant modification : activer l'application stricte de la signature (CONFIG_MODULE_SIG_FORCE) sur un système comportant des modules tiers hors arbre (pilotes GPU propriétaires, VirtualBox, DKMS) peut empêcher le chargement de ces modules et casser le matériel ou le démarrage. Vérifiez que tous les modules requis sont signés par une clé de confiance avant d'appliquer la contrainte, et conservez un accès console au cas où un module ne se chargerait pas.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R18 | direct | 2.0 | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.