Activer l'empoisonnement de l'allocateur SLUB/SLAB
Exige le paramètre de démarrage noyau slub_debug=P afin que l'allocateur SLUB empoisonne les objets libérés, détectant les use-after-free et effaçant les données résiduelles.
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
slub_debug=P active l'empoisonnement des objets de l'allocateur SLUB : un motif connu est écrit dans les objets au moment de leur libération, si bien que toute lecture ou écriture sur un objet après sa libération (ou avant sa réinitialisation) est détectée et empêchée. Cela neutralise de nombreuses vulnérabilités use-after-free à faible coût de performance, et efface les données sensibles restées dans les objets libérés afin qu'elles ne fuient pas vers l'allocation suivante. Le drapeau P n'active que l'empoisonnement (et non la suite de débogage complète, plus coûteuse).
Ce que vérifie Pavois
Pavois lit la ligne de commande noyau active depuis /proc/cmdline et vérifie la présence de slub_debug=P. C'est la ligne de boot analysée par le noyau, et non /etc/default/grub, une modification GRUB jamais régénérée passerait à tort un scan fichier alors que l'empoisonnement d'objets reste désactivé à l'exécution. L'état par cache est visible sous /sys/kernel/slab/*/.
describe command('cat /proc/cmdline') do
its('stdout') { should match(/(^| )slub_debug=P( |$)/) }
end
describe command("grep -hwsF 'slub_debug=P' /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
Lancez cat /proc/cmdline et confirmez la présence de slub_debug=P. Vous pouvez confirmer que l'empoisonnement est actif sur un cache en lisant son attribut sysfs, par ex. :
cat /sys/kernel/slab/kmalloc-64/poison
La sortie attendue est 1.
Inspecter et investiguer
Une violation d'empoisonnement/redzone est rapportée dans le ring buffer noyau comme un message de corruption SLUB, inspectez dmesg | grep -iE 'slab|slub|poison' ou journalctl -k | grep -iE 'slub|poison'. L'état par cache se trouve sous /sys/kernel/slab/.
Remédiation
pavois harden apply utilise la ressource kernel_cmdline pour ajouter slub_debug=P à la configuration du bootloader et la régénérer, afin que l'option soit présente au prochain démarrage. Un redémarrage est requis pour qu'il prenne effet.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| param | slub_debug=P |
|---|---|
| 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
L'empoisonnement d'objets ajoute un faible coût CPU pour l'écrasement/vérification à l'allocation et à la libération, et désactive la fusion des caches slab (le drapeau P implique un débogage par cache), augmentant légèrement l'usage mémoire noyau. Précautions :
- Sur des charges à fort renouvellement mémoire ou critiques en latence, mesurez pour confirmer que le surcoût est acceptable.
- Il peut révéler des pilotes bogués préexistants touchant la mémoire libérée en déclenchant des rapports de corruption, validez d'abord sur un nœud non critique.
- S'applique uniquement après redémarrage, planifiez une fenêtre de maintenance.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R8 | direct | 2.0 | haute |
| NIST | CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
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.