Activer la prise en charge de Yama
Exige un noyau compilé avec le LSM Yama (CONFIG_SECURITY_YAMA=y), qui active les restrictions de portée ptrace.
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'usage non restreint de ptrace permet à tout processus compromis de s'attacher à d'autres processus du même utilisateur et d'en inspecter la mémoire. Le LSM Yama (CONFIG_SECURITY_YAMA=y) est la brique noyau qui rend disponible la restriction kernel.yama.ptrace_scope, empêchant un binaire détourné (navigateur, client mail, etc.) d'extraire identifiants, clés SSH ou jetons de session de processus voisins.
Ce que vérifie Pavois
Pavois lit la configuration de compilation du noyau en cours d'exécution, via /boot/config-$(uname -r) ou le /proc/config.gz interne, et vérifie CONFIG_SECURITY_YAMA=y. Interroger le noyau actif (et non une config par défaut empaquetée) garantit que le noyau a réellement démarré avec Yama compilé : un noyau installé mais pas encore démarré, ou un build hors arbre, donnerait sinon une fausse conformité.
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_SECURITY_YAMA=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should match(/^CONFIG_SECURITY_YAMA=y$/) }
endComment vérifier qu’elle est appliquée
Confirmez que l'option est compilée :
grep '^CONFIG_SECURITY_YAMA=' /boot/config-$(uname -r) || zcat /proc/config.gz | grep '^CONFIG_SECURITY_YAMA='
Sortie attendue : CONFIG_SECURITY_YAMA=y. Vous pouvez aussi vérifier que le réglage qu'il fournit existe : sysctl kernel.yama.ptrace_scope.
Inspecter et investiguer
Les tentatives de ptrace bloquées par Yama sont journalisées par le noyau. Examinez dmesg ou journalctl -k pour des messages comme ptrace of pid ... was attempted by .... Le niveau de restriction effectif se lit avec sysctl kernel.yama.ptrace_scope.
Remédiation
Aucune remédiation automatique n'est fournie : CONFIG_SECURITY_YAMA est une option noyau à la compilation, elle ne peut donc pas être activée à chaud. La correction consiste à exécuter un noyau compilé avec Yama. Les noyaux par défaut des distributions prises en charge l'embarquent déjà ; le remède est donc généralement d'installer ou de démarrer le noyau du fournisseur plutôt qu'un noyau personnalisé. Si vous compilez votre propre noyau, positionnez CONFIG_SECURITY_YAMA=y et reconstruisez.
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
Sans Yama, la restriction kernel.yama.ptrace_scope est indisponible, laissant chaque processus utilisateur capable de ptrace ses voisins, un vecteur majeur de vol latéral d'identifiants. Précautions : changer de noyau impose un redémarrage ; planifiez une fenêtre de maintenance et conservez l'entrée GRUB du noyau précédent en repli. Certains débogueurs (gdb), profileurs (perf) et outils de gestion de crash s'appuient sur ptrace ; avec Yama actif et ptrace_scope élevé, ils peuvent devoir s'exécuter en root ou utiliser CAP_SYS_PTRACE. Validez vos flux de débogage après le changement.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R20 | 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.