Activer l'empoisonnement des pages après libération
Exige que le noyau en cours d'exécution soit compilé avec CONFIG_PAGE_POISONING=y afin que les pages mémoire libérées soient écrasées, détruisant les données obsolètes.
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
Lorsqu'une mémoire est libérée, son contenu reste en RAM jusqu'à réutilisation. Si cette mémoire contenait auparavant des secrets (clés, mots de passe, jetons), un bug d'utilisation après libération ultérieur ou une nouvelle allocation lisant des données obsolètes peut les divulguer. CONFIG_PAGE_POISONING=y écrase les pages libérées avec un motif connu, de sorte que les données sensibles obsolètes sont détruites et que les conditions d'utilisation après libération sont plus faciles à détecter et plus difficiles à exploiter.
Ce que vérifie Pavois
Pavois lit la configuration de compilation du noyau en cours d'exécution via /boot/config-$(uname -r), avec repli sur /proc/config.gz, de sorte que le résultat reflète le noyau démarré. Pavois attend CONFIG_PAGE_POISONING=y.
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_PAGE_POISONING=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_PAGE_POISONING=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep '^CONFIG_PAGE_POISONING=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep '^CONFIG_PAGE_POISONING='). Sortie attendue : CONFIG_PAGE_POISONING=y. Sur de nombreux noyaux, l'empoisonnement est intégré mais conditionné par le paramètre de démarrage page_poison=1, vérifiez cat /proc/cmdline.
Inspecter et investiguer
Lorsqu'il est activé, le noyau journalise au démarrage des messages du style mem auto-init: stack:..., heap alloc:..., heap free:... ; consultez dmesg | grep -i poison et journalctl -k. Les bascules actives au démarrage apparaissent dans cat /proc/cmdline.
Remédiation
Aucune remédiation automatique : CONFIG_PAGE_POISONING est une option de compilation du noyau. Elle ne peut pas être activée à l'exécution, elle nécessite un noyau compilé avec l'option (et souvent le paramètre de ligne de commande page_poison=1 pour l'activer). Utilisez un noyau de distribution qui la fournit, ou recompilez. À appliquer manuellement ; pavois harden apply ne peut pas modifier un paramètre compilé en dur.
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 empoisonnement des pages, la mémoire libérée conserve des secrets obsolètes susceptibles de fuir via des bugs. L'activer a un coût en performance mesurable (chaque page libérée est réécrite), d'où l'existence de CONFIG_PAGE_POISONING_NO_SANITY et _ZERO pour l'ajuster. Précaution : sur des charges sensibles à la latence ou à fort débit, mesurez le surcoût avant un déploiement large, et préférez l'activation via page_poison=1 en ligne de commande afin de pouvoir revenir en arrière par un simple changement de paramètre de démarrage.
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.