Activer les vérifications sur la manipulation des listes chaînées
Garantit que le noyau en cours d'exécution est compilé avec CONFIG_DEBUG_LIST=y, ajoutant des vérifications à la manipulation des listes chaînées qui détectent la corruption avant qu'elle ne soit exploitable.
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_DEBUG_LIST=y ajoute des vérifications d'intégrité aux opérations sur les listes chaînées intrusives du noyau (list_add, list_del, …), validant les pointeurs prev/next avant chaque manipulation. La corruption de liste chaînée, souvent via des conditions de course ou des use-after-free, est une primitive d'exploitation classique : un écrasement façonné des pointeurs de liste peut donner à un attaquant une écriture arbitraire. Ces vérifications détectent l'incohérence et abandonnent l'opération (empêchant par ex. des exploits comme la course de corruption de liste CVE-2017-1661), transformant une primitive d'écriture potentielle en un échec sûr.
Ce que vérifie Pavois
Pavois lit la config de compilation du noyau en cours d'exécution via /boot/config-$(uname -r) (repli /proc/config.gz) et vérifie CONFIG_DEBUG_LIST=y. S'indexer sur uname -r correspond à l'image exacte démarrée, plus fiable que lire un /boot/config-* quelconque. Cette option sous-tend CONFIG_BUG_ON_DATA_CORRUPTION, qui fait escalader une corruption de liste détectée en un BUG() ferme.
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_DEBUG_LIST=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_DEBUG_LIST=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep -h '^CONFIG_DEBUG_LIST=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep DEBUG_LIST). Attendu : CONFIG_DEBUG_LIST=y.
Inspecter et investiguer
Option de compilation statique du noyau, sans journal dédié. Inspectez avec zcat /proc/config.gz | grep DEBUG_LIST ou grep DEBUG_LIST /boot/config-$(uname -r). Lorsqu'une vérification de corruption de liste se déclenche à l'exécution, l'avertissement/oops avec trace apparaît dans dmesg et journalctl -k.
Remédiation
Aucune remédiation automatisée n'est fournie : c'est une option de compilation du noyau. Appliquez-la en démarrant un noyau compilé avec CONFIG_DEBUG_LIST=y (un noyau durci ou orienté sécurité), ou recompilez le noyau. pavois harden apply ne peut pas la modifier.
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
Risque si désactivé : la corruption de liste chaînée, voie courante vers une écriture noyau arbitraire, passe inaperçue et peut être exploitée pour une élévation de privilèges.
Précautions avant de modifier : les vérifications ajoutent un léger surcoût par opération mais aucun risque fonctionnel, et la plupart des noyaux de distribution les activent déjà. Changer de noyau nécessite un redémarrage ; conservez le noyau précédent dans GRUB en repli et validez le démarrage sur une console.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R16 | 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.