Restreindre l'exposition des adresses de pointeurs noyau
Fixe kernel.kptr_restrict = 2 afin que les adresses de pointeurs noyau soient masquées (affichées en 0) pour tous les utilisateurs, y compris ceux disposant de CAP_SYSLOG.
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
L'exposition des pointeurs noyau (via procfs ou seq_printf()) divulgue les adresses de structures noyau modifiables, susceptibles de contenir des pointeurs de fonction. Si une vulnérabilité d'écriture dans le noyau permet d'altérer l'une de ces structures, les adresses divulguées rendent la compromission fiable bien plus facile (en mettant en échec KASLR). Fixer kptr_restrict = 2 remplace par 0 les pointeurs noyau affichés par ces interfaces pour tous les utilisateurs, indépendamment de CAP_SYSLOG.
Ce que vérifie Pavois
Pavois lit la valeur noyau en vigueur via kernel_parameter('kernel.kptr_restrict') (équivalent à sysctl kernel.kptr_restrict), et non une ligne de /etc/sysctl.conf ou /etc/sysctl.d/*.conf. Un fichier peut déclarer 2 alors que le noyau en cours est encore à 0 ou 1, parce qu'un drop-in ultérieur l'a écrasé, que le fichier n'a jamais été appliqué, ou qu'un sysctl -w l'a modifié à chaud. Auditer le paramètre effectif est la seule preuve fiable de ce que le noyau applique réellement.
describe kernel_parameter('kernel.kptr_restrict') do
its('value') { should cmp 2 }
end
describe command("grep -hsE '^[[:space:]]*kernel.kptr_restrict[[: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.kptr_restrict. Sortie attendue :
kernel.kptr_restrict = 2
Inspecter et investiguer
Ce réglage ne produit aucune entrée de journal. Vérifiez-le directement via sysctl kernel.kptr_restrict. Vous pouvez constater l'effet en vérifiant que les pointeurs sont masqués, p. ex. cat /proc/kallsyms | head doit afficher les adresses en 0000000000000000.
Remédiation
Le plan de durcissement de Pavois utilise la ressource sysctl pour fixer kernel.kptr_restrict = 2, l'écrit dans un drop-in géré par Pavois sous /etc/sysctl.d/ pour la persistance, 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.kptr_restrict |
|---|---|
| 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é : les adresses de pointeurs noyau fuient via /proc, affaiblissant KASLR et fournissant à un attaquant les cibles précises pour transformer une primitive d'écriture en exécution de code noyau fiable.
Précautions avant application :
- La valeur
2masque les pointeurs même aux outils privilégiés. Certains outils de performance/débogage (perf, traceurs eBPF,systemtap, certains profileurs) peuvent afficher des adresses0x0ou perdre la résolution des symboles. Sur des hôtes dédiés au profilage, préférez1; pour des serveurs de production durcis,2est la valeur recommandée. - Le changement est inoffensif pour les applications et entièrement réversible à chaud, sans risque de blocage.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R9 | direct | 2.0 | haute |
| NIST | CM-6(a), SC-30, SC-30(2), SC-30(5) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| CIS | 1.5.6 | direct | per OS, see the benchmark table | 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.