Désactiver la prise en charge de /proc/kcore
Exige que le noyau en cours d'exécution soit compilé sans CONFIG_PROC_KCORE afin que la vue /proc/kcore de la mémoire noyau en direct n'existe pas.
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
/proc/kcore est un pseudo-fichier qui expose la mémoire du noyau en cours d'exécution sous forme d'image core ELF. Pour un attaquant privilégié (ou un outil facilitant l'élévation de privilèges), c'est une carte des structures du noyau et un moyen de lire la mémoire noyau en direct, aidant à contourner KASLR et à découvrir des vecteurs d'attaque. Compiler le noyau sans CONFIG_PROC_KCORE supprime entièrement cette surface d'introspection. C'est un durcissement de défense en profondeur, de faible sévérité : il réduit ce qu'un attaquant disposant déjà de droits élevés peut apprendre.
Ce que vérifie Pavois
Pavois lit la configuration de compilation du noyau en cours d'exécution via /boot/config-$(uname -r), avec repli sur /proc/config.gz, de sorte que le résultat reflète le noyau démarré. Contrairement aux autres règles de ce domaine, ce contrôle vérifie que l'option n'est pas à y (should_not match), car /proc/kcore doit être absent.
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_PROC_KCORE=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should_not match(/^CONFIG_PROC_KCORE=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep '^CONFIG_PROC_KCORE=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep '^CONFIG_PROC_KCORE='). La ligne doit être absente ou indiquer CONFIG_PROC_KCORE=n, elle ne doit pas être =y. Confirmez aussi que le fichier a disparu : ls -l /proc/kcore doit renvoyer No such file or directory.
Inspecter et investiguer
Il n'existe pas de journal d'événements pour cette surface statique ; confirmez par la présence/absence du fichier lui-même : ls -l /proc/kcore. Les tentatives d'accès à /proc/kcore par un processus peuvent être détectées avec une surveillance auditd (auditctl -w /proc/kcore -p r -k kcore) et apparaîtraient alors dans /var/log/audit/audit.log sous key="kcore".
Remédiation
Aucune remédiation automatique : CONFIG_PROC_KCORE est une option de compilation du noyau et ne peut pas être désactivée à l'exécution. La plupart des noyaux de distribution l'activent, donc la conformité nécessite généralement un noyau personnalisé avec l'option désactivée. Comme atténuation à l'exécution, vous pouvez restreindre l'accès (/proc/kcore est déjà réservé à root, mode 0400) ou auditer les lectures. À appliquer manuellement ; pavois harden apply ne peut pas modifier un paramètre compilé en dur.
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
Laisser /proc/kcore disponible offre à un attaquant privilégié un moyen simple de lire la mémoire noyau et de contourner KASLR, mais il n'est accessible que par root, d'où la faible sévérité. Le coût pratique de sa suppression est que les outils de débogage noyau et d'analyse de mémoire en direct (crash, gdb sur kcore, certaines introspections perf/eBPF) perdent une source de données. Précaution : ne le désactivez que sur les hôtes de production qui n'ont pas besoin de débogage noyau en direct ; conservez-le sur les systèmes dédiés au débogage/à l'analyse. Aucun risque de blocage d'accès ni de disponibilité.
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.