Kees Cook, ancien administrateur système principal de kernel.org et leader de l'Ubuntu Security Team, qui travaille maintenant chez Google à la sécurité d'Android et de ChromeOS, a exprimé ses inquiétudes concernant le processus actuel de correction des erreurs dans les branches stables du noyau. Environ cent corrections sont ajoutées chaque semaine aux branches stables, et après la fermeture de la fenêtre de réception des modifications pour la prochaine version, ce nombre approche le millier (les développeurs retardent les corrections jusqu'à la fermeture de la fenêtre, puis publient tout le cumul après la formation de 'rc1'), ce qui est trop élevé et demande beaucoup de ressources pour maintenir les produits basés sur le noyau Linux.
Selon Kees, le processus de gestion des erreurs dans le noyau n'est pas suffisamment pris en compte et le noyau manque d'au moins 100 développeurs supplémentaires pour un travail coordonné dans ce domaine. Les principaux développeurs du noyau corrigent régulièrement des erreurs, mais il n'y a aucune garantie que ces corrections seront intégrées dans les variantes du noyau utilisées par les fabricants tiers. Les utilisateurs de divers produits basés sur le noyau Linux n'ont également pas la possibilité de contrôler quelles erreurs ont été corrigées et quel noyau est utilisé dans leurs dispositifs. En fin de compte, les fabricants sont responsables de la sécurité de leurs produits, mais avec l'intensité très élevée de publication des corrections dans les branches stables du noyau, ils se retrouvent confrontés à un choix : appliquer toutes les corrections, porter sélectivement les plus importantes ou ignorer toutes les corrections.
En conséquence, sans une branche séparée pour les corrections de vulnérabilités et sans obtenir d'informations sur le lien avec la sécurité d'un problème donné, les fabricants de produits basés sur le noyau Linux doivent continuellement transférer tous les correctifs des nouvelles branches stables. Cependant, ce travail nécessite une grande quantité de ressources et fait face à une résistance au sein des entreprises en raison de la crainte d'introduire des changements régressifs susceptibles de perturber le bon fonctionnement du produit.
Rappelons qu selon Linus Torvalds, toutes les erreurs sont importantes et les vulnérabilités ne doivent pas être séparées des autres types d'erreurs et classées dans une catégorie de priorité supérieure. Cette opinion s'explique par le fait que pour un développeur ordinaire, qui ne se spécialise pas dans les questions de sécurité, il n'est pas évident de faire le lien entre un correctif et une vulnérabilité potentielle (pour de nombreux correctifs, seul un audit séparé permet de comprendre qu'ils concernent la sécurité). Selon Linus, la tâche de distinguer les vulnérabilités potentielles du flot général des correctifs doit être assumée par des spécialistes en sécurité des équipes responsables du soutien des paquets avec le noyau dans les distributions Linux.
Kees Cook estime que la seule solution pour maintenir la sécurité du noyau à des coûts raisonnables à long terme est de transférer à des ingénieurs des entreprises la tâche de porter les corrections dans des compilations locales du noyau, pour collaborer de façon coordonnée à l'entretien des correctifs et des vulnérabilités dans le noyau principal (upstream). Dans l'état actuel des choses, de nombreux fabricants utilisent des versions du noyau qui ne sont pas les plus récentes et effectuent des backports des correctifs par leurs propres moyens, ce qui signifie que les ingénieurs de différentes entreprises doublent leurs efforts en s'attaquant au même problème.
Par exemple, si 10 entreprises, chacune avec un ingénieur s'occupant de backporter les mêmes corrections, réorientent ces ingénieurs vers la correction des bugs dans l'upstream, ils pourraient au lieu de porter une seule correction, résoudre 10 bugs différents pour un bénéfice commun, ou participer à la révision des modifications proposées afin d'éviter d'inclure des codes erronés dans le noyau. Les ressources pourraient également être dirigées vers la création de nouveaux outils pour tester et analyser le code, permettant d'identifier automatiquement, dès les premières étapes, les classes d'erreurs récurrentes.
Kees Cook propose également d'utiliser plus activement les tests automatisés et de fuzzing directement dans le processus de développement du noyau, d'appliquer des systèmes d'intégration continue et d'abandonner la gestion archaïque du développement par email. Actuellement, le test efficace est entravé par le fait que les principaux processus de test sont séparés du développement et se déroulent après la formation des versions. Kees recommande également de réduire le nombre d'erreurs en utilisant des langages assurant une meilleure et de confidentialité des utilisateurs est promis, ainsi que des standards ouverts. Un des arguments avancés est l'utilisation de l'algorithme Signal. Le système prend également en charge la recherche et la consultation illimitée de l'historique des messages, le partage de fichiers, les communications vocales et vidéo. De plus, il existe des fonctionnalités telles que des notifications de saisie, des confirmations de lecture, des notifications push et une recherche côté client., comme Rust.
Source : opennet.ru
