Im Jahr 2021 gibt es mehr Gründe, warum Menschen Linux lieben als je zuvor. In dieser Serie werde ich 21 verschiedene Gründe für die Verwendung von Linux nennen. Dieser Artikel diskutiert den Einfluss von Linux auf die Sicherheit von Open-Source-Software.
Ein oft gepriesener Vorteil von Open-Source-Software ist, dass ihr Code von jedem und jedem überprüft (oder „geprüft“, wie Sicherheitsexperten gerne sagen) kann. Wenn Sie jedoch viele Open-Source-Benutzer fragen, wann sie das letzte Mal Code überprüft haben, erhalten Sie möglicherweise Antworten, die von einem leeren Blick bis zu einem verlegenen Murmeln reichen. Außerdem gibt es einige wirklich große Open-Source-Anwendungen, sodass es schwierig sein kann, jede einzelne Codezeile effektiv zu überprüfen.
Ausgehend von diesen etwas unbequemen Wahrheiten muss man sich fragen:Wenn sich niemand den Code ansieht, spielt es dann wirklich eine Rolle, ob er offen ist oder nicht?
Sollten Sie Open Source vertrauen?
Wir neigen dazu, beim Hobby-Computing die banale Annahme zu treffen, dass Open Source "sicherer" ist als alles andere. Wir sprechen nicht oft darüber, was das bedeutet, was die Vergleichsgrundlage ist („sicherer“ als was?) oder wie es überhaupt zu dem Schluss gekommen ist. Es ist eine gefährliche Aussage, weil sie impliziert, dass, solange Sie etwas Open Source nennen , erbt es automatisch und auf magische Weise eine verbesserte Sicherheit. Das ist nicht das, worum es bei Open Source geht, und in der Tat ist es das, wogegen Open Source-Sicherheit sehr dagegen ist.
Sie sollten niemals davon ausgehen, dass eine Anwendung sicher ist, es sei denn, Sie haben ihren Code persönlich geprüft und verstanden. Sobald Sie dies getan haben, können Sie ultimatives Vertrauen zuweisen zu dieser Anwendung. Ultimatives Vertrauen ist keine Sache, die Sie auf einem Computer tun; Es ist etwas, was Sie in Ihrem eigenen Kopf tun:Sie vertrauen Software, weil Sie glauben, dass sie sicher ist, zumindest bis jemand einen Weg findet, diese Software auszunutzen.
Sie sind die einzige Person, die diesem Code absolut vertrauen kann, also muss jeder Benutzer, der diesen Luxus haben möchte, den Code selbst prüfen. Es zählt nicht, jemand anderen beim Wort zu nehmen!
Bis Sie also eine Codebasis selbst geprüft und verstanden haben, ist das maximale Vertrauensniveau, das Sie einer Anwendung geben können, ein Spektrum, das von ungefähr bis überhaupt nicht vertrauenswürdig reicht bis ziemlich vertrauenswürdig . Dafür gibt es keinen Spickzettel. Es ist eine persönliche Entscheidung, die Sie für sich selbst treffen müssen. Wenn Sie von Personen, denen Sie sehr vertrauen, gehört haben, dass eine Anwendung sicher ist, vertrauen Sie dieser Software möglicherweise mehr als einer Sache, für die Sie keine vertrauenswürdigen Empfehlungen erhalten haben.
Da Sie proprietären (nicht Open-Source-)Code nicht prüfen können, können Sie ihm niemals ultimatives Vertrauen zuweisen .
Das Gesetz von Linus
Weitere Linux-Ressourcen
- Spickzettel für Linux-Befehle
- Spickzettel für fortgeschrittene Linux-Befehle
- Kostenloser Online-Kurs:RHEL Technical Overview
- Spickzettel für Linux-Netzwerke
- SELinux-Spickzettel
- Spickzettel für allgemeine Linux-Befehle
- Was sind Linux-Container?
- Unsere neuesten Linux-Artikel
Die Realität ist, dass nicht jeder ein Programmierer ist und nicht jeder, der ein Programmierer ist, die Zeit hat, sich der Überprüfung von Hunderten und Aberhunderten von Codezeilen zu widmen. Wenn Sie Code also nicht selbst prüfen, müssen Sie sich dafür entscheiden, (bis zu einem gewissen Grad) den Leuten zu vertrauen, die dies tun Prüfcode.
Also genau, wer prüft Code überhaupt?
Das Gesetz von Linus besagt, dass bei genügend Augäpfeln alle Fehler oberflächlich sind , aber wir wissen nicht wirklich, wie viele Augäpfel "genug" sind. Unterschätzen Sie die Zahl jedoch nicht. Software wird sehr oft von mehr Personen überprüft, als Sie sich vorstellen können. Der oder die ursprünglichen Entwickler kennen offensichtlich den Code, den sie geschrieben haben. Open Source ist jedoch oft eine Gruppenarbeit, je länger Code also offen ist, desto mehr Softwareentwickler sehen ihn. Ein Entwickler muss große Teile des Codes eines Projekts überprüfen, weil er eine Codebasis lernen muss, um neue Funktionen dafür zu schreiben.
Auch Open-Source-Packager engagieren sich bei vielen Projekten, um sie einer Linux-Distribution zur Verfügung zu stellen. Manchmal kann eine Anwendung paketiert werden, ohne mit dem Code vertraut zu sein, aber oft macht sich ein Paketierer mit dem Code eines Projekts vertraut, sowohl weil er keine Software absegnen möchte, der er nicht vertraut, als auch weil er möglicherweise Änderungen vornehmen muss damit es richtig kompiliert wird. Bug-Reporter und Triager machen sich manchmal auch mit einer Codebasis vertraut, wenn sie versuchen, Anomalien zu lösen, die von Macken bis hin zu größeren Abstürzen reichen. Natürlich enthüllen einige Bug-Melder unbeabsichtigt Schwachstellen im Code, nicht indem sie ihn selbst überprüfen, sondern indem sie auf etwas aufmerksam machen, das offensichtlich nicht wie beabsichtigt funktioniert. Systemadministratoren machen sich häufig mit dem Code einer wichtigen Software vertraut, auf die sich ihre Benutzer verlassen. Schließlich gibt es Sicherheitsforscher, die sich ausschließlich mit Code befassen, um potenzielle Exploits aufzudecken.
Vertrauen und Transparenz
Einige Leute gehen davon aus, dass große Software, weil sie aus Hunderttausenden von Codezeilen besteht, im Grunde unmöglich zu auditieren ist. Lassen Sie sich nicht davon täuschen, wie viel Code erforderlich ist, um eine Anwendung auszuführen. Sie müssen nicht wirklich Millionen von Zeilen lesen. Code ist hochgradig strukturiert, und ausnutzbare Schwachstellen sind selten nur eine einzelne Zeile, die zwischen Millionen von Zeilen versteckt ist; normalerweise sind ganze Funktionen beteiligt.
Es gibt natürlich Ausnahmen. Manchmal wird eine schwerwiegende Schwachstelle mit nur einem Systemaufruf oder durch die Verknüpfung mit einer fehlerhaften Bibliothek aktiviert. Glücklicherweise sind diese Arten von Fehlern dank der aktiven Rolle von Sicherheitsforschern und Schwachstellendatenbanken relativ leicht zu bemerken.
Einige Leute verweisen auf Bugtracker, wie die Common Vulnerabilities and Exposures (CVE)-Website, und folgern daraus, dass es eigentlich so klar wie der Tag ist, dass Open Source nicht sicher ist. Schließlich werden Hunderte von Sicherheitsrisiken gegen viele Open-Source-Projekte eingereicht, die für alle sichtbar sind. Lass dich davon aber nicht täuschen. Nur weil Sie die Fehler in geschlossener Software nicht sehen können, heißt das nicht, dass diese Fehler nicht existieren. Tatsächlich wissen wir, dass sie es tun, weil auch gegen sie Exploits eingereicht werden. Der Unterschied besteht darin, dass alle Exploits gegen Open-Source-Anwendungen stehen Entwicklern (und Benutzern) zur Verfügung, damit diese Fehler behoben werden können. Das ist Teil des Systems, das das Vertrauen in Open Source stärkt, und es fehlt vollständig bei proprietärer Software.
Es gibt vielleicht nie "genug" Augäpfel für Code, aber je stärker und vielfältiger die Community rund um den Code ist, desto größer ist die Chance, Schwachstellen aufzudecken und zu beheben.
Vertrauen und Menschen
Bei Open Source die Wahrscheinlichkeit, dass viele Entwickler, die alle am selben Projekt arbeiten, etwas nicht sicher bemerkt haben aber alle haben gleichermaßen darüber geschwiegen, dass dieser Fehler als gering angesehen wird, da Menschen sich selten gegenseitig auf diese Weise verschwören. Wir haben in letzter Zeit gesehen, wie unzusammenhängendes menschliches Verhalten mit der Eindämmung von COVID-19 sein kann:
- Wir alle haben einen Fehler (einen Virus) identifiziert.
- Wir wissen, wie wir die Ausbreitung verhindern können (bleib zu Hause).
- Trotzdem breitet sich das Virus weiter aus, weil eine oder mehrere Personen vom Minderungsplan abweichen.
Gleiches gilt für Fehler in der Software. Wenn es einen Fehler gibt, wird jemand, der ihn bemerkt, ihn ans Licht bringen (vorausgesetzt natürlich, dass jemand ihn sieht).
Bei proprietärer Software kann es jedoch sehr wahrscheinlich sein, dass viele Entwickler, die an einem Projekt arbeiten, etwas Unsicheres bemerken, aber ebenso schweigen, weil das proprietäre Modell auf Gehaltsschecks beruht. Wenn sich ein Entwickler gegen einen Fehler ausspricht, kann dieser Entwickler bestenfalls dem Ruf der Software schaden, wodurch der Umsatz sinkt, oder im schlimmsten Fall von seinem Job gefeuert werden. Entwickler, die dafür bezahlt werden, im Geheimen an Software zu arbeiten, neigen nicht dazu, über deren Fehler zu sprechen. Wenn Sie jemals als Entwickler gearbeitet haben, haben Sie wahrscheinlich eine Geheimhaltungsvereinbarung unterzeichnet und wurden über die Bedeutung von Geschäftsgeheimnissen belehrt und so weiter. Proprietäre Software ermutigt und erzwingt sogar angesichts schwerwiegender Fehler Stillschweigen.
Vertrauen und Software
Vertrauen Sie keiner Software, die Sie nicht geprüft haben.
Wenn Sie Software vertrauen müssen, die Sie nicht geprüft haben, entscheiden Sie sich dafür, Code zu vertrauen, der vielen Entwicklern ausgesetzt ist, die wahrscheinlich unabhängig voneinander über eine Schwachstelle sprechen werden.
Open Source ist nicht von Natur aus sicherer als proprietäre Software, aber die vorhandenen Systeme, um das Problem zu beheben, sind viel besser geplant, implementiert und mit Personal ausgestattet.