Détecter la corruption de pile lors des appels à schedule()
Exige que le noyau soit compilé avec CONFIG_SCHED_STACK_END_CHECK=y afin que le canari de fin de pile soit vérifié à chaque appel de schedule().
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
Ceci garantit qu'aucun comportement erroné ne survient, qui pourrait entraîner une corruption de données ou un plantage sporadique ultérieur une fois la région examinée. CONFIG_SCHED_STACK_END_CHECK fait vérifier au noyau le canari en fin de pile noyau à chaque appel de schedule() ; une récursion profonde ou un exploit débordant la pile est détecté immédiatement par une panic, transformant un débordement de pile noyau silencieux (primitive de corruption exploitée par les attaquants) en une défaillance propre et contenue.
Ce que vérifie Pavois
Pavois lit les options de compilation du noyau en cours d'exécution, grep '^CONFIG_SCHED_STACK_END_CHECK=' /boot/config-$(uname -r) ou zcat /proc/config.gz, et exige y. Lire la configuration du noyau réellement démarré (indexée sur uname -r) reflète exactement le noyau démarré, ce qu'une supposition de nom de paquet ou un fichier générique ne peut faire.
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_SCHED_STACK_END_CHECK=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_SCHED_STACK_END_CHECK=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep '^CONFIG_SCHED_STACK_END_CHECK=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep CONFIG_SCHED_STACK_END_CHECK). Sortie attendue :
CONFIG_SCHED_STACK_END_CHECK=y
Inspecter et investiguer
Aucune entrée de journal courante. Quand le contrôle se déclenche, le noyau journalise Thread overran stack, or stack corrupted puis panique, visible dans dmesg / journalctl -k et tout vidage de plantage. Confirmez l'option de compilation avec grep CONFIG_SCHED_STACK_END_CHECK /boot/config-$(uname -r).
Remédiation
Il s'agit d'une option de compilation du noyau, Pavois ne fournit donc aucune étape de durcissement automatique. Elle est satisfaite en démarrant un noyau de distribution compilé avec CONFIG_SCHED_STACK_END_CHECK=y (le cas des noyaux durcis Debian/Ubuntu/RHEL actuels) ; un noyau personnalisé doit être recompilé.
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
En son absence, un débordement de pile noyau peut corrompre silencieusement la mémoire adjacente et être instrumentalisé pour une exploitation au lieu d'échouer proprement. Précautions : la vérification à chaque schedule() est extrêmement peu coûteuse et sans impact fonctionnel ; l'activer via un noyau conforme présente un faible risque. Le seul effet visible est que les vrais débordements de pile produisent désormais une panic immédiate plutôt qu'un comportement indéfini, résultat recherché. Aucune préoccupation de blocage particulière au-delà du changement de noyau habituel.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R15 | 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.