Exiger que les modules soient valablement signés
Exige que le noyau en cours d'exécution soit compilé avec CONFIG_MODULE_SIG_FORCE=y afin qu'il rejette tout module non signé ou signé avec une clé non fiable.
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
CONFIG_MODULE_SIG rend seulement le noyau capable de vérifier les signatures ; sans CONFIG_MODULE_SIG_FORCE=y, il charge tout de même les modules non signés (il se contente de marquer le noyau comme « taint »). L'application stricte fait que le noyau refuse tout module non signé ou signé avec une clé inconnue, fermant la porte qu'un attaquant utiliserait sinon pour charger du code arbitraire en ring 0. C'est l'option qui transforme la signature des modules d'indicative en obligatoire.
Ce que vérifie Pavois
Pavois lit la configuration de compilation du noyau en cours d'exécution via /boot/config-$(uname -r) avec /proc/config.gz en repli, de sorte que le résultat reflète le noyau réellement démarré plutôt qu'un fichier statique. Pavois attend CONFIG_MODULE_SIG_FORCE=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_FORCE=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_MODULE_SIG_FORCE=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep '^CONFIG_MODULE_SIG_FORCE=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep '^CONFIG_MODULE_SIG_FORCE='). Sortie attendue : CONFIG_MODULE_SIG_FORCE=y.
Inspecter et investiguer
Consultez dmesg | grep -i module et journalctl -k pour les rejets comme Loading of unsigned module is rejected. Utilisez cat /proc/sys/kernel/tainted pour voir si un module non signé a marqué le noyau comme « taint » (bit 13, valeur 8192).
Remédiation
Aucune remédiation automatique : CONFIG_MODULE_SIG_FORCE est une option de compilation du noyau qui ne peut pas être basculée à l'exécution. Elle nécessite un noyau compilé avec l'application stricte (ou, sur un système Secure Boot avec le LSM lockdown, l'application stricte peut aussi être imposée en démarrant en mode lockdown=integrity/confidentiality). À 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
Sans application stricte, un attaquant capable de déposer un fichier de module peut exécuter du code dans le noyau sans être détecté. Le principal risque lors de l'activation est de casser des modules légitimes hors arbre : pilotes GPU propriétaires (NVIDIA), VirtualBox, modules construits par DKMS et certains outils de débogage noyau échoueront à se charger s'ils ne sont pas signés avec une clé de confiance. Avant d'appliquer la contrainte, signez chaque module nécessaire (ou enrôlez la clé via MOK sous Secure Boot), testez sur un démarrage hors production, et conservez un accès console/récupération afin qu'un échec de chargement ne vous prive pas du matériel requis.
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.