19 Sicherheitsaktualisierungen

Ab und zu werden wichtige Sicherheitsschwachstellen in Software-Paketen entdeckt, die mit Patches behoben werden müssen. Guix-Entwickler geben ihr Bestes, bezüglich bekannter Schwachstellen auf dem Laufenden zu bleiben und so bald wie möglich Patches dafür auf den master-Branch von Guix aufzuspielen (einen stabilen „stable“-Branch ohne riskante Änderungen haben wir noch nicht). Das Werkzeug guix lint hilft Entwicklern dabei, verwundbare Versionen von Softwarepaketen in der Distribution zu finden:

$ guix lint -c cve
gnu/packages/base.scm:652:2: glibc@2.21: Wahrscheinlich angreifbar durch CVE-2015-1781, CVE-2015-7547
gnu/packages/gcc.scm:334:2: gcc@4.9.3: Wahrscheinlich angreifbar durch CVE-2015-5276
gnu/packages/image.scm:312:2: openjpeg@2.1.0: Wahrscheinlich angreifbar durch CVE-2016-1923, CVE-2016-1924
…

Siehe guix lint aufrufen für weitere Informationen.

Guix verfolgt eine funktionale Disziplin bei der Paketverwaltung (siehe Einführung), was impliziert, dass bei jeder Änderung an einem Paket jedes davon abhängige Paket neu erstellt werden muss. Ohne einen Mechanismus würde das Ausliefern von Sicherheitsaktualisierungen in Kernpaketen wie libc oder Bash dadurch deutlich verlangsamt – schließlich müsste quasi die gesamte Distribution neu erstellt werden. Vorerstellte Binärdateien zu benutzen, wäre schon einmal eine Hilfe (siehe Substitute), aber die Auslieferung wäre immer noch laangsamer, als wir es uns wünschen.

Als Gegenmittel sind in Guix Veredelungen implementiert. Diese stellen einen Mechanismus dar, mit dem kritische Aktualisierungen schnell an Guix’ Benutzer ausgeliefert werden können, ohne die Nachteile, zu denen es käme, wenn wir die gesamte Distribution neu erstellen müssten. Die Idee dahinter ist, nur das Paket, das einen Patch braucht, neu zu erstellen, und damit dann Pakete, die der Nutzer ausdrücklich installiert hat und die vorher Referenzen auf das alte Paket enthielten, zu „veredeln“. So eine Veredelung kostet typischerweise nur sehr wenig, d.h. um Größenordnungen weniger, als die ganze Abhängigkeitskette neu zu erstellen.

Nehmen wir also an, eine Sicherheitsaktualisierung müsste auf Bash angewandt werden. Guix-Entwickler schreiben dann eine Paketdefinition für die „reparierte“ Bash, sagen wir bash-fixed, auf die gleiche Art wie immer (siehe Pakete definieren). Dann wird die ursprüngliche Paketdefinition um ein replacement-Feld (zu Deutsch „Ersetzung“) erweitert, das auf das Paket verweist, in dem der Fehler behoben wurde:

(define bash
  (package
    (name "bash")
    ;; …
    (replacement bash-fixed)))

Ab diesem Zeitpunkt wird jedes Paket, das Sie installieren und das direkt oder indirekt von Bash abhängt – also die von guix gc --requisites ausgegebenen Pakete (siehe guix gc aufrufen) –, automatisch „umgeschrieben“, so dass es bash-fixed referenziert, wo es vorher bash referenziert hatte. Die Dauer dieses Veredelungsprozesses ist proportional zur Größe des Pakets und liegt auf einer neuen Maschine für ein „durchschnittliches“ Paket bei unter einer Minute. Veredeln ist rekursiv: Wenn eine indirekte Abhängigkeit veredelt werden muss, „propagiert“ der Veredelungsprozess durch die abhängigen Pakete und endet mit dem Paket, das der Nutzer installiert.

Zurzeit muss der Name und die Version einer Veredelung gleichlang wie die beim ersetzten Paket sein (also bei bash-fixed und bash im Beispiel oben). Diese Einschränkung kommt daher, dass beim Veredeln der Inhalt von Dateien, einschließlich Binärdateien, durch einfache Ersetzungen „geflickt“ wird. Es gibt noch mehr Einschränkungen: Wenn zum Beispiel ein Paket veredelt wird, das eine gemeinsame Bibliothek („Shared Library“) verwendet, muss der SONAME von Original und Ersatz derselbe sein und die beiden müssen binär kompatibel sein.

Mit der Befehlszeilenoption --no-grafts können Sie den Veredelungsmechanismus zwingend abschalten (siehe --no-grafts). Der Befehl

guix build bash --no-grafts

liefert also den Namen der Store-Datei mit der ursprünglichen Bash, während

guix build bash

den Namen der Store-Datei für die „reparierte“ Ersatz-Bash liefert. Dadurch können Sie zwischen den beiden Varianten von Bash unterscheiden.

Um zu prüfen, welche Bash Ihr gesamtes Profil referenziert, können Sie diesen Befehl hier laufen lassen (siehe guix gc aufrufen):

guix gc -R $(readlink -f ~/.guix-profile) | grep bash

Dann vergleichen Sie die Namen der Store-Objekte, die Sie ausgegeben bekommen, mit den beiden Bash-Paketnamen oben. Ebenso können Sie eine ganze Guix-Systemgeneration überprüfen:

guix gc -R $(guix system build my-config.scm) | grep bash

Zum Schluss können Sie mit dem Befehl lsof überprüfen, welches von den Bash-Paketen die laufenden Prozesse benutzen:

lsof | grep /gnu/store/.*bash