Killswitch : arrête une fonction Linux sans redémarrer
Pourquoi ça compte pour toi
Quand une faille de sécurité se découvre, tu es exposé jusqu'au correctif + redémarrage. Killswitch te laisse couper la fonction vulnérable immédiatement, le temps que le vrai correctif arrive. Parfait pour les flottes de serveurs où tu ne peux pas tout redémarrer d'un coup.
Ce qu'il faut retenir
- 1.Écris une commande dans /sys/kernel/security/killswitch/control et la fonction renvoie -EPERM sans exécuter son code
- 2.Aucun redémarrage requis : prend effet immédiatement sur tous les CPU et disparaît au redémarrage suivant
- 3.Cible les chemins rarement utilisés (AF_ALG, ksmbd, nf_tables, vsock) où une journée d'indisponibilité coûte moins cher qu'un kernel vulnérable
Tu galères avec le jargon ?
Lis la version réécrite en mode débutant — toutes les idées, sans le jargon.
Pourquoi c'est malin
Aujourd'hui, quand une CVE cible une fonction spécifique du kernel, tu dois :
- ▸Attendre le correctif
- ▸Compiler un kernel
- ▸Déployer
- ▸Redémarrer la machine (ou la flotte entière)
Killswitch saute les étapes 1, 2, 3. Tu peux bloquer la fonction en direct depuis sysfs, immédiatement.
Comment ça marche
L'admin tape :
echo "engage af_alg_sendmsg -1" > /sys/kernel/security/killswitch/control
Résultat : chaque appel à af_alg_sendmsg() retourne -1 (ou la valeur que tu spécifies) sans rien exécuter. Aucun corps de fonction, aucun effet de bord.
Pour désactiver :
echo "disengage af_alg_sendmsg" > /sys/kernel/security/killswitch/control
Ou tout désactiver d'un coup :
echo "disengage_all" > /sys/kernel/security/killswitch/control
Cas d'usage réel
Beaucoup de vulnérabilités kernel récentes vivent dans des chemins "oubliés" :
- ▸AF_ALG (sockets algébriques) : 1% des installations l'utilisent
- ▸ksmbd (partage SMB Linux) : utilisé seulement sur certains déploiements
- ▸nf_tables (pare-feu) : pas indispensable partout
Si une faille y traîne, tu peux neutraliser le service le jour du correctif, au lieu de tourner 48h avec une faille active.
Pièges à éviter
L'article donne des exemples de ce qu'il ne faut pas faire :
Mauvais : bloquer af_alg_count_tsgl() (retourne le nombre d'entrées SG). Si tu retournes 0, l'appelant alloue un petit tampon et plante sur un dépassement de tampon.
Bon : bloquer af_alg_sendmsg() (le point d'entrée haut niveau). Aucun appelant ne voit d'état partiellement initialisé.
Règle : neutralise toujours la fonction la plus haut niveau qui contient le bug.
Bonus : activation au démarrage
Tu peux aussi configurer des killswitches dans le chargeur de démarrage :
killswitch=buggy_func=-1,another_func=-22
Parfait pour déployer une atténuation à la flotte via PXE, sans attendre la recompilation du kernel.
Un détail rassurant
Le kernel se marque comme modifié (« tainted »). Si un crash arrive sur une machine où killswitch tourne, les logs affichent Tainted: ... H pour signaler qu'une fonction était bloquée.
Et concrètement pour toi ?
Choisis ton profil — la lecture de l'article change selon qui tu es.
Pour toi, c'est la preuve que Linux n'est pas figé : même le kernel peut se corriger à chaud sans tout arrêter. Ça explique pourquoi les datacenters ne craignent pas de relancer leurs serveurs—killswitch démontre qu'ils ont des options qu'un OS classique n'a pas.
Source
Pour aller plus loin
Cet article t'a donné envie d'approfondir ? Deux formations Noésis t'attendent :