Randomiser les sections mémoire du noyau
Exige que le noyau soit compilé avec CONFIG_RANDOMIZE_MEMORY=y afin que le mapping de la mémoire physique ainsi que les régions vmalloc et vmemmap soient placés à des adresses virtuelles randomisées.
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
Cette fonctionnalité de sécurité rend les exploits reposant sur des emplacements mémoire prévisibles moins fiables. CONFIG_RANDOMIZE_MEMORY étend KASLR aux régions du mapping de la mémoire physique, vmalloc et vmemmap : même si un attaquant découvre la base de l'image du noyau, il ne peut toujours pas prédire où se trouvent le direct map et les tables de pages, fermant ainsi une classe d'attaques ciblant ces régions fixes.
Ce que vérifie Pavois
Pavois lit les options de compilation du noyau en cours d'exécution, grep '^CONFIG_RANDOMIZE_MEMORY=' /boot/config-$(uname -r) ou zcat /proc/config.gz, et exige la valeur y. Lire la configuration du noyau réellement démarré (indexée sur uname -r) reflète exactement le noyau démarré, y compris les compilations éditeur ou personnalisées, ce qu'une heuristique de nom de paquet ou un fichier générique ne peut garantir.
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_RANDOMIZE_MEMORY=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_RANDOMIZE_MEMORY=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep '^CONFIG_RANDOMIZE_MEMORY=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep CONFIG_RANDOMIZE_MEMORY). Sortie attendue :
CONFIG_RANDOMIZE_MEMORY=y
Inspecter et investiguer
Il n'y a pas d'entrée de journal dédiée. Confirmez le réglage via grep CONFIG_RANDOMIZE_MEMORY /boot/config-$(uname -r) et vérifiez cat /proc/cmdline, nokaslr désactive à la fois la randomisation de la base et de la mémoire même si l'option est compilée.
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_RANDOMIZE_MEMORY=y (vrai pour tous les noyaux x86-64 Debian/Ubuntu/RHEL actuels) et en s'assurant que nokaslr est absent des paramètres de démarrage ; 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, le map physique et les régions de tables de pages du noyau se trouvent à des adresses prévisibles, aidant les attaquants à transformer des fuites en exploits fiables. Précautions : cette option est groupée avec KASLR dans les noyaux standards et présente un faible risque à l'activation. Les mêmes réserves que pour KASLR s'appliquent, pilotes hors arbre rares, flux kexec/hibernation ou débogueurs supposant des adresses fixes peuvent nécessiter un test sur un hôte hors production avant déploiement.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R25 | 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.