Désactiver la prise en charge du périphérique virtuel /dev/kmem
Exige que le noyau soit compilé sans CONFIG_DEVKMEM, supprimant l'interface /dev/kmem qui expose la mémoire virtuelle du noyau.
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
Le périphérique /dev/kmem est rarement utilisé, mais il peut servir à certaines opérations de débogage du noyau.
Ce que vérifie Pavois
Pavois lit le drapeau de compilation effectif du noyau en cours d'exécution via /boot/config-$(uname -r) ou /proc/config.gz, indexé sur $(uname -r). Le contrôle vérifie que le drapeau n'est pas =y, reflétant l'image réellement démarrée plutôt qu'un .config égaré qu'un scan à chemin fixe pourrait capter.
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_DEVKMEM=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should_not match(/^CONFIG_DEVKMEM=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep '^CONFIG_DEVKMEM=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep '^CONFIG_DEVKMEM='). Attendu : aucune sortie, ou # CONFIG_DEVKMEM is not set. Une ligne CONFIG_DEVKMEM=y est un échec. Vous pouvez aussi confirmer l'absence du périphérique avec ls -l /dev/kmem (doit signaler un fichier inexistant).
Inspecter et investiguer
Il s'agit d'une absence à la compilation sans journalisation à l'exécution. Vérifiez l'état directement avec zcat /proc/config.gz | grep DEVKMEM et ls /dev/kmem. Tout processus tentant d'ouvrir un /dev/kmem inexistant reçoit simplement ENOENT.
Remédiation
Aucune remédiation automatisée n'est fournie : une option de compilation du noyau ne se désactive pas en éditant un fichier. Appliquez-la manuellement en installant et démarrant un noyau compilé sans CONFIG_DEVKMEM (le défaut sur les distributions actuelles).
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
/dev/kmem est un périphérique caractère offrant un accès direct en lecture/écriture à l'espace d'adressage virtuel du noyau. Tout processus capable de l'ouvrir (root, ou via un bogue de privilège) peut lire des secrets, modifier le code du noyau ou installer un rootkit sans charger de module ni laisser de trace dans la liste des modules. C'est un mécanisme de débogage hérité que presque rien n'utilise légitimement. Le retirer à la compilation élimine une primitive de post-exploitation puissante. C'est une option à la compilation (à l'inverse des autres : elle doit être absente), modifiable uniquement en démarrant un noyau compilé sans. Les noyaux de distribution modernes la désactivent déjà, donc cette règle passe généralement. Précautions : les seuls logiciels ayant jamais eu besoin de /dev/kmem sont anciens (quelques vieux débogueurs, le lrmi d'origine) ; vérifiez que rien sur l'hôte n'en dépend avant de changer de noyau. Aucun risque de redémarrage au-delà d'un échange de noyau classique.
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.