En 2021, il y a plus de raisons que jamais pour lesquelles les gens aiment Linux. Dans cette série, je partagerai 21 raisons différentes d'utiliser Linux. Cet article traite de l'influence de Linux sur la sécurité des logiciels open source.
Une vertu souvent vantée des logiciels open source est que leur code peut être revu (ou "vérifié", comme les professionnels de la sécurité aiment à le dire) par n'importe qui et n'importe qui. Cependant, si vous demandez à de nombreux utilisateurs open source quand ils ont revu le code pour la dernière fois, vous pourriez obtenir des réponses allant d'un regard vide à un murmure embarrassé. De plus, il existe de très grosses applications open source, il peut donc être difficile d'examiner efficacement chaque ligne de code.
En extrapolant à partir de ces vérités légèrement inconfortables, vous devez vous demander :lorsque personne ne regarde le code, est-ce vraiment important qu'il soit ouvert ou non ?
Faut-il faire confiance à l'open source ?
Nous avons tendance à faire l'hypothèse banale dans l'informatique amateur que l'open source est "plus sûr" qu'autre chose. Nous ne parlons pas souvent de ce que cela signifie, de la base de comparaison ("plus" sûre que quoi ?), ou de la manière dont la conclusion a même été tirée. C'est une déclaration dangereuse à faire car cela implique que tant que vous appelez quelque chose open source , il hérite automatiquement et comme par magie d'une sécurité renforcée. Ce n'est pas ce qu'est l'open source, et en fait, c'est ce contre quoi la sécurité open source s'oppose.
Vous ne devez jamais présumer qu'une application est sécurisée à moins d'avoir personnellement audité et compris son code. Une fois que vous avez fait cela, vous pouvez attribuer la confiance ultime à cette demande. La confiance ultime n'est pas une chose que vous faites sur un ordinateur; c'est quelque chose que vous faites dans votre esprit :vous faites confiance à un logiciel parce que vous choisissez de croire qu'il est sécurisé, du moins jusqu'à ce que quelqu'un trouve un moyen d'exploiter ce logiciel.
Vous êtes la seule personne qui peut accorder une confiance ultime à ce code, donc chaque utilisateur qui veut ce luxe doit auditer le code pour lui-même. Prendre la parole de quelqu'un d'autre ne compte pas !
Ainsi, jusqu'à ce que vous ayez audité et compris une base de code par vous-même, le niveau de confiance maximal que vous pouvez accorder à une application est un spectre allant d'environ, pas du tout digne de confiance à plutôt digne de confiance . Il n'y a pas de feuille de triche pour cela. C'est un choix personnel que vous devez faire vous-même. Si vous avez entendu dire par des personnes en qui vous avez toute confiance qu'une application est sécurisée, vous pourriez faire plus confiance à ce logiciel qu'à quelque chose pour lequel vous n'avez reçu aucune recommandation fiable.
Comme vous ne pouvez pas auditer le code propriétaire (non open source), vous ne pouvez jamais lui attribuer une confiance ultime .
Loi de Linus
Plus de ressources Linux
- Aide-mémoire des commandes Linux
- Aide-mémoire des commandes Linux avancées
- Cours en ligne gratuit :Présentation technique de RHEL
- Aide-mémoire sur le réseau Linux
- Aide-mémoire SELinux
- Aide-mémoire sur les commandes courantes de Linux
- Que sont les conteneurs Linux ?
- Nos derniers articles Linux
La réalité est que tout le monde n'est pas programmeur et que tous les programmeurs n'ont pas le temps de passer en revue des centaines et des centaines de lignes de code. Donc, si vous n'allez pas auditer le code vous-même, vous devez choisir de faire confiance (dans une certaine mesure) aux personnes qui font code d'audit.
Alors, qui vérifie exactement le code ?
La loi de Linus affirme que avec suffisamment de globes oculaires, tous les bogues sont superficiels , mais nous ne savons pas vraiment combien de globes oculaires sont "suffisants". Cependant, ne sous-estimez pas le nombre. Les logiciels sont très souvent évalués par plus de personnes que vous ne l'imaginez. Le ou les développeurs d'origine connaissent évidemment le code qu'ils ont écrit. Cependant, l'open source est souvent un effort de groupe, donc plus le code est ouvert longtemps, plus les développeurs de logiciels finissent par le voir. Un développeur doit revoir les principales parties du code d'un projet car il doit apprendre une base de code pour écrire de nouvelles fonctionnalités.
Les empaqueteurs open source s'impliquent également dans de nombreux projets afin de les rendre disponibles pour une distribution Linux. Parfois, une application peut être empaquetée avec presque aucune familiarité avec le code, mais souvent un empaqueteur se familiarise avec le code d'un projet, à la fois parce qu'il ne veut pas se déconnecter d'un logiciel auquel il ne fait pas confiance et parce qu'il peut avoir à faire des modifications. pour qu'il compile correctement. Les rapporteurs de bogues et les trieurs se familiarisent également parfois avec une base de code lorsqu'ils tentent de résoudre des anomalies allant des bizarreries aux plantages majeurs. Bien sûr, certains reporters de bogues révèlent par inadvertance des vulnérabilités du code non pas en l'examinant eux-mêmes, mais en attirant l'attention sur quelque chose qui ne fonctionne manifestement pas comme prévu. Les administrateurs système se familiarisent fréquemment avec le code d'un logiciel important sur lequel leurs utilisateurs comptent. Enfin, il existe des chercheurs en sécurité qui fouillent dans le code exclusivement pour découvrir des exploits potentiels.
Confiance et transparence
Certaines personnes supposent que parce qu'un logiciel majeur est composé de centaines de milliers de lignes de code, il est fondamentalement impossible à auditer. Ne vous laissez pas berner par la quantité de code nécessaire pour exécuter une application. Vous n'êtes pas obligé de lire des millions de lignes. Le code est très structuré et les failles exploitables sont rarement une seule ligne cachée parmi des millions de lignes; il y a généralement des fonctions entières impliquées.
Il y a des exceptions, bien sur. Parfois, une vulnérabilité grave est activée avec un seul appel système ou en se liant à une bibliothèque défectueuse. Heureusement, ces types d'erreurs sont relativement faciles à remarquer, grâce au rôle actif des chercheurs en sécurité et des bases de données de vulnérabilités.
Certaines personnes pointent vers des traqueurs de bogues, tels que le site Web Common Vulnerabilities and Exposures (CVE), et en déduisent qu'il est en fait aussi évident que le jour que l'open source n'est pas sécurisé. Après tout, des centaines de risques de sécurité sont déposés contre de nombreux projets open source, à la vue de tous. Ne laissez pas cela vous tromper, cependant. Ce n'est pas parce que vous ne voyez pas les défauts d'un logiciel fermé que ces défauts n'existent pas. En fait, nous savons qu'ils le font parce que des exploits sont également déposés contre eux. La différence est que tous les exploits contre les applications open source sont disponibles pour les développeurs (et les utilisateurs) afin que ces failles puissent être atténuées. Cela fait partie du système qui renforce la confiance dans l'open source, et c'est totalement absent des logiciels propriétaires.
Il n'y aura peut-être jamais "assez" de regards sur un code, mais plus la communauté autour du code est forte et diversifiée, plus il y a de chances de découvrir et de corriger les faiblesses.
La confiance et les gens
En open source, la probabilité que de nombreux développeurs, chacun travaillant sur le même projet, aient remarqué quelque chose de non sécurisé mais sont tous restés également silencieux sur cette faille considérée comme faible car les humains s'entendent rarement mutuellement pour conspirer de cette manière. Nous avons vu récemment à quel point le comportement humain peut être décousu avec l'atténuation du COVID-19 :
- Nous avons tous identifié une faille (un virus).
- Nous savons comment l'empêcher de se propager (restez chez vous).
- Pourtant, le virus continue de se propager car une ou plusieurs personnes s'écartent du plan d'atténuation.
Il en va de même pour les bogues dans les logiciels. S'il y a un défaut, quelqu'un le remarquera le mettra en lumière (à condition, bien sûr, que quelqu'un le voit).
Cependant, avec un logiciel propriétaire, il peut y avoir une forte probabilité que de nombreux développeurs travaillant sur un projet remarquent quelque chose de non sécurisé mais restent tout aussi silencieux car le modèle propriétaire repose sur des chèques de paie. Si un développeur dénonce une faille, alors ce développeur peut au mieux nuire à la réputation du logiciel, diminuant ainsi les ventes, ou au pire, peut être licencié de son travail. Les développeurs payés pour travailler sur un logiciel en secret n'ont pas tendance à parler de ses défauts. Si vous avez déjà travaillé en tant que développeur, vous avez probablement signé un NDA et vous avez été sermonné sur l'importance des secrets commerciaux, etc. Les logiciels propriétaires encouragent, et plus souvent imposent, le silence même face à de graves failles.
Confiance et logiciel
Ne faites pas confiance à un logiciel que vous n'avez pas audité.
Si vous devez faire confiance à un logiciel que vous n'avez pas audité, choisissez de faire confiance au code qui est exposé à de nombreux développeurs qui, indépendamment, sont susceptibles de parler d'une vulnérabilité.
L'open source n'est pas intrinsèquement plus sûr que les logiciels propriétaires, mais les systèmes en place pour y remédier sont bien mieux planifiés, mis en œuvre et dotés en personnel.