Durcir les métadonnées de la freelist du slab
Exige un noyau compilé avec CONFIG_SLAB_FREELIST_HARDENED=y, qui obfusque et valide les pointeurs de freelist du slab.
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
De nombreux exploits du tas noyau ciblent les métadonnées des caches slab. CONFIG_SLAB_FREELIST_HARDENED=y obfusque les pointeurs de freelist de l'allocateur slab (XOR avec un secret par cache et l'adresse du pointeur) et ajoute des contrôles de cohérence : un attaquant corrompant un objet libéré ne peut plus forger de façon fiable un pointeur de freelist pour rediriger les allocations vers une adresse arbitraire. Le coût est un léger surcoût de performance.
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_SLAB_FREELIST_HARDENED=y. Lire la config effective du noyau actif, et non un fichier empaqueté ou par défaut, prouve que le durcissement est réellement compilé dans le noyau qui a démarré, et pas seulement présent dans une image installée mais non démarré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_SLAB_FREELIST_HARDENED=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_SLAB_FREELIST_HARDENED=y$/) }
endComment vérifier qu’elle est appliquée
grep '^CONFIG_SLAB_FREELIST_HARDENED=' /boot/config-$(uname -r) || zcat /proc/config.gz | grep '^CONFIG_SLAB_FREELIST_HARDENED='
Sortie attendue : CONFIG_SLAB_FREELIST_HARDENED=y.
Inspecter et investiguer
Il s'agit d'une protection statique à la compilation, sans flux de journal dédié. Lorsque le durcissement détecte une corruption, il déclenche un panic ou un BUG noyau ; examinez dmesg ou journalctl -k pour les messages de corruption slab/freelist. Confirmez l'option avec la commande grep ci-dessus.
Remédiation
Aucune remédiation automatique n'est fournie : CONFIG_SLAB_FREELIST_HARDENED est une option noyau à la compilation, non modifiable à 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. Si vous compilez un noyau personnalisé, positionnez CONFIG_SLAB_FREELIST_HARDENED=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
Laisser cette option désactivée facilite grandement l'exploitation du slab/tas, car les pointeurs de freelist peuvent être forgés de façon prévisible. Précautions : le seul remède est un changement de noyau, qui impose un redémarrage, planifiez une fenêtre de maintenance et gardez le noyau précédent dans GRUB en repli. Le surcoût à l'exécution est faible (quelques pour cent sur les charges très allocatrices) ; mesurez les services sensibles à la latence le cas échéant, mais pour la quasi-totalité des systèmes le gain de sécurité le justifie.
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.