- 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é
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é »
Aucun commentaire pour le moment.