Imposer la mitigation Spectre v2
Impose le paramètre noyau spectre_v2=on pour appliquer la mitigation processeur Spectre v2 (injection de cible de branchement) la plus forte disponible.
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
La vulnérabilité Spectre v2 (injection de cible de branchement / CVE-2017-5715) permet à un attaquant d'orienter l'exécution spéculative du processeur pour lire de la mémoire à laquelle il ne devrait pas avoir accès, exfiltrant des secrets du noyau ou d'autres processus via un canal auxiliaire. Définir spectre_v2=on force la mitigation la plus forte disponible (retpolines / IBRS / IBPB) au lieu du mode auto par défaut du noyau, qui peut laisser des failles selon le microcode et le processeur.
Ce que vérifie Pavois
Pavois lit la ligne de commande de démarrage effective depuis /proc/cmdline, c'est-à-dire exactement ce avec quoi le noyau a démarré. Faire un grep dans /etc/default/grub ou grub.cfg n'est pas fiable : les modifications peuvent ne pas être régénérées, des drop-ins sous /etc/default/grub.d/ peuvent les surcharger, et le fichier peut ne pas correspondre à l'entrée réelle du chargeur d'amorçage. Seul /proc/cmdline prouve que la mitigation est appliquée sur ce boot.
describe command('cat /proc/cmdline') do
its('stdout') { should match(/(^| )spectre_v2=on( |$)/) }
end
describe command("grep -hwsF 'spectre_v2=on' /etc/default/grub /etc/kernel/cmdline /boot/grub/grub.cfg /boot/grub2/grub.cfg /boot/efi/EFI/*/grub.cfg 2>/dev/null") do
its('stdout') { should match(/\S/) }
endComment vérifier qu’elle est appliquée
Exécutez cat /proc/cmdline et vérifiez la présence de spectre_v2=on. Recoupez avec l'état en direct du CPU via cat /sys/devices/system/cpu/vulnerabilities/spectre_v2, qui doit indiquer une mitigation (par ex. Mitigation: Retpolines) plutôt que Vulnerable.
Inspecter et investiguer
Utilisez dmesg | grep -i spectre ou journalctl -k | grep -i spectre pour voir le rapport du noyau au démarrage sur la mitigation choisie. L'état résolu est exposé en continu via l'entrée sysfs /sys/devices/system/cpu/vulnerabilities/spectre_v2.
Remédiation
Le plan de durcissement de Pavois utilise la ressource kernel_cmdline pour ajouter spectre_v2=on à la configuration du chargeur d'amorçage et la régénérer. En tant que paramètre de démarrage, reboot_required est vrai et le changement ne s'applique qu'au prochain redémarrage. Appliquez-le avec pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| param | spectre_v2=on |
|---|---|
| reboot_required | true |
| resource | kernel_cmdline |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Laisser Spectre v2 sans mitigation expose l'hôte à une divulgation de mémoire entre niveaux de privilège. Forcer spectre_v2=on peut entraîner une pénalité de performance notable sur les charges intensives en appels système et changements de contexte (retpolines/IBRS), et nécessite un redémarrage. Précautions : mesurez d'abord les services sensibles à la performance, planifiez le redémarrage dans une fenêtre de maintenance, confirmez la régénération du chargeur d'amorçage (grubby --info=ALL sous RHEL ou inspection de grub.cfg) et conservez un accès console/IPMI au cas où le système ne démarrerait pas correctement.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R8 | 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.