Bericht Updates unter Linux: Paketmanager NIX aktualisiert (fast) alles

[Kuristina]

Und ich dachte, da kommt noch was Spektakuläres. 🙂
Aber wenn hier schon alles steht, ist ja prima.

 

[Snakeeater]

Ja, das geht sogar mit einem Microsoft Account.

Wie ich schon sagte, keinerlei Vorteile.

Das kann einfach nicht ernst gemeint sein. Warum tut man nichts gegen die Trolle in diesem Forum. Das ist Menschenverdummung.

Ergänzung (23. Juni 2023)

Wer das Konzept von Nix spannend findet, sollte sich definitiv auch mal Guix anschauen. Das ist quasi das gleiche Prinzip nur in einer anderen Sprache (Lisp-Dialekt) umgesetzt und ausschließlich mit freier Software (Teil des GNU-Projekts).

Ich verwende Guix seit drei Jahren als Distribution ("Guix System" analog zu NixOS) auf meinem Hauptrechner. Sowie auf zwei Servern. Gerade dort macht das richtig Spaß, wenn man mal die initiale Konfiguration hinter sich hat

Dazu gefällt mir das UI besser, finde z.B. "guix install hello" etwas intuitiver als "nix-env -iA nixpkgs.hello".

Ich bin auch vor einiger Zeit über Guix gestolpert und fand es recht interessant, habe es aber noch nicht ausprobiert.

Kannst du mal beschreiben was du so alles mit deinem Hauptrechner machst? Spielst du an dem Gerät auch? Wie sieht es mit der Paketaktualität aus?

 

[andy_m4]

OpenSSL ist ein gutes Beispiel. Beim Fedora Update ging deswegen mein VPN-Client kaputt, weil der private Schlüssel in einem alten Format gespeichert ist, das jetzt als unsicher gilt und in OpenSSL 3 deaktiviert wurde.

Ehrlich gesagt sehe ich das nicht als "Bug", sondern als "Feature". Wenn dann die Anwendung platzt, dann merkt man wenigstens mal, mit was für nen unsicheren Schrott man die ganze Zeit gefahren ist und was von der jeweiligen Anwendung zu halten ist.

Theoretisch ja. Bis die WebUi irgendein Element erfordert, dass das neue Electron nicht mehr unterstützt.

Naja. Das begründet ja trotzdem nicht, warum man immer und in jedem Fall alles inkludiert mit installiert.
Und auch beim shared-Ansatz kann man ja solche Dinge abdecken und verschiedene Versionen gleichzeitig installiert haben und Programm A Version 1 benutzen lassen und Programm B Version 2.
Zumal das ja immer auch nur Übergangsweise ist, weil neue Versionen fixen ja auch Bug (die mitunter sicherheitsrelevant sind). Da sollte sowieso programmseitig baldmöglichst nachgezogen werden.

Und ja. In der Praxis geschieht das nicht immer so, wie es wünschenswert wäre. Python ist da so ein berüchtigter Kandidat. Da trifft man heute noch Abhängigkeiten auf Python 2.7
Und im Grunde genommen finde ich es gut, wenn dann solche Dinge offenbar werden, als wenn sie silent jahrelang mitlaufen, weil jeder hübsch seine benötigten Dinge selbst mit liefert und man dadurch gar keinen Überblick hat, was für ranzige Versionen da auf dem System schlummern.

 

[floTTes]

Dieser deklarative Ansatz ist ja der Hammer! Für Single-User vielleicht jetzt weniger, aber als Software-Deployment-Methode schon sehr!

 

[jonsger]

Ziehst du das wirklich konsequent durch und konfigurierst dein System ausschließlich via zentraler Konfiguration?

Vor allem am Desktop... bedeutet dies, dass du dein Hintergrundbild nicht via Gnome/KDE/whatever-Lösung setzt sondern auch via deklarativer Konfigurationsdatei? Du willst ja schließlich irgendwann einmal dein System exakt so wie es gerade ist nachbauen können, nicht wahr? ;-)

Sagen wir mal so weit wie möglich. Mittlerweile gibt es ja guix home damit kann man dann auch dotfiles und so Zeugs mit Guix verwalten. Das mach ich tatsächlich noch nicht, weil es noch recht neu ist und ich mir noch nicht die Zeit genommen habe.
Gut als DE hab ich sway da ist auch nicht so viel zu konfigurieren.

In der Arbeit verwende ich Ansible um "normale" Linux-Systeme zu administrieren. Da bin ich dann wie du beschrieben hast unterwegs. Grade beim Löschen ist das in Ansible nicht mehr ganz so elegant.

Auf meinen zwei privaten Servern verwende ich Guix System aber ziemlich konsequent. Grade auf Server-VMs macht Guix schon relativ viel Spaß, weil man da ja für den Betrieb eigentlich keine unfreie Software/Firmware benötigt wie auf nem Desktop/Laptop oder baremetal-Server.

Ergänzung (25. Juni 2023)

Kannst du mal beschreiben was du so alles mit deinem Hauptrechner machst? Spielst du an dem Gerät auch? Wie sieht es mit der Paketaktualität aus?

Ich mach jetzt nicht zu anspruchsvolle Dinge: Browsen, Filme schauen, E-Mail mit Thunderbird, Messaging Dienste (Signal, Telegram, Matrix), bisschen LibreOffice, mal was mit GIMP zurecht schneiden und in der Konsole an Guix und anderen Dingen rumbasteln.

Spielen tu ich tatsächlich nicht, aber das geht mittlerweile auch halbwegs. Es gibt in einem Zusatzrepo (Channel/Kanal im Guix-Sprech) Pakete für Steam und den proprietären Nvidia-Treiber. Ich hab das noch nie verwendet, aber das funktioniert glaube ich
Ich muss aber auch zugeben, dass ich noch ein Laptop mit openSUSE habe, weil ich zum Beispiel mein Samsung-Drucker nicht mit Guix System zum Laufen kriege.

Guix ist eine Rolling-Release Distro. Pakete mit vielen Abhängigkeiten wie GCC, Mesa oder GTK/QT werden nicht so oft aktualisiert. Die Pakete sind also im Schnitt älter wie bei Arch Linux oder openSUSE Tumbleweed, aber oft neuer wie bei stabilen Distros wie Debian, Ubuntu LTS oder openSUSE Leap.

Kannst dich auch gerne per PN melden, wenns Probleme oder Fragen beim Installieren bzw. ausprobieren gibt

 

[flmr]

Ein signierter Installer sagt aber auch erstmal nur aus, dass der Installer von dem stammt, der im Zertifikat steht. Es trifft keine Aussage darüber, ob der Installer bzw. das damit installierte Programm "sauber" ist.

Was auch genau der Sinn einer Signatur ist.

 

[andy_m4]

Nein. Der Sinn der Signatur ist, das die unterzeichnete "Datei" auch tatsächlich vom Unterzeichner (bzw. dem Besitzer des dazugehörigen Private Keys) stammt und diese Datei auf dem Weg zu Dir auch nicht manipuliert worden ist. Mehr Aussagekraft hat eine Signatur nicht. Ob eine Datei sauber ist, da macht es nur mittelbare Aussagen drüber. Wenn man davon ausgeht das der Unterzeichner sauber ist. Ist der das nicht, weil der sich beispielsweise selbst einen Virus eingefangen hat, dann gilt das halt nicht mehr.

 

[Whistl0r]

An der Stelle sei noch angemerkt, dass die Quelle des Key-Materials dabei auch eine entscheidende Bedeutung hat. Schauen wir uns das am Beispiel Grafana an:

Die aktuelle Grafana-Version ist zum Zeitpunkt an dem ich diesen Beitrag verfasse (04.07.2023) die Version 10.0.1. Das entsprechende Debian-Paket kann von

https://apt.grafana.com/pool/main/g/grafana/grafana_10.0.1_amd64.deb

bezogen werden.

Die offizielle Grafana-Dokumentation empfiehlt folgendes:

sudo apt-get install -y apt-transport-https
sudo apt-get install -y software-properties-common wget
sudo wget -q -O /usr/share/keyrings/grafana.key https://apt.grafana.com/gpg.key

Was ist hierbei das Problem?

Zu erst müssen wir verstehen, weswegen wir überhaupt die Signatur von grafana_10.0.1_amd64.deb prüfen wollen:

• Wir wollen sicherstellen, dass das Paket von Grafana stammt
• Wir wollen sicherstellen, dass das Paket unverändert auf unser System gelangt ist

Wenn wir jetzt aber sowohl das Paket/Signatur als auch den Schlüssel von der gleichen Quelle beziehen,

https://apt.grafana.com/

dann haben wir in dem Moment ein Problem, wo ein Angreifer die Kontrolle über selbige Ressource erlangt hat. Denn wenn wir annehmen, dass der Angreifer das Paket durch sein manipuliertes Paket austauschen kann, dann kann der Angreifer auch den dort abgelegten Schlüssel durch eine Kopie seines Keys ersetzen sowie alles mit seinem Key valide signieren.

Wie geht es besser?

In der Vergangenheit gab es "apt-key" (der Befehl ist nun als veraltet (deprecated) markiert) worüber man, sofern man den Fingerprint kannte, sich den aktuelle GPG-Key von einem beliebigen Keyserver herunterladen konnte.

Warum ist das Verfahren sicherer gewesen?

Weil es ein zweites Medium gab (die Keyserver). welcher der Angreifer hätte manipulieren müssen.

Obacht: Keyserver selbst bieten in der Regel keinen Schutz (keys.openpgp.org ist eine Ausnahme). Jeder kann sich einen Key mit der UID

Grafana Labs <engineering@grafana.com>

wie ihn aktuell Grafana aus unserem Beispiel verwendet erzeugen und hochladen. Deshalb ist die Suche nach UIDs unsicher und daher kann man dem Befehl

gpg --recv-key

auch nur noch einen Fingerprint übergeben -- denn dieser ist eindeutig.

Aber Achtung: Wenn Grafana seinen Fingerprint nun auf apt.grafana.com oder in der Dokumentation veröffentlicht hat, dann sollte man diesen nicht verwenden. Denn nach unserem Threat-Model gehen wir ja davon aus, dass der Angreifer möglicherweise die Kontrolle über diesen Host erlangt und das Paket inkl. Key und Signatur ausgetauscht hat. Wenn die Angreiferin dazu in der Lage ist, dann wird sie auch den angezeigten Fingerprint ersetzen können.

Und wie finde ich dann richtigen Schlüssel?

GPG hat einmal auf dem so genannten "Web of Trust" aufgesetzt. D.h. man ging davon aus, dass die Entwicklerin Jane Doe die bspw. für Grafana die Pakete erstellt, einen GPG-Key erstellt. Jetzt ist Jane Doe nicht alleine auf dieser Welt. Irgendjemand anderes, der auch einen GPG-Key hat, nennen mir wir ihn Max Mustermann, kennt diese Entwicklerin. Persönlich (ganz wichtig!). Dieser Kontakt signiert nun den Key von Jane Doe öffentlich. Eine andere Person die Jane Doe nicht kennt, dafür aber Max Mustermann und dessen Key daher bereits vertraut, wird jetzt auch dem Key von Jane Doe vertrauen, weil dieser von Max Mustermann, dem diese Person wie gesagt bereits vertraut, signiert ist.

Einziges Problem: Das Web of Trust gilt seit dem demonstrierten Angriff 2019 als tot. Und wie dargestellt, fußt es auf echte Kontakte, d.h. ein Key ist einer echten Person zugeordnet. Das skaliert nicht mit CI-Systemen wo es Rollen-Accounts gibt -- denn diese sollte man nie signieren (ich weiß ja nicht, wer Morgen die Kontrolle über den Key hat -- will ich dafür mit meiner Integrität bürgen?).

Einen Punkt über den wir noch gar nicht gesprochen haben ist die Überprüfung des Schlüssels vor Signaturprüfung: Evtl. wurde der Key ja von seinem Aussteller zwischenzeitlich als Kompromittiert zurückgerufen. Das ist leider etwas, was oftmals vergessen wird und meines Wissens selbst zu Zeiten von apt-keys nie gemacht wurde (man könnte zwar

apt-key net-update

aufrufen aber ich bezweifle, dass das irgendwer jemals getan hat). Der neue Weg Mittels

trusted.gpg.d

sieht so etwas gar nicht vor

Fazit: Keys und Signaturen sind eigentlich wichtig. Man muss das System aber verstehen. Vor allem seine Grenzen: Oftmals liest man ja, wenn wieder einmal Malware mit einer gültigen Signatur versehen wurde, dass der ganze Zirkus nur Schlangenöl sei. Das finde ich nicht. Dank der Signatur weiß ich immerhin, "woher" die Datei stammt bzw. wessen Infrastruktur kompromittiert wurde. Etwas was ich nicht wüsste, wenn die Datei gar nicht signiert wäre. Natürlich müssen daraufhin dann Konsequenzen wie Widerruf des Zertifikats etc. folgen.

Es ist auch wichtig zu verstehen, dass man "Trust" nicht automatisieren kann. In dem Moment wo ich also einfach irgendeinen Key bei mir wie auch immer installiere (was leider die meisten Anleitungen tun), kann ich mir das auch alles sparen

Überhaupt ist Verständnis wichtig. Wer bspw. Arch Linux nutzt hat bestimmt schon einmal erlebt, dass der dortige Paketmanager "pacman" fragt, ob man einem besimmten GPG-Key im Rahmen eines Updates vertrauen möchte. Hintergrund ist, dass das besagte Paket von einem neuen, bis dahin unbekannten Key signiert wurde. Ich finde das sehr schwierig: Woher weiß ich, ob das seine Richtigkeit hat? Ich müsste jetzt manuell im Repository von Arch Linux nachschauen um nachvollziehen zu können, ob das seine RIchtigkeit hat. Wer macht so etwas? Die meisten Nutzer werden den Prompt wohl einfach bestätigen ohne zu wissen, dass dieser Key plötzlich als vertrauenswürdig markiert wurde -- nicht nur für dieses eine Mal. Und wenn dann mal etwas schief geht wird sich Arch Linux herausreden mit, "Aber wir haben Dich $User doch gefragt und Du hast JA gesagt..."