Wenn ein Schüler bei der Lösung einer Prüfungsaufgabe den falschen Lösungsweg wählt, aber dennoch das richtige Ergebnis erzielt, soll er dann vom Lehrer die volle Punktzahl für seine Lösung erhalten oder nur einen Teil oder gar keine Punkte? Das hängt davon ab, wie die Prüfung aufgesetzt wurde: Im «Multiple Choice»-Stil zählt nur das richtige Ergebnis – also der Effekt – während bei der Beurteilung nach Verständniskriterien auch dann eine hohe Punktzahl möglich ist, wenn der Algorithmus richtig, das Rechenergebnis aber falsch ist. Den Lösungsweg zu evaluieren ist für den Lehrer aber ungleich aufwendiger, als nur das Ergebnis zu prüfen.
Bei der Diskussion über Softwarequalität ist das ähnlich. In der Regel sind wir nur am offensichtlichen Effekt interessiert, den die Software auslöst – das mag ein Rechenergebnis sein oder eine Übermittlung oder aber das Auslesen einer Datenbank zur Erstellung eines Berichts. Wir sind nur selten an den Seiteneffekten interessiert, also an denjenigen Aktivitäten, die ein Programm zusätzlich durchführt, beispielsweise der Übermittlung von statistischen Daten an den Softwarehersteller, oder der Abfrage ganzer Verzeichnisbäume aus dem angeschlossenen Active Directory, wenn doch nur einzelne Zugriffe notwendig wären.
Wenn wir solche unerwünschten Abweichungen vermuten, können wir ein Programm «unter Quarantäne» stellen, also im Sinne einer «Black Box»-Prüfung alle Ein- und Ausgänge beobachten. Dennoch werden wir so nie feststellen können, ob es sich beim verdächtigen Verhalten nur um einen Programmierfehler oder um eine absichtliche Fehlfunktion handelt, und auch in Quarantäne sind wir darauf angewiesen, dass die unerwünschten Funktionen aktiv werden, um sie überhaupt beurteilen zu können. Wenn wir wirklich wissen sollen, was in einem Programm vorgeht, benötigen wir den Source Code, und müssen ihn analysieren.
Schwierige Code-Prüfung
Es ist bekannt, dass Linux und andere Open Source Software heute omnipräsent ist und auch, dass gemäss der Lizenz-Bestimmungen, unter denen sie steht (z.B. GPL), bei jedem Produkt, das sie enthält, der Source Code mitgeliefert werden muss. Die Programmiersprachen, in denen der Linux-Kernel und die vielen zugehörigen Programme geschrieben wurden, sind Standard-Technologien, die jeder Informatik-Absolvent beherrscht. Und doch: Wer hat sich schon einmal die Mühe gemacht, den Source Code tatsächlich zu betrachten? Er würde alles offenbaren: die Qualität der eingebauten Verschlüsselungsalgorithmen, die Zugriffe auf Dateisysteme und Netzwerkknoten, die Effizienz der Speichernutzung, oder die Verfahren, mit denen die Echtheit von Benutzern oder anfragenden Kommunikationspartnern geprüft wird.
Die weitaus meisten Benutzer nehmen einfach blind an, dass das alles schon seine Richtigkeit habe, und nur in Ausnahmefällen – insbesondere in besonders sicherheitskritischen Bereichen – wird der Aufwand getrieben, die Qualität durch Analyse des Source Codes zu evaluieren. Dabei steht ein ernsthafter Prüfer aber gleich vor mehreren Hürden. Die erste ist, dass für viele heute eingesetzte Programme, vor allem auch für die omnipräsenten Produkte der grossen Hersteller Microsoft, Apple, Oracle oder Cisco, der Source Code gar nicht, oder nur unter strengen Auflagen verfügbar ist.
Viele Hersteller proprietärer Produkte sind überzeugt, dass eine Source-Code-Freigabe nur ihrer Konkurrenz nutzen würde, um die enthaltenen Algorithmen abzukupfern und ihrerseits in geschlossenen Produkten wieder auf den Markt zu bringen. Zudem unterliegt Software dem Copyright, und viele Komponenten proprietärer Produkte werden eingekauft und wiederverkauft, so dass die Einholung einer Erlaubnis zur Publikation des Source Codes eines solchen Teilsystems aufwendig sein und immer noch abgelehnt werden kann – oder die Quelle des Codes gar nicht einmal mehr eruiert werden kann.
Doch auch wenn der Source Code für eine Prüfung zur Verfügung steht, kann jede einzelne prüfende Person immer nur einen Bruchteil eines komplexen Systems in genügendem Detail betrachten. Zudem muss ihr das Know-how für alle im Source Code verwendeten Technologien und Algorithmen während der Prüfung verfügbar sein. Schon bei kleinen zu prüfenden Systemen müssen also viele Fachleute im Verbund arbeiten. Schliesslich muss auch sichergestellt werden, dass der geprüfte Source Code auch tatsächlich zu dem kompiliert wird, was später als Binärobjekt durch den Computer ausgeführt wird. Hier kommen Compiler ins Spiel, die zwar selbst Open Source sein können (und entsprechend geprüft werden müssten), aber oft aus sich selbst heraus gewachsen sind und durchaus versteckten Binärcode enthalten können, der wiederum Sicherheitslöcher in jedes von ihm übersetzte Programm einbaut.
Im Interesse des Kunden?
Wie komplex ein solches im Detail geprüftes und für vertrauenswürdig befundenes Stück Software auch ist, so ist seine Sicherheit doch immer auch vom Kontext abhängig, in dem es ausgeführt wird. Bei Standard-PC- und Server-Technologie kommen so gut wie immer – auch bei Linux – proprietäre Treiber für alle möglichen Komponenten zum Einsatz, seien es Grafik-, Netzwerk- oder Speichersubsystem-Treiber. Weiterhin sind die in die Computer integrierten Input-Output-Hardware-Subsysteme inzwischen so komplex, dass sie über eigene Prozessoren und Speicher verfügen und im Prinzip jede Kommunikation verändern, unterdrücken oder kopieren können, ohne dass das Betriebssystem das mitbekommt.
Bei all diesen Komponenten stellt sich nicht nur die Frage nach dem Source Code – der in der Regel nicht verfügbar ist – sondern auch nach der Motivation des jeweiligen Herstellers. Grundsätzlich liegt ihm daran, die Interessen seiner Kunden zu wahren. Es ist aber spätestens seit letztem Sommer bekannt, dass jedes noch so seriöse US-amerikanische Unternehmen durch die Behörden zur Konspiration und Kollusion gezwungen werden kann. Abgesehen davon, dass viele der von uns täglich verwendeten Schlüsseltechnologien US-amerikanischen Ursprungs sind, sind von diesen rechtlichen Vorgaben nicht nur die grössten Hardware-Hersteller betroffen, sondern auch die Open-Source-Software-Verteiler Red Hat und Suse (Teil von Novell), da sie US-amerikanische Firmen sind.
Lecks in Open-Source- Programmen
Tatsächlich wurden in der Vergangenheit auch in Open-Source-Programmen verschiedener Distributoren Sicherheitslücken entdeckt, deren Herkunft und Tragweite die Fachleute staunen liessen (z.B. in OpenSSH oder in den OpenSSL-Bibliotheken, die von vielen Verschlüsselungsprodukten verwendet werden). Das Vorkommen solcher effektiver Schwachstellen in Open Source Software ist aufgrund des Viel-Augen-Prinzips nicht erwartet worden – schliesslich könnte ja jeder Nutzer der Software den Source Code prüfen. Offensichtlich hat das aber lange niemand getan. Es erstaunt deshalb nicht, dass in Sicherheitskreisen davon ausgegangen wird, es sei viel einfacher, verschlüsselte Daten vor ihrer Verschlüsselung oder nach ihrer Entschlüsselung abzufangen, als einen verschlüsselten Text zu knacken.
Obwohl es also offensichtlich ist, dass nur durch die konsequente Analyse des Source Codes einer Software festgestellt werden kann, ob sie vertrauenswürdig ist, so ist es doch praktisch unmöglich, durch ein solches Vorgehen praktische Aussagen zur Sicherheit eines Gesamtsystems abzugeben. Zu gross ist der Aufwand, zu divers das notwendige Know-how, zu komplex die ausführende Umgebung und zu gross die möglichen Störeinflüsse.
Mitgestalten und kontrollieren
Es gibt jedoch noch einen weiteren Qualitätsaspekt von Open Source, der hier noch nicht angesprochen wurde: Kontrollierbarkeit. Damit ist gemeint, dass eine Software, deren Source Code verfügbar ist, ungleich flexibler an konkrete Umgebungsanforderungen angepasst werden kann, als eine proprietäre Software, deren Quellcode nicht vorliegt. Vor allem in Organisationen, in denen vielfältige, komplexe Systeme betrieben, gewartet und vielfach untereinander vernetzt werden müssen, aber auch neue Software kontinuierlich und schnell integriert und in den Betrieb überführt werden muss, hat die Verfügbarkeit und Anpassbarkeit von Source Code dermassen viele Vorteile, dass ein eigener Fachbereich für diese Art von «Power Providing» entstanden ist: Das sogenannte Devops.
Und so kann nur empfohlen werden, was der gesunde Menschenverstand ohnehin schon festgestellt hat: Richten wir uns auf eine Welt ein, in der jedes System nicht nur einem gewünschten, sondern auch einem verdeckten Anspruch genügt, und in der es einer interessierten, motivierten, mit geringen Mitteln und dem Mut für Rechtswidrigkeit ausgestatteten Partei immer möglich sein wird, weltweit beliebige Informationen zu erhalten, ohne dass deren jeweiliger Eigentümer das möchte. Aber auch auf eine Welt, in der es uns durch eigenes Engagement zunehmend möglich ist, auch komplexe Informationsverarbeitungen selbst zu kontrollieren, indem wir mit Open Source dazu beitragen, in der wir lernen, selbst Software zu schreiben und so die Welt ein bisschen mitgestalten.
