Démapper le noyau lors de l'exécution en espace utilisateur (alias KAISER)
Exige que le noyau soit compilé avec CONFIG_UNMAP_KERNEL_AT_EL0=y, activant l'isolation des tables de pages KPTI/KAISER qui mitige Meltdown sur arm64.
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_UNMAP_KERNEL_AT_EL0 active la mitigation KPTI/KAISER sur arm64 : les tables de pages du noyau sont démappées pendant l'exécution au niveau d'exception 0 (espace utilisateur). Sans elle, un processus non privilégié peut exploiter l'attaque par canal auxiliaire Meltdown (CVE-2017-5754) pour lire la mémoire noyau, identifiants, clés et secrets d'autres processus, en franchissant la frontière utilisateur/noyau.
Ce que vérifie Pavois
Pavois lit la configuration de compilation du noyau en cours d'exécution, /boot/config-$(uname -r) ou /proc/config.gz, et exige CONFIG_UNMAP_KERNEL_AT_EL0=y. Cela reflète le noyau réellement démarré, et non un fichier de config pouvant décrire un noyau différent ou non installé : un scanner basé fichiers lisant un /boot/config-* obsolète pourrait passer alors que le noyau vivant n'a pas la mitigation.
only_if('arm64 only') { os.arch.to_s =~ /aarch64|arm/ }
describe command("grep -h '^CONFIG_UNMAP_KERNEL_AT_EL0=' /boot/config-$(uname -r) 2>/dev/null; zcat /proc/config.gz 2>/dev/null | grep '^CONFIG_UNMAP_KERNEL_AT_EL0='") do
its('stdout') { should match(/^CONFIG_UNMAP_KERNEL_AT_EL0=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep '^CONFIG_UNMAP_KERNEL_AT_EL0=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep CONFIG_UNMAP_KERNEL_AT_EL0). Sortie attendue : CONFIG_UNMAP_KERNEL_AT_EL0=y. Sur arm64, confirmez aussi l'état d'exécution avec cat /sys/devices/system/cpu/vulnerabilities/meltdown (attendu : Mitigation: PTI).
Inspecter et investiguer
Il n'y a pas de trace dans les journaux d'audit pour une option de compilation. Inspectez la vue du noyau démarré : dmesg | grep -i 'kpti\|meltdown\|unmap' et cat /sys/devices/system/cpu/vulnerabilities/meltdown indiquent si la mitigation est active à l'exécution.
Remédiation
Aucune remédiation automatique : remediation est vide car il s'agit d'une option de compilation du noyau non modifiable sur un système en marche. La correction passe par l'installation d'un noyau fournisseur compilé avec CONFIG_UNMAP_KERNEL_AT_EL0=y (tous les noyaux arm64 actuels Debian/Ubuntu/RHEL l'activent déjà). Appliquez-la manuellement en démarrant un noyau conforme, puis relancez le scan.
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
Échouer au contrôle signifie que la mitigation Meltdown est absente sur arm64 : la mémoire noyau est potentiellement lisible par tout processus local. Précautions avant de changer de noyau : KPTI/PTI ajoute un léger surcoût aux appels système / changements de contexte (généralement quelques pour cent), et changer de noyau peut affecter les modules hors arbre (GPU, stockage). Testez le nouveau noyau sur un hôte hors production, conservez l'entrée du noyau précédent dans le chargeur d'amorçage pour pouvoir revenir en arrière, et vérifiez le chargement des pilotes matériels avant de valider.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R27 | 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.