Avertir sur les mappages W+X détectés au démarrage
Exige que le noyau soit compilé avec CONFIG_DEBUG_WX=y, qui avertit au démarrage lorsqu'une page mémoire est mappée à la fois en écriture et en exécution.
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
Utile pour découvrir les cas où le noyau laisse des mappages W+X après application de NX, ces mappages constituant un risque de sécurité. Notez que même si le contrôle échoue, votre noyau peut rester sain : les mappages W+X ne sont pas une faille en soi, mais ils facilitent l'exploitation d'autres bogues noyau non corrigés.
Ce que vérifie Pavois
Pavois lit le drapeau de compilation effectif du noyau en cours d'exécution via /boot/config-$(uname -r) ou /proc/config.gz, indexé sur $(uname -r) : il reflète l'image réellement démarrée plutôt qu'un .config égaré qu'un scan à chemin fixe pourrait capter.
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_WX=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_DEBUG_WX=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep '^CONFIG_DEBUG_WX=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep '^CONFIG_DEBUG_WX='). Sortie attendue : CONFIG_DEBUG_WX=y. Absente ou # CONFIG_DEBUG_WX is not set est un échec.
Inspecter et investiguer
Au démarrage, si des mappages W+X subsistent, le noyau imprime un décompte et des détails dans le ring buffer : dmesg | grep -i 'W+X\|wx' ou journalctl -k | grep -i 'W+X'. Un système sain affiche Checked W+X mappings: passed. Confirmez le drapeau avec zcat /proc/config.gz | grep DEBUG_WX.
Remédiation
Aucune remédiation automatisée n'est fournie : une option de compilation du noyau ne se règle pas en éditant un fichier. Appliquez-la manuellement en installant et démarrant un noyau compilé avec CONFIG_DEBUG_WX=y.
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
Une page à la fois inscriptible et exécutable (W+X) permet à un attaquant capable d'y écrire d'exécuter ensuite ces données comme du code, la base de nombreuses techniques d'exploitation. Un noyau correctement durci applique W^X (écriture OU exécution exclusivement) afin qu'aucune page ne soit les deux. CONFIG_DEBUG_WX ne supprime pas à lui seul les pages W+X ; il les détecte et les signale au démarrage pour que les violations résiduelles soient repérées. Son absence signifie que les régressions W+X passent inaperçues, affaiblissant la défense contre l'injection de code. C'est une option à la compilation, posée uniquement en démarrant un noyau compilé avec. Précautions : les noyaux standard peuvent ne pas l'activer ; passer à un noyau durci change l'ABI des modules, donc vérifiez le chargement de tous les pilotes et examinez dmesg pour de nouveaux avertissements W+X (certains modules hors-arbre les déclenchent légitimement) avant de considérer la production saine. Aucun risque de redémarrage au-delà d'un échange de noyau classique.
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.