Désactiver le chargement automatique des disciplines de ligne TTY
Positionne dev.tty.ldisc_autoload=0 afin qu'un processus non privilégié ne puisse plus faire charger automatiquement au noyau un module de discipline de ligne TTY simplement en le demandant (ioctl TIOCSETD). Seules les disciplines déjà chargées restent accessibles.
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.
Ce que vérifie Pavois
Pavois lit la valeur effective dans /proc/sys/dev/tty/ldisc_autoload (ressource InSpec kernel_parameter) : c'est la valeur que le noyau consulte quand un processus réclame une discipline, et la seule preuve que la protection est active. Un second contrôle inspecte /etc/sysctl.conf et les répertoires sysctl.d pour prouver la persistance, car une valeur posée avec sysctl -w seule revient à zéro au prochain démarrage. Un fichier de configuration seul ne prouve rien non plus : un drop-in chargé plus tard, ou un sysctl -w à chaud, peut l'écraser, et c'est précisément le faux négatif qu'un contrôle limité aux fichiers produirait.
describe kernel_parameter('dev.tty.ldisc_autoload') do
its('value') { should cmp 0 }
end
describe command("grep -hsE '^[[:space:]]*dev.tty.ldisc_autoload[[:space:]]*=[[:space:]]*0([[: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
Vérifiez la valeur effective et sa persistance :
sysctl dev.tty.ldisc_autoload
# dev.tty.ldisc_autoload = 0
grep -r dev.tty.ldisc_autoload /etc/sysctl.conf /etc/sysctl.d/
# /etc/sysctl.d/zz-pavois.conf:dev.tty.ldisc_autoload = 0
Les deux doivent concorder : un 0 dans /proc sans rien sur le disque est perdu au prochain démarrage, et un 0 sur le disque avec un 1 dans /proc signifie que le réglage n'a jamais été (re)chargé.
Inspecter et investiguer
Le noyau ne journalise pas un chargement automatique refusé : le processus demandeur reçoit simplement une erreur en retour de son ioctl TIOCSETD, et la trace éventuelle se trouve donc dans les journaux de ce programme. Ce qui reste observable, c'est l'activité de modules autour : une discipline réellement chargée (par root, délibérément) apparaît dans lsmod et journalctl -k, et le jeu de règles d'audit Pavois enregistre les appels de chargement (init_module, finit_module, clé modules) dans /var/log/audit/audit.log : cherchez key="modules" directement dans le fichier brut plutôt que de vous fier à ausearch.
Remédiation
Le plan Pavois applique cette règle comme une remédiation sysctl : la clé est agrégée avec les autres écarts sysctl dans un unique drop-in, /etc/sysctl.d/zz-pavois.conf. Le préfixe zz- est délibéré : il trie après tout fichier 99-* livré par la distribution, si bien que Pavois a le dernier mot. L'écriture du fichier déclenche un rechargement sysctl --system, de sorte que la valeur en vigueur corresponde immédiatement à celle qui persiste, sans redémarrage. Pavois active également une unité oneshot qui rejoue sysctl --system après network-online.target, car la configuration réseau tardive remet certaines clés à leur valeur par défaut.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| key | dev.tty.ldisc_autoload |
|---|---|
| resource | sysctl |
| value | 0 |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque faible : pas de redémarrage, aucun effet sur SSH, et aucun effet sur une discipline déjà chargée. Le réglage ne bloque que le chargement automatique d'un module de discipline de ligne à la demande d'un processus. Il ne mord que là où une charge de travail compte sur le chargement à la volée d'une discipline non intégrée au noyau : piles de lignes série (slip, ppp, n_hdlc), CAN sur série (slcan), certains démons Bluetooth, GPS/AIS ou série industriels. Ceux-ci continuent de fonctionner tant que le module est chargé explicitement au préalable : modprobe <module>, ou une entrée permanente dans /etc/modules-load.d/. Inventoriez les disciplines utilisées par vos charges série (lsmod) avant d'appliquer, et préchargez-les. Sur un serveur sans charge série, le changement est invisible.