Configurer la mitigation Speculative Store Bypass
Impose le paramètre noyau spec_store_bypass_disable=on pour activer la mitigation processeur Speculative Store Bypass (SSB) sur l'ensemble du système.
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
Sur les processeurs vulnérables, un store transmis de manière spéculative peut être exploité via une attaque par canal auxiliaire sur le cache. Cela permet à un attaquant de lire de la mémoire qu'il ne devrait pas pouvoir atteindre directement, par exemple en exfiltrant des secrets depuis du code sandboxé ou compilé en JIT (Spectre variante 4 / CVE-2018-3639). Forcer spec_store_bypass_disable=on active la mitigation du noyau pour tout le système au lieu de la laisser au choix de chaque processus.
Ce que vérifie Pavois
Pavois lit la ligne de commande de démarrage effective depuis /proc/cmdline, qui reflète les arguments noyau réellement utilisés au boot. C'est supérieur à un grep dans /etc/default/grub ou grub.cfg : ces fichiers peuvent être modifiés sans régénération, surchargés par des drop-ins sous /etc/default/grub.d/, ou différer de ce que le chargeur d'amorçage a transmis. Seul /proc/cmdline prouve que la mitigation est active sur le boot courant.
describe command('cat /proc/cmdline') do
its('stdout') { should match(/(^| )spec_store_bypass_disable=on( |$)/) }
end
describe command("grep -hwsF 'spec_store_bypass_disable=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 spec_store_bypass_disable=on. Vous pouvez aussi contrôler l'état résolu du CPU avec cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass, qui doit indiquer une mitigation active plutôt que Vulnerable.
Inspecter et investiguer
Examinez le tampon noyau avec dmesg | grep -i 'speculative store bypass' ou journalctl -k | grep -i ssb pour voir comment le noyau signale la mitigation au démarrage. L'état en direct est exposé via l'entrée sysfs /sys/devices/system/cpu/vulnerabilities/spec_store_bypass.
Remédiation
Le plan de durcissement de Pavois utilise la ressource kernel_cmdline pour ajouter spec_store_bypass_disable=on à la configuration du chargeur d'amorçage et la régénérer. S'agissant d'un paramètre de démarrage, reboot_required est vrai, le changement ne prend effet 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 | spec_store_bypass_disable=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
Sans cette mitigation, l'hôte reste exposé aux attaques Speculative Store Bypass capables d'exfiltrer des secrets en mémoire. Son activation a un coût de performance mesurable mais généralement modéré sur les charges sensibles à la mémoire, et nécessite un redémarrage pour prendre effet. Précautions : planifiez le redémarrage dans une fenêtre de maintenance, vérifiez que le chargeur d'amorçage a bien été régénéré avant de redémarrer (grep spec_store_bypass /boot/grub*/grub.cfg ou grubby --info=ALL sous RHEL), et conservez un accès console/IPMI au cas où la nouvelle ligne de commande empêcherait un démarrage propre.
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.