Désactiver la LDT (table de descripteurs locale)
Exige que le noyau soit compilé sans CONFIG_MODIFY_LDT_SYSCALL=y, supprimant l'appel système modify_ldt() et la prise en charge de la LDT par 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
CONFIG_MODIFY_LDT_SYSCALL active l'appel système modify_ldt(), qui permet à un processus d'installer des descripteurs de segment personnalisés dans une table de descripteurs locale propre au processus. Ce mécanisme x86 hérité (utilisé par du vieux code 16 bits/segmenté et certains bacs à sable) a un long historique de vulnérabilités noyau et d'exploits d'élévation de privilèges. L'espace utilisateur 64 bits moderne n'en a presque jamais besoin ; compiler le noyau sans CONFIG_MODIFY_LDT_SYSCALL supprime donc un appel système inutile et propice aux exploits, et réduit la surface d'attaque.
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 que CONFIG_MODIFY_LDT_SYSCALL n'est pas à y. Lire la config réelle du noyau démarré (et non un /boot/config-* obsolète) reflète si l'appel système modify_ldt() est réellement compilé.
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_MODIFY_LDT_SYSCALL=|PAVOIS_NO_KERNEL_CONFIG)'") do
its('stdout') { should_not match(/PAVOIS_NO_KERNEL_CONFIG/) }
its('stdout') { should_not match(/^CONFIG_MODIFY_LDT_SYSCALL=y$/) }
endComment vérifier qu’elle est appliquée
Exécutez grep '^CONFIG_MODIFY_LDT_SYSCALL=' /boot/config-$(uname -r). Attendu : aucune correspondance, ou # CONFIG_MODIFY_LDT_SYSCALL is not set, la ligne CONFIG_MODIFY_LDT_SYSCALL=y doit être absente. Sur un noyau qui l'a compilé mais désactivé à l'exécution, sysctl kernel.modify_ldt renvoie 0.
Inspecter et investiguer
Aucun journal dédié. Quand l'appel système est indisponible, les appelants reçoivent ENOSYS. Sur les noyaux compilés avec, le verrou à l'exécution est sysctl kernel.modify_ldt (0 = désactivé). Les programmes tentant de l'utiliser peuvent être tracés avec strace -e trace=modify_ldt <cmd>.
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 supprimer entièrement l'appel système, démarrez un noyau compilé sans CONFIG_MODIFY_LDT_SYSCALL. En atténuation à l'exécution sur les noyaux qui l'embarquent, positionnez kernel.modify_ldt=0 via sysctl, mais cela ne supprime pas l'appel système visé par cette règle.
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
Supprimer modify_ldt() casse les rares logiciels qui dépendent d'une LDT personnalisée : DOSEMU/ancien code Wine 16 bits, certains bacs à sable segmentés ou JIT hérités. Auditez ces charges avant d'appliquer. Comme le changement requiert un autre noyau, conservez l'entrée du noyau précédent dans le chargeur d'amorçage pour revenir en arrière si une application dépendante est trouvée.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R25 | 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.