Activer la prise en charge du débogage SLUB
Exige un noyau compilé avec CONFIG_SLUB_DEBUG=y, activant les contrôles de détection de corruption de l'allocateur SLUB.
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_SLUB_DEBUG=y intègre les mécanismes de vérification de cohérence de l'allocateur SLUB : contrôles de redzone et de poison qui détectent la corruption du tas, ainsi que la validation de l'intégrité de la freelist. C'est le prérequis du durcissement à l'exécution (init_on_free/slub_debug) et il permet au noyau de détecter use-after-free et débordements au lieu de poursuivre silencieusement avec une mémoire corrompue. Les contrôles restent inactifs tant qu'ils ne sont pas demandés, d'où un coût minimal hors usage.
Ce que vérifie Pavois
Pavois lit la configuration de compilation du noyau en cours d'exécution via /boot/config-$(uname -r) ou /proc/config.gz et vérifie CONFIG_SLUB_DEBUG=y. Lire la config effective du noyau démarré prouve que le support de débogage est compilé dans le noyau utilisé, et pas seulement disponible dans une image installée.
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_SLUB_DEBUG=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_SLUB_DEBUG=y$/) }
endComment vérifier qu’elle est appliquée
grep '^CONFIG_SLUB_DEBUG=' /boot/config-$(uname -r) || zcat /proc/config.gz | grep '^CONFIG_SLUB_DEBUG='
Sortie attendue : CONFIG_SLUB_DEBUG=y. Pour voir si les contrôles sont actifs à l'exécution, inspectez la ligne de boot pour slub_debug= via cat /proc/cmdline.
Inspecter et investiguer
Lorsque le débogage SLUB détecte une corruption, il écrit des diagnostics dans le ring buffer noyau, examinez dmesg ou journalctl -k pour des messages comme Redzone overwritten, Poison overwritten ou Object already free. L'état par cache est visible sous /sys/kernel/slab/.
Remédiation
Aucune remédiation automatique n'est fournie : CONFIG_SLUB_DEBUG est une option noyau à la compilation, non activable à chaud. La correction consiste à démarrer un noyau compilé avec cette option, c'est déjà le cas des noyaux par défaut des OS pris en charge. Pour un noyau personnalisé, positionnez CONFIG_SLUB_DEBUG=y et reconstruisez.
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 CONFIG_SLUB_DEBUG, le noyau ne peut pas effectuer de contrôles de cohérence de l'allocateur et vous perdez la base du durcissement SLUB à l'exécution : la corruption du tas peut passer inaperçue. Précautions : activer l'option seule a un surcoût négligeable, les contrôles restant inactifs ; seul l'activation complète à l'exécution (slub_debug=FZP) a un coût mesurable, à réserver au débogage. Changer de noyau impose un redémarrage, planifiez une fenêtre de maintenance et gardez le noyau précédent dans GRUB en repli.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R17 | 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.