Le travail de sécurité du noyau Linux
(kroah.com)- L’équipe de sécurité du noyau Linux corrige les vulnérabilités signalées aussi vite que possible et fusionne les correctifs dans le dépôt public, sans publier d’annonce ou de communication distincte
- Cette équipe est distincte de l’équipe Kernel CVE chargée de l’attribution des CVE ; tous ses membres agissent à titre individuel, indépendamment de leur entreprise d’appartenance
- Les bugs de sécurité sont traités exactement comme des bugs ordinaires et ne sont pas signalés comme des « correctifs de sécurité » distincts après correction
- Elle ne maintient pas d’embargo de plus de 7 jours, et la plupart des correctifs sont rendus publics immédiatement
- Cette approche tient compte de la nature de l’open source et de la diversité des environnements d’utilisation, afin de préserver la transparence et l’indépendance de la réponse de sécurité du noyau
Le rôle de l’équipe de sécurité du noyau Linux
- L’équipe de sécurité du noyau est un groupe de développeurs qui classe les bugs potentiellement liés à la sécurité signalés et les corrige rapidement
- Elle est chargée d’une réponse de sécurité réactive (reactive), distincte des mesures préventives de long terme menées par le Kernel Self-Protection Project
- La procédure de signalement repose sur un simple email en texte brut ; le HTML, les pièces jointes binaires et le chiffrement ne sont pas autorisés
- Les signalements chiffrés ne peuvent pas être traités en raison de la structure à destinataires multiples
- Les membres de l’équipe sont des développeurs clés représentant les principaux sous-systèmes du noyau, et ne peuvent pas partager le contenu des discussions avec leur employeur ou des tiers
- Cette indépendance permet une réponse cohérente, indépendamment des exigences légales de différents pays (CRA, etc.)
Procédure de correction des bugs
- Lorsqu’un bug signalé concerne un sous-système donné, le mainteneur de ce sous-système est inclus dans les échanges par email afin de le résoudre
- Pour les sous-systèmes où des problèmes reviennent régulièrement, le mainteneur peut participer directement à la mailing list de l’équipe de sécurité
- Si la personne qui signale le bug fournit un patch correctif, sa contribution est créditée ; sinon, les développeurs s’en chargent eux-mêmes
- Une fois la correction terminée, elle est fusionnée dans la branche principale du noyau ainsi que dans les versions stable
Politique d’embargo
- Les périodes de non-divulgation dépassant 7 jours ne sont pas autorisées, et la plupart des correctifs sont publiés immédiatement
- Après la correction, la personne à l’origine du signalement peut faire une annonce externe si elle le souhaite, mais l’équipe de sécurité, elle, ne publie aucune communication
- L’attribution des CVE est ensuite effectuée par l’équipe Kernel CVE, distincte de l’équipe de sécurité
Le principe « un bug reste un bug »
- En 2008, Linus Torvalds a explicitement indiqué qu’il ne fallait pas marquer séparément les bugs de sécurité
- Selon lui, la catégorie « correctif de sécurité » déforme l’importance des autres bugs
- Toutes les corrections de bugs ont la même importance, et sont intégrées immédiatement sans distinction entre sécurité, fonctionnalité ou performance
Pourquoi il n’y a pas de bulletin de sécurité
- Presque tous les bugs au niveau du noyau peuvent potentiellement devenir des problèmes de sécurité
- Ils peuvent prendre des formes variées : fuite mémoire, déni de service, fuite d’informations, etc.
- Par nature, dans l’open source, les développeurs ne connaissent pas l’environnement réel des utilisateurs
- Une correction mineure pour un utilisateur peut être une vulnérabilité critique pour un autre
- La politique reste donc simple
- corriger immédiatement les bugs connus
- publier les versions corrigées aussi vite que possible
- La position défendue est qu’au lieu de craindre qu’un correctif puisse causer un problème, il est plus dangereux de laisser un bug connu sans correction
Problèmes de sécurité matériels
- Des cas comme Spectre et Meltdown, qui impliquent à la fois l’OS et le matériel, nécessitent une procédure exceptionnelle
- Pour cela, une « Hardware Security Policy » a été mise en place, avec une collaboration via une mailing list chiffrée et restreinte
- Ce processus est lent et complexe, mais récemment, beaucoup de bugs matériels ont été résolus sans passer par cette procédure
- À l’avenir, les exigences de délai de réponse des lois CRA devraient rendre les longues périodes de non-divulgation encore plus difficiles
Contexte de création de l’équipe de sécurité du noyau
- Avant 2005, il n’existait aucun point de contact officiel pour la sécurité
- Les signalements passaient uniquement par des réseaux informels entre développeurs
- En 2005, la discussion a commencé avec une proposition par email de Steve Bergman, puis
Chris Wright a rédigé un patch ajoutant un contact sécurité et la documentation correspondante- C’est ainsi qu’un alias email centralisé (
security@kernel.org) a ensuite été officialisé
- C’est ainsi qu’un alias email centralisé (
Absence de bulletin de sécurité et de préalerte
- L’équipe de sécurité du noyau n’exploite aucune forme de bulletin de sécurité ni de liste de préalerte
- L’attribution des identifiants CVE relève de l’équipe Kernel CVE, et l’équipe de sécurité n’y participe pas
- Les demandes de liste de préalerte sont nombreuses, mais elle n’existe pas en raison du risque de fuite et du principe de publicité
- La position est la suivante : « si un gouvernement autorisait cela, c’est que le projet ne serait en réalité pas utilisé »
1 commentaires
Avis sur Hacker News
Ces derniers temps, les technologies qui rendent l’expérience de virtualisation fluide sur le bureau Linux progressent rapidement
Les pilotes GPU prennent désormais en charge les contextes natifs via Mesa, et les fonctions de partage entre invité et hôte sous Wayland s’améliorent aussi
Autrefois, il fallait un parsing complexe de protocoles comme sommelier ou wayland-proxy-virtwl, mais désormais le projet wl-cross-domain-proxy est en train de bien faire les choses
Parmi les VMM qui exploitent ces fonctionnalités, on trouve muvm, et comme solution qui les intègre il y a munix
Ce serait génial si on pouvait déplacer une machine virtuelle en la mettant en pause, en la transférant, puis en la relançant
C’est pour ce genre de raison que Red Hat reste important en 2025
Ce type de travail d’infrastructure sera toujours nécessaire
Quand Red Hat cherry-pick des commits liés à la sécurité, comment peuvent-ils savoir lesquels concernent la sécurité si l’amont ne l’indique pas ?
Il m’arrive parfois de rêver d’un OS parfaitement sûr à 100 %
Peut-être que la vérification formelle ou Rust en sont la clé
J’aimerais avoir la certitude de ne pas pouvoir me faire pirater
En fin de compte, l’humain reste la plus grande vulnérabilité
Même l’assembleur y avait été vérifié, et Dafny en est aussi issu
Mais sur le marché, le « déploiement rapide avant la bonne qualité » prime, donc il faut des décennies pour que ce type d’idée devienne grand public
Pour une vraie isolation, il faut de la virtualisation ou une séparation physique
C’est pourquoi il est difficile de rassembler beaucoup de contributeurs autour d’un « OS sûr à 100 % »
Cela dit, si le sujet t’intéresse, il existe plusieurs projets de développement d’OS
La sécurité est une compétition sans fin
Par ailleurs, on est en 2026 et le site personnel de Greg ne prend toujours pas en charge TLS
C’est facile à configurer avec Caddy, mais pour un site statique comme un blog personnel, le bénéfice réel du chiffrement est presque nul
De toute façon, le domaine et l’IP restent exposés en clair, donc ça ne change pas grand-chose
S’ils pensaient vraiment cela, ils auraient dû retirer le CNA, non ?
Or certains chercheurs ont tendance à vouloir simplement augmenter leur nombre de CVE, et cherchent donc à donner une haute priorité même à des bugs en réalité inoffensifs
« Si signaler un problème de sécurité impose le chiffrement, alors il faut revoir cette politique (oui, on parle du gouvernement britannique) »
Ce passage est juste hilarant
Dire que « les bugs ne sont que des bugs » est trop simpliste
Un DoS nécessitant les droits root et une prise de contrôle du système par un utilisateur non privilégié sont deux choses totalement différentes
Certains bugs provoquent clairement une violation de frontière de sécurité, et ceux-là doivent être classés comme bugs de sécurité
Cela fait des décennies qu’on l’explique à Greg
En pratique, si on n’exécute pas la dernière version, le noyau reste complètement non corrigé
Les CVE sont évités, les correctifs de vulnérabilités sont cachés dans les logs de commits, et les attaquants les repèrent en les lisant
Je ne vois pas pourquoi il faudrait insister spécialement là-dessus
Les clients demandent des correctifs liés au noyau dans les images Docker
Alors que Docker n’inclut pas le noyau
Il devrait exister un moyen de livrer des images sans noyau
Les images de base classiques n’incluent pas le noyau