Restreindre l'usage de ptrace aux processus descendants
Définit kernel.yama.ptrace_scope=1 pour qu'un processus ne puisse ptrace que ses propres descendants, bloquant l'espionnage mémoire entre processus.
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
Un usage non restreint de ptrace permet à n'importe quel processus appartenant à un utilisateur d'inspecter et de manipuler la mémoire de tous les autres processus de ce même utilisateur. Un binaire compromis peut ainsi s'attacher à un client SSH, un navigateur ou un gestionnaire de mots de passe en cours d'exécution et voler identifiants, clés de session ou secrets, sans privilège supplémentaire et sans piéger l'utilisateur. Définir kernel.yama.ptrace_scope=1 confine ptrace aux descendants directs du processus traceur (le modèle classique du débogueur), ce qui neutralise toute cette catégorie d'attaques par injection de processus et vol d'identifiants.
Ce que vérifie Pavois
Pavois lit la valeur noyau effective via kernel_parameter('kernel.yama.ptrace_scope'), c'est-à-dire ce que le noyau en cours applique réellement, et vérifie qu'elle vaut 1. Lire la valeur effective détecte le cas où un fichier drop-in de /etc/sysctl.d/ ou une ligne de /etc/sysctl.conf positionne la clé sans jamais l'avoir rechargée, ou bien où un drop-in ultérieur l'écrase. Un scanner basé sur les fichiers qui ne lit que sysctl.conf rapporterait une valeur qui n'est pas celle appliquée par le noyau.
describe kernel_parameter('kernel.yama.ptrace_scope') do
its('value') { should cmp 1 }
end
describe command("grep -hsE '^[[:space:]]*kernel.yama.ptrace_scope[[:space:]]*=[[:space:]]*1([[: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.yama.ptrace_scope. Sortie attendue :
kernel.yama.ptrace_scope = 1
Inspecter et investiguer
sysctl kernel.yama.ptrace_scopeaffiche la valeur courante.cat /proc/sys/kernel/yama/ptrace_scopeest la source de vérité brute du noyau.- Lorsqu'un appel
ptraceest refusé, le noyau journalise une ligne via le LSM Yama, visible avecdmesg | grep -i yama(ex.ptrace of pid ... was attempted by ...).
Remédiation
Le plan de durcissement de Pavois utilise la ressource sysctl pour positionner kernel.yama.ptrace_scope à 1. Il écrit la clé dans un drop-in géré par Pavois puis le recharge, de sorte que la valeur soit active immédiatement et persistante après 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.yama.ptrace_scope |
|---|---|
| resource | sysctl |
| value | 1 |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
L'impact fonctionnel est minime sur des serveurs. La principale réserve concerne le débogage et le traçage : des outils comme gdb, strace, ltrace ou les collecteurs de core dump s'attachant à un processus déjà lancé que vous n'avez pas créé seront refusés sauf s'ils tournent en root (CAP_SYS_PTRACE). Certains agents de supervision/APM et outils d'introspection de conteneurs reposent sur ptrace inter-processus. Avant d'appliquer, vérifiez qu'aucun agent dépendant d'un débogueur n'a besoin d'un attachement non privilégié ; si c'est le cas, lancez-le avec la capacité requise plutôt que de désactiver la protection. Les valeurs 2 ou 3 sont encore plus strictes mais cassent davantage d'outils ; 1 reste le bon compromis.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R11 | direct | 2.0 | haute |
| CIS | 1.5.2, 1.5.7 | direct | per OS, see the benchmark table | haute |
| NIST | SC-7(10) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
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.