Aus LinuxUser 11/2016

Reproducible Builds in Debian (Seite 2)

Neue Werkzeuge

Technische Probleme bei der Reproduzierbarkeit entstehen zu 80 Prozent aufgrund neuer Zeitstempel sowie anderer Zeitzonen und Lokalisierungen.

Viele Build-Werkzeuge zeichnen Daten wie die Zeit und das Datum des Builds in nichtdeterministischer Form auf. Um das zu korrigieren, gibt es die Bibliothek strip-nondeterminism [7]. Sie entfernt im Vorfeld der Builds Informationen, die zu verfälschten Ergebnissen führen könnten (Abbildung 5).

Abbildung 5: Werkzeugkoffer: Die wichtigsten Tools im Rahmen des Reproducible-Builds-Projekts.
Abbildung 5: Werkzeugkoffer: Die wichtigsten Tools im Rahmen des Reproducible-Builds-Projekts.

Um diese durch deterministische Werte zu ersetzen, wurde die Source_Date_Epoch [8] ersonnen. Dieser Zeitstempel definiert in einem String die Sekunden seit der letzten Modifikation des Quelltexts nach dem 1. Januar 1970, 0 Uhr UTC, also dem Start der Unix-Zeit.

Allerdings lassen sich nicht alle Probleme automatisiert lösen, sodass insgesamt noch viel Handarbeit ansteht. Zu den hier verwendeten Praktiken findet sich eine ausführliche Dokumentation [9]. Zum weiteren Handwerkszeug bei der Suche danach, warum sich ein Paket nicht reproduzierbar erstellen lässt, gehört an prominenter Stelle auch Diffoscope [10]. Mit diesem Werkzeug lassen sich Dateien oder Ordner in der Tiefe vergleichen (Abbildung 6). Dazu entpackt das Programm Archive und transformiert Binärpakete in von Menschen lesbare Formate.

Abbildung 6: Diffoscope erlaubt tiefgehende Vergleiche zur Fehlerfindung. Hier untersucht es zwei Firefox-Extensions.
Abbildung 6: Diffoscope erlaubt tiefgehende Vergleiche zur Fehlerfindung. Hier untersucht es zwei Firefox-Extensions.

Reproduzierbare Builds stellen einen wichtigen Schritt auf dem Weg zu jener Art von Sicherheit dar, die wir künftig brauchen, um die Integrität unseres digitalen Daseins zu verbessern. Als Allheilmittel taugen sie aber nicht: Geheimdienste und organisierte Kriminelle verfügen über Mittel, uns manipulierte Software unterzuschieben, gegen die es kaum eine Gegenwehr gibt.

Ein Beispiel dafür liefert die bereits 1974 erstmals beschriebene Trusting-Trust-Attacke [11]: Dabei manipuliert der Angreifer die Binärdatei eines Compilers dergestalt, dass sie sich erst einmal selbst neu kompiliert und der so manipulierte Compiler dann auf kaum erkennbare Weise veränderte Software ausspuckt, die beispielsweise Backdoors oder andere Gemeinheiten enthält.

Ein Bit genügt

Auch Ken Thompson [12], einer der legendären Väter von Unix, machte in einer amüsant zu lesenden Rede [13] anlässlich einer Preisverleihung klar, dass es keine absolut sichere Software gibt – es sei denn, man schreibt einen eigenen Compiler und baut alle Software selbst. Denn oft macht ein einziges Bit in einem 500 KByte großen Binärpaket den Unterschied zwischen einer sicheren und einer angreifbaren Software aus.

Dies belegten Tor-Entwickler in einem Vortrag [14] auf dem Chaos Computer Congress 2014 (31c3) anhand eines Fehlers im Netzwerkprotokoll SSH aus dem Jahr 2002 (CVE 2002-0083). Dort entschied ein einziges Bit darüber, ob sich jemand Root-Rechte auf der Maschine erschleichen konnte. Der Vortrag führte darüber hinaus einen Angriff vor, bei dem der Code eines Kernel-Moduls lediglich im Speicher geändert wurde. Auf dem Bildschirm erschien er dabei völlig intakt, das resultierende Binärpaket jedoch war kompromittiert.

Um solche und ähnliche Angriffe zu verhindern, begann die Idee der reproduzierbaren Builds zuerst bei Projekten wie Tor und Bitcoin Gestalt anzunehmen, da dort Sicherheit und Vertrauen eine zentrale Rolle spielen. Beide Projekte lassen sich seit 2012 gänzlich reproduzierbar bauen. Als Grundlage dafür dient Gitian [15], eine Distributionsmethode, die einen deterministischen Build-Prozess in einem Container oder einer virtuellen Maschine darstellt.

Mithilfe von Gitian Builder [16] bauen mehrere Personen unabhängig voneinander und der Umgebung das Paket. Stimmt alles, führt dies zu bitgenau identischen Binärpaketen. Für kleinere Projekte reicht Gitian aus, für eine komplette Distribution wie Debian mit zigtausenden Quellpaketen lässt es sich allerdings aufgrund des damit verbundenen Zeit- und Personalaufwands nicht gebrauchen.

Fazit

Bei den Distributionen nimmt Debian eine Vorreiterrolle in Sachen überprüfbare Pakete ein. Die dabei geschaffene Infrastruktur in Jenkins greifen mittlerweile andere Distributionen ebenso auf wie die Werkzeuge zum Lösen von Problemen und Überprüfen der Ergebnisse. So können etwa Fedora, OpenSuse oder Arch Linux die Ergebnisse von Debian verifizieren und umgekehrt.

Im letzten Jahr fand in Athen dazu ein distributionsübergreifendes Arbeitstreffen mit über 40 Teilnehmern statt, auch in diesem Jahr soll wieder eines stattfinden (Abbildung 7). Anfang August vermeldeten die Entwickler von Hardened GNU/Linux [17] – sie härten den Linux-Kernel mit PaX/Grsecurity – die Verfügbarkeit von Patches, um PaX/Grsecurity reproduzierbar zu bauen.

Abbildung 7: Auch 2016: europäisches Entwicklertreffen und GSoC-Beteiligung.
Abbildung 7: Auch 2016: europäisches Entwicklertreffen und GSoC-Beteiligung.

Damit entsteht Schritt für Schritt ein Netz des Vertrauens, das reproduzierbare Builds auch für solche Anwender vertrauenswürdig macht, die nicht selbst überprüfen möchten oder können, ob sich zwei Pakete bis aufs Bit gleichen. Die künftige Ausgestaltung des gesamten Prozesses und des Ergebnisses bedürfen weiterer Klärung – doch diese Probleme lassen sich lösen, sobald es erst einmal ein fast vollständig reproduzierbares Archiv gibt. 

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 5 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
KAUFEN
LinuxUser 11/2016 KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS
Deutschland

Hinterlasse einen Kommentar

  E-Mail Benachrichtigung  
Benachrichtige mich zu: