Durcir le fonctionnement du compilateur à la volée (JIT) de BPF
Définit net.core.bpf_jit_harden=2 pour aveugler les constantes et masquer les adresses du code BPF compilé en JIT, pour tous les utilisateurs.
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 compilateur à la volée (JIT) d'eBPF transforme le bytecode BPF en code machine natif pour la performance, mais ce code généré réside dans l'espace noyau et ses adresses peuvent fuiter via /proc/kallsyms. Des attaquants ont détourné le JIT pour construire des primitives de JIT-spraying et contourner l'ASLR du noyau, transformant un programme BPF en tremplin d'exploitation. Définir net.core.bpf_jit_harden=2 active le durcissement pour tous les utilisateurs (pas seulement les non privilégiés) : il randomise/aveugle les constantes du code émis et cesse d'exposer les adresses du JIT, supprimant ces aides à l'exploitation.
Ce que vérifie Pavois
Pavois lit la valeur noyau effective via kernel_parameter('net.core.bpf_jit_harden') et vérifie qu'elle vaut 2. La valeur effective est celle qui régit réellement la façon dont le JIT émet le code à l'instant présent ; une clé écrite dans /etc/sysctl.d/ mais non rechargée, ou masquée par un autre drop-in, laisserait le noyau à sa valeur par défaut. Seule la lecture de la valeur effective (et non des fichiers de configuration) prouve que le durcissement est réellement en vigueur.
describe kernel_parameter('net.core.bpf_jit_harden') do
its('value') { should cmp 2 }
end
describe command("grep -hsE '^[[:space:]]*net.core.bpf_jit_harden[[:space:]]*=[[:space:]]*2([[: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 net.core.bpf_jit_harden. Sortie attendue :
net.core.bpf_jit_harden = 2
Inspecter et investiguer
sysctl net.core.bpf_jit_hardenaffiche la valeur courante.cat /proc/sys/net/core/bpf_jit_hardenest la valeur brute du noyau.- Ce paramètre ne produit aucun journal par événement ; il change seulement la façon dont le JIT émet le code. Pour auditer l'usage de BPF lui-même, inspectez les programmes chargés avec
bpftool prog show(nécessite root).
Remédiation
Le plan de durcissement de Pavois utilise la ressource sysctl pour positionner net.core.bpf_jit_harden à 2. Il écrit la clé dans un drop-in géré par Pavois puis le recharge, de sorte que le durcissement du JIT soit actif immédiatement et persiste 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 | net.core.bpf_jit_harden |
|---|---|
| resource | sysctl |
| value | 2 |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
L'aveuglement des constantes ajoute une surcharge CPU aux programmes BPF compilés en JIT ; les charges qui s'appuient fortement sur eBPF dans le chemin critique (filtrage de trafic XDP/tc à haut débit, certains traceurs d'observabilité comme Cilium ou un usage intensif de bpftrace) peuvent voir leur débit BPF mesurablement réduit. Il n'y a aucun risque de blocage réseau ou de service, c'est un pur compromis performance/sécurité. Avant d'appliquer sur un plan de données intensif en BPF, mesurez l'impact ; s'il est inacceptable, la valeur 1 (durcit uniquement les programmes non privilégiés) est une alternative plus légère, même si les référentiels exigent 2.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R12 | direct | 2.0 | haute |
| NIST | CM-6, 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.