Renforcer les copies mémoire entre le noyau et l'espace utilisateur
Exige que le noyau soit compilé avec CONFIG_HARDENED_USERCOPY=y afin que les copies vers/depuis l'espace utilisateur soient bornées à la taille de l'objet.
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
CONFIG_HARDENED_USERCOPY=y fait valider par le noyau chaque copy_to_user/copy_from_user par rapport aux limites de l'objet source/destination. Sans cette option, une copie qui déborde un objet du tas ou de la pile n'est pas contrôlée, transformant des bugs ordinaires en divulgations de mémoire noyau (fuite de secrets, contournement de KASLR) ou en primitives de dépassement de tas utilisées pour l'élévation de privilèges. L'activer neutralise des classes entières d'attaques pour un coût d'exécution faible.
Ce que vérifie Pavois
Pavois lit la configuration de compilation du noyau en cours d'exécution, /boot/config-$(uname -r) et /proc/config.gz en mémoire, et confirme CONFIG_HARDENED_USERCOPY=y. Cela vise le noyau réellement démarré, et non un fichier /boot/config-* obsolète laissé par un paquet précédent ; un noyau personnalisé ou vendeur ayant discrètement retiré l'option est ainsi détecté.
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_HARDENED_USERCOPY=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_HARDENED_USERCOPY=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep '^CONFIG_HARDENED_USERCOPY=' /boot/config-$(uname -r) (ou zcat /proc/config.gz | grep CONFIG_HARDENED_USERCOPY). Sortie attendue : CONFIG_HARDENED_USERCOPY=y.
Inspecter et investiguer
Quand la protection se déclenche à l'exécution, le noyau journalise une faute usercopy, examinez dmesg | grep -i usercopy ou journalctl -k | grep -i usercopy pour des messages tels que usercopy: Kernel memory overwrite attempt detected.
Remédiation
Aucune remédiation automatisée : il s'agit d'une option de compilation du noyau, pas d'un paramètre modifiable à chaud. Le plan de durcissement Pavois est vide. Pour corriger, démarrez un noyau compilé avec CONFIG_HARDENED_USERCOPY=y, installez un noyau de distribution qui l'embarque (les noyaux Debian/Ubuntu/RHEL actuels le font) ou recompilez votre noyau personnalisé avec l'option, puis redémarrez.
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
Si l'option est absente, le noyau n'effectue aucun contrôle de bornes sur les copies utilisateur, exposant le système à l'exploitation par divulgation mémoire et dépassement de tas. La changer impose de démarrer un autre noyau : vérifiez que le noyau de remplacement démarre toujours et charge tous les pilotes/modules requis avant de retirer l'ancien. Conservez l'entrée du noyau précédent dans le chargeur d'amorçage pour pouvoir revenir en arrière si le nouveau noyau ne démarre pas.
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.