Activer la disposition aléatoire de l'espace d'adressage virtuel
Fixe kernel.randomize_va_space = 2 pour activer l'ASLR complète (pile, tas, mmap, VDSO et bibliothèques partagées randomisés).
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
La randomisation de l'espace d'adressage (ASLR) complique fortement la prédiction par un attaquant de l'emplacement du code d'attaque injecté dans l'espace d'adressage d'un processus, et la localisation du code existant à réutiliser via le Return-Oriented Programming (ROP). Fixer kernel.randomize_va_space = 2 active l'ASLR complète, randomisant la pile, le tas (brk), la base mmap, le VDSO et les bibliothèques partagées, augmentant nettement le coût des exploits de corruption mémoire.
Ce que vérifie Pavois
Pavois lit la valeur noyau en vigueur via kernel_parameter('kernel.randomize_va_space') (équivalent à sysctl kernel.randomize_va_space), et non une ligne de /etc/sysctl.d/*.conf. L'ASLR est souvent affaiblie par un kernel.randomize_va_space = 0 résiduel laissé par une session de débogage ou une image de conteneur de mauvaise qualité ; seule la lecture du paramètre effectif détecte que le noyau en cours a réellement la randomisation complète activée.
describe kernel_parameter('kernel.randomize_va_space') do
its('value') { should cmp 2 }
end
describe command("grep -hsE '^[[:space:]]*kernel.randomize_va_space[[:space:]]*=[[:space:]]*2([[:space:]]|$)' /etc/sysctl.conf /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf 2>/dev/null") do
its('stdout') { should match(/\S/) }
endComment vérifier qu’elle est appliquée
Exécutez sysctl kernel.randomize_va_space. Sortie attendue :
kernel.randomize_va_space = 2
Inspecter et investiguer
Aucune ligne de journal dédiée. Vérifiez via sysctl kernel.randomize_va_space. Vous pouvez constater l'ASLR à l'œuvre : exécuter cat /proc/self/maps deux fois doit montrer des adresses de base différentes pour la pile et les bibliothèques à chaque fois.
Remédiation
Le plan de durcissement de Pavois utilise la ressource sysctl pour fixer kernel.randomize_va_space = 2, le persiste dans un drop-in géré par Pavois sous /etc/sysctl.d/, et l'applique à chaud (sans redémarrage). Appliquez-le avec pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| key | kernel.randomize_va_space |
|---|---|
| resource | sysctl |
| value | 2 |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque si non appliqué : sans ASLR complète, les adresses mémoire sont prévisibles, rendant les exploits par débordement de tampon et ROP nettement plus fiables.
Précautions avant application :
- L'ASLR est activée par défaut et sûre pour la quasi-totalité des logiciels. Seules des charges de travail de niche qui figent ou épinglent des adresses virtuelles (certains JIT, émulateurs hérités, réglages HPC/bases de données, ou débogage avec randomisation désactivée) peuvent dysfonctionner ; testez ces applications.
- Aucun risque de blocage au démarrage ou à la connexion ; le changement est entièrement réversible à chaud.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R9 | direct | 2.0 | haute |
| CIS | 1.5.1, 3.3.1.1, 1.5.8 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.7, CM-6(a), SC-30, SC-30(2) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 3.3.1.1 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-22-213020, UBTU-24-700310 | direct | per OS STIG release | 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.