Advertisements

Das Linus-Gesetz für Open-Source-Sicherheit verstehen

Im Jahr 2021 gibt es mehr Gründe, warum Menschen Linux lieben als je zuvor. In dieser Serie werde ich 21 verschiedene Gründe nennen, um Linux zu verwenden. In diesem Artikel wird der Einfluss von Linux auf die Sicherheit von Open-Source-Software erörtert.

Eine oft gelobte Tugend von Open-Source-Software besteht darin, dass ihr Code von jedem und jedem überprüft (oder „geprüft“ werden kann, wie Sicherheitsexperten gerne sagen). 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 Gemurmel 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 niemand den Code ansieht, ist es dann wirklich wichtig, ob er offen ist oder nicht?

Sollten Sie Open Source vertrauen?

Wir neigen dazu, beim Hobby-Computing die banale Annahme aufzustellen, dass Open Source “sicherer” ist als alles andere. Wir sprechen nicht oft darüber, was das bedeutet, was die Vergleichsbasis ist (“sicherer” als was?) oder wie der Schluss überhaupt zustande gekommen ist. Es ist eine gefährliche Aussage, weil es impliziert, dass solange du etwas rufst Open Source, erbt es automatisch und auf magische Weise die verbesserte Sicherheit. Darum geht es bei Open Source nicht, und in der Tat ist Open Source-Sicherheit sehr dagegen.

Sie sollten niemals davon ausgehen, dass eine Anwendung sicher ist, es sei denn, Sie haben den Code persönlich geprüft und verstanden. Sobald Sie dies getan haben, können Sie ultimatives Vertrauen zu diesem Antrag. Ultimatives Vertrauen ist nichts, was 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 uneingeschränkt vertrauen kann. Jeder Benutzer, der diesen Luxus möchte, muss den Code selbst prüfen. Das Wort eines anderen zu nehmen zählt nicht!

Bis Sie also eine Codebasis für sich selbst geprüft und verstanden haben, können Sie einer Anwendung maximal ein Vertrauensniveau verleihen, das von ca. überhaupt nicht vertrauenswürdig zu ziemlich vertrauenswürdig. Dafür gibt es keinen Spickzettel. Es ist eine persönliche Entscheidung, die Sie selbst treffen müssen. Wenn Sie von Leuten gehört haben, denen Sie stark vertrauen, dass eine Anwendung sicher ist, dann vertrauen Sie dieser Software möglicherweise mehr als etwas, für das Sie keine vertrauenswürdigen Empfehlungen erhalten haben.

Da Sie proprietären (nicht Open Source) Code nicht prüfen können, können Sie ihn niemals zuweisen ultimatives Vertrauen.

Linus’ Gesetz

Weitere Linux-Ressourcen

Die Realität ist, dass nicht jeder Programmierer ist und nicht jeder Programmierer die Zeit hat, Hunderte und Aberhunderte von Codezeilen zu überprüfen. Wenn Sie also nicht selbst Code prüfen, müssen Sie (bis zu einem gewissen Grad) den Leuten vertrauen, die tun Audit-Code.

Also genau, wer prüft eigentlich Code?

Das Gesetz von Linus besagt, dass Bei genügend Augäpfeln sind alle Käfer flach, aber wir wissen nicht wirklich, wie viele Augäpfel “genug” sind. Unterschätzen Sie die Zahl jedoch nicht. Software wird sehr oft von mehr Leuten überprüft, als Sie sich vorstellen können. Der ursprüngliche Entwickler oder die ursprünglichen Entwickler kennen offensichtlich den Code, den sie geschrieben haben. Open Source ist jedoch oft eine Gruppenarbeit. Je länger Code offen ist, desto mehr Softwareentwickler sehen ihn. Ein Entwickler muss große Teile des Codes eines Projekts überprüfen, da er eine Codebasis erlernen muss, um neue Funktionen dafür zu schreiben.

Auch Open-Source-Packager engagieren sich in vielen Projekten, um diese einer Linux-Distribution zur Verfügung zu stellen. Manchmal kann eine Anwendung gepackt werden, ohne mit dem Code vertraut zu sein, aber oft wird ein Paketierer mit dem Code eines Projekts vertraut, sowohl weil er Software, der er nicht vertraut, nicht abmelden möchte, als auch weil er möglicherweise Änderungen vornehmen muss um es richtig zu kompilieren. Fehlerreporter und Triager machen sich manchmal auch mit einer Codebasis vertraut, wenn sie versuchen, Anomalien zu lösen, die von Macken bis hin zu schwerwiegenden Abstürzen reichen. Natürlich decken einige Fehlerreporter unabsichtlich Code-Schwachstellen auf, nicht indem sie sie 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 ausschließlich in Code graben, um potenzielle Exploits aufzudecken.

Vertrauen und Transparenz

Manche Leute gehen davon aus, dass es im Grunde unmöglich ist, Software zu auditieren, weil große Software aus Hunderttausenden von Codezeilen besteht. Lassen Sie sich nicht davon täuschen, wie viel Code erforderlich ist, um eine Anwendung zum Laufen zu bringen. Sie müssen nicht wirklich Millionen von Zeilen lesen. Code ist stark strukturiert, und ausnutzbare Fehler sind selten nur eine einzelne Zeile, die unter Millionen von Zeilen verborgen ist; es sind normalerweise ganze Funktionen beteiligt.

Ausnahmen gibt es natürlich. Manchmal wird eine schwerwiegende Schwachstelle mit nur einem Systemaufruf oder durch die Verknüpfung mit einer fehlerhaften Bibliothek aktiviert. Glücklicherweise sind solche Fehler dank der aktiven Rolle von Sicherheitsforschern und Schwachstellendatenbanken relativ leicht zu erkennen.

Einige Leute verweisen auf Bug-Tracker, wie die Website Common Vulnerabilities and Exposures (CVE), und folgern, dass Open Source nicht sicher ist. Schließlich werden Hunderte von Sicherheitsrisiken für viele Open-Source-Projekte offen für jedermann angezeigt. Lassen Sie sich davon jedoch nicht täuschen. Nur weil Sie die Fehler in geschlossener Software nicht sehen, heißt das nicht, dass diese Fehler nicht existieren. Tatsächlich wissen wir, dass sie es tun, weil auch Exploits gegen sie eingereicht werden. Der Unterschied ist, dass alle Exploits gegen Open-Source-Anwendungen sind für Entwickler (und Benutzer) verfügbar, um diese Fehler zu beheben. Dies ist ein Teil des Systems, der das Vertrauen in Open Source stärkt, und fehlt bei proprietärer Software vollständig.

Es mag nie “genug” Augen auf einen Code geben, 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 an demselben Projekt arbeiten, etwas bemerkt haben nicht sicher aber alle haben gleichermaßen geschwiegen, dass dieser Fehler als gering angesehen wird, da die Menschen selten einvernehmlich einer solchen Verschwörung zustimmen. Wir haben gesehen, wie unzusammenhängend menschliches Verhalten in letzter Zeit mit der Eindämmung von COVID-19 sein kann:

  • Wir alle haben einen Fehler (einen Virus) identifiziert.
  • Wir wissen, wie man die Ausbreitung verhindert (bleib zu Hause).
  • Dennoch breitet sich das Virus weiter aus, weil eine oder mehrere Personen vom Eindämmungsplan abweichen.

Das gleiche gilt für Fehler in der Software. Wenn es einen Fehler gibt, wird ihn jemand, der ihn bemerkt, 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 angewiesen ist. Wenn sich ein Entwickler gegen einen Fehler ausspricht, kann dieser Entwickler bestenfalls dem Ruf der Software schaden, wodurch der Umsatz sinkt, oder schlimmstenfalls von seinem Job entlassen werden. Entwickler, die dafür bezahlt werden, heimlich an Software zu arbeiten, neigen nicht dazu, über ihre Fehler zu sprechen. Wenn Sie jemals als Entwickler gearbeitet haben, haben Sie wahrscheinlich eine NDA unterzeichnet und Sie wurden über die Bedeutung von Geschäftsgeheimnissen usw. unterrichtet. Proprietäre Software fördert und erzwingt sogar bei schwerwiegenden Fehlern 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, vertrauen Sie Code, der vielen Entwicklern ausgesetzt ist, die unabhängig voneinander wahrscheinlich eine Sicherheitsanfälligkeit äußern.

Open Source ist nicht von Natur aus sicherer als proprietäre Software, aber die Systeme, die das Problem beheben, sind viel besser geplant, implementiert und personell ausgestattet.

Das Linus-Gesetz für Open-Source-Sicherheit verstehen

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top