Tag: Pacman

Posted on

Arch Linux: Paketsignaturen mit GnuPG und Pacman 4

Vor drei Tagen wurde auf archlinux.org die gute Nachricht verkündet, dass Archs neuer Paketmanager Pacman 4 nun in den "Core"-Paketquellen verfügbar ist. Ich hatte im letzten September noch laut über die Sicherheitsarchitektur der Paketverwaltung nachgedacht und damals die Diskussion zu dem Thema näher verfolgt, die schon vor Jahren angestoßen wurde aber erst durch einen kritischen lwn.net Artikel an Fahrt gewann.
Währenddessen war man nicht untätig und 893 commits von 24 Helfern später, ist es nun gelungen eine Reihe von neuen Feature zu implementieren, darunter eben auch das Signieren von Paketen mit GnuPG.
Zuerst fiel mir auf, dass ich yaourt und dessen Abhängigkeit package-query vor einem Systemupgrade entfernen musste, da package-query auf Pacman in einer Version < 3.6 angewiesen war. Danach wurde zuerst Pacman aktualisiert, bevor ich mir das neue Sicherheitskonzept näher anschauen konnte.
Als erstes sollte man den neuen GnuPG Schlüsselbund mit pacman-key --init anlegen. Zum Thema Package Signing und Pacman-Key gibt es schon einen hilfreichen Eintrag im Wiki. Ausführlich wird der gesamte Prozess auch auf Allan McRaes Homepage erläutert.
Nachdem mit pacman-key sowohl Schlüsselbund und ein Grundgerüst an Konfigurationsdateien angelegt worden ist, kann man in /etc/pacman.conf seine persönlichen Vorstellungen von Sicherheit einstellen. Zur Zeit ist das Überprüfen der Paketsignaturen nämlich noch mit der Variablen SigLevel = Never abgeschaltet.
Mit SigLevel = Optional TrustedOnly werden Pakete auf ihre Signaturen hin überpüft, jedoch muss man jedem unbekannten Schlüssel noch einzeln vertrauen. Eine typische Fehlermeldung sieht dann am Anfang so aus:

pacman -S transmission-gtk
resolving dependencies...
looking for inter-conflicts...
Targets (1): transmission-gtk-2.42-2
Total Download Size: 0.61 MiB
Total Installed Size: 2.57 MiB
Proceed with installation? [Y/n]
:: Retrieving packages from extra...
transmission-gtk-2.42-2-i686 625.7 KiB 410K/s 00:02 [########################################] 100%
(1/1) checking package integrity [########################################] 100%
error: transmission-gtk: key "E8F18BA1615137BC" is unknown
:: Import PGP key 615137BC, "Ionut Biru ", created 2011-04-19? [Y/n] n
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

Deswegen sollte man zuerst die sogenannten MasterKeys importieren. Diese fünf Hauptschlüssel werden dazu benutzt um die Schlüssel anderer ArchLinux-Entwickler zu unterschreiben. Gemäß dem Web of Trust ist das marginale Vertrauen in drei dieser Schlüssel ausreichend, um einen anderen mit ihnen unterschriebenen Schlüssel als gültig anzusehen. Selbst im schlimmsten Fall, wenn zwei der MasterKeys widerrufen werden müssten, wäre also das Sicherheitskonzept weiter in Takt.
Problematisch ist momentan die Verteilung dieser Schlüssel. Es gibt z.B. noch kein pacman-keyring Paket, mit welchem alle GnuPG-Schlüssel automatisch und benutzerfreundlich eingerichtet werden können. Außerdem haben noch nicht alle ArchLinux-Entwickler ihre GnuPG-Schlüssel unterschreiben lassen, weswegen es zu Warnmeldungen kommt. Dies ist auch der ausschlaggebende Grund, warum Arch Linux mit Pacman 4 standardmäßig noch auf die Validierung verzichtet.
Eine einfache Möglichkeit die fünf MasterKeys zu importieren, ist diese For-Schleife zu benutzen.

for key in FFF979E7 CDFD6BB0 4C7EA887 6AC6A4C2 824B18E8; do
pacman-key --recv-keys $key
pacman-key --lsign-key $key
printf 'trustn3nquitn' | gpg --homedir /etc/pacman.d/gnupg/
--no-permission-warning --command-fd 0 --edit-key $key
done

Halten wir mal fest, dass Arch Linux einen großen Schritt in Sachen Paketsicherheit nach vorne gemacht hat. Es braucht aber noch den letzten Feinschliff in den kommenden Wochen, um das Vertrauen in das neue System auch tatsächlich herzustellen.

Posted on

Ein Debianbenutzer zu Besuch bei Arch Linux

Auch wenn ich mich in Sachen Arch Linux oft wiederhole. Beißt euch durch die Installation durch, bleibt dran und gebt nicht auf - ganbatte kudasai!. Sie ist wirklich gut im englischen oder deutschen Arch Linux Wiki erklärt. Nachdem man diese vermeintliche Hürde nämlich genommen hat, stellt man plötzlich fest, dass man für den Rest der Lebenszeit seines Computers nicht mehr daran denken muss. Genauso wie bei Debian Unstable oder Testing ist Arch eine fortlaufend aktualisierte Distribution, weswegen der Teil mit der Installation wirklich nur einen Bruchteil der Zeit am Rechner ausmacht. Wie versprochen ist hier ein erster Eindruck, was mir bei regelmäßiger Benutzung von Arch auf dem Inspiron 4000 aufgefallen ist.

Das Netzwerk

Nachdem man den Installationsschritten gefolgt ist, muss man sich als Neuankömmling erst einmal ein paar Problemen stellen. Eine Interfaces Datei für Arch Linux gibt es nicht. Ist die nicht sogar bei Debian schon "deprecated"? Am leichtesten geht es, wenn man direkt in der /etc/rc.conf eine einzelne Netzwerkschnittstelle einrichten möchte. Für statische oder dynamische IP-Adressen-Konfiguration ist hier der richtige Ort.
Wenn es komplizierter werden soll aufgrund mehrerer Netzwerkkarten, sollte man sich netcfg anschauen. Ein Verhalten, das erst einmal gewöhnungsbedürftig ist falls man Befehle wie ifconfig, ifup und ifdown sofort nach einer Minimalinstallation von Debian gewohnt ist. Für einen Laptop gefällt mir außerdem noch Wicd, mit dem sich übersichtlich drahtlose Netzwerke einrichten lassen.

Aptitude und Pacman

Arch Linux ist kaputt, denn es hat kein Apt. Wahre Worte. 😛 Pacman ist zwar nicht Apt, erfüllt aber ähnliche Aufgaben, die man auch von Apt gewohnt ist. Die wichtigsten Befehle für den Anfang sind:

  • pacman -Syu : Das komplette System auf den neuesten Stand bringen
  • pacman -S "Paketname": Ein Paket installieren
  • pacman -Ss "Suchbegriff" : Nach einem Begriff/Paket suchen
  • pacman -Sc : Den Paketcache leeren
  • pacman -Rs "Paketname" : Ein Paket und dessen Abhängigkeiten entfernen, sofern sie nicht von anderen Paketen gebraucht werden

Man vermisst zwar ein wenig Aptitudes exzellente Suchfähigkeiten, bisher konnte ich mein Arch trotzdem immer nach meinem Geschmack einrichten.

Kleine Unterschiede

Arch Linux bezeichnet sich selbst als eine Keep-it-simple-Distribution. Das geht soweit, dass das Patchen von Dateien bis auf ein absolut notwendiges Minimum reduziert wird. In der Regel werden neue Feature und Sicherheitsaktualisierungen durch den jeweiligen Upstream-Autor erstellt und dann umgehend als Arch-Linux-Paket bereitgestellt. Das kann aber auch dazu führen, dass einige Fähigkeiten, die man aus Debian kennt, plötzlich nicht mehr funktionieren.
Am Beispiel scrot, dem Screenshot Programm, wird das ziemlich deutlich. In der Arch Version gibt es den Patch zum gezielten Aufnehmen eines Fensters, in der offiziellen Version leider nicht. (-u) Dafür wird eine inoffizielle Version in AUR bereitgestellt. Wie gut sie wirklich ist, lässt sich nur durch Ausprobieren feststellen. Im Moment hat sie nur zwei Bewertungspunkte.

Pakete aus AUR - der leichte Weg

Am Anfang genügt es vollkommen nur die offiziell verfügbaren Pakete und den offiziellen Paketmanager Pacman zu benutzen. Es stehen dann zwar nicht die gleiche Anzahl an Paketen wie bei Debian zur Verfügung, man kann aber durch geschicktes Substituieren das Problem meistens umgehen. In den letzten beiden Posts zu Arch Linux auf dem Inspiron 4000 habe ich die manuelle Methode mit makepkg -s vorgestellt, bei der man das PKGBUILD manuell herunterladen und ggf. Abhängigkeiten ebenfalls manuell bauen muss.
Wenn man sich erst einmal an dieses "Do-it-yourself"-Konzept gewöhnt hat, macht das Bauen von Paketen bei Arch Linux sogar richtig Spaß. Für den regelmäßigen Baumeister empfiehlt sich aber einer der sogenannten AUR-Helfer. Insbesondere yaourt scheint populär zu sein. Im Grunde genommen ist yaourt ein Wrapper für Pacman, der die gleichen Befehle unterstützt, gleichzeitig aber die Möglichkeit bietet direkt im Arch User Repository nach Software zu suchen und diese wie mit Pacman gewohnt zu installieren. Momentan benutze ich yaourt ausschließlich nur für das Installieren von AUR-Paketen, was eine große Zeitersparnis ist.

Zum Schluss

Ja, Arch Linux ist anders als Debian. Wenn man sich aber an die Unterschiede gewöhnt hat, macht es viel Spaß. Software zu verwalten ist einfach und unkompliziert. Pacman ist weniger mächtig als Apt, ist dabei aber auch fühlbar schneller auf älteren Rechnern. Ein Bonus ist sicherlich auch, dass man in Sachen Desktopumgebung nicht umdenken muss. Meine alten Openbox-Einstellungen konnte ich problemlos übernehmen.

Posted on

Pacman und das Bedürfnis nach Sicherheit

In den letzten Tagen und Wochen habe ich mich öfter mit Pacman dem Paketmanager von Arch Linux auseinander setzen müssen. Kurioserweise ist er mir bei der Konfiguration von ConnochaetOS vertrauter geworden und weniger beim Umgang mit Arch Linux selbst. Irgendwann habe ich mich gewundert, wie Pacman eigentlich die Integrität der heruntergeladenen Pakete sicherstellt und nach Parallelen zu Debian GNU/Linux gesucht.
Ein wichtiges Hilfsmittel sind MD5-Hashes um zu bestimmen, ob ein vom Server heruntergeladenes Paket auch tatsächlich intakt auf dem eigenen Rechner ankommt. Auch Arch Linux greift genau auf diese Methode zurück. MD5 gilt seit einiger Zeit nicht mehr als ausreichend sicher und eignet sich daher auch nicht um die Echtheit von Paketen zu verifizieren.
Mittlerweile weiß ich auch, dass im Gegensatz zu Debians apt der Paketmanager von Arch Linux noch über keine ausreichende Implementierung zur Überprüfung von sicheren Paketsignaturen mit Hilfe von GnuPG verfügt. Bei meiner Suche nach Informationen bin ich dann auf einige lesenswerte und interessante Artikel gestoßen.
Zum einen wäre da der LWN Artikel "Arch Linux and (the lack of) package signing" und die Antwort darauf von Dan McGee, einer der Hauptentwickler von Pacman und Arch Linux. Kurz zusammengefasst wurde die Problematik am 23. März 2011 deutlich in den Fokus der interessierten Öffentlichkeit gerückt, obwohl das Problem schon seit mehreren Jahren im Bugtracker und Forum von Arch Linux bekannt war. Nach dem ich mir beide Artikel durchgelesen habe, denke ich, dass die Behauptung zutrifft, dass eine funktionierende Paketsignierung bei Arch Linux nicht existiert.

Weniger schwer wiegen da die verletzten Befindlichkeiten der Pacman-Entwickler und des im LWN-Artikels zitierten Arch-Nutzers, der die ganze Sache "ans Licht brachte". Offensichtlich gab es seit Jahren aus verschiedenen Gründen kein Interesse ein solches Sicherheitsfeature zu implementieren und gleichzeitig auch keine echte Hilfe von Seiten der Community. Die Entwicklung stagnierte. Die Frage ist nur, ob man ein solches Problem nur zur Aufgabe einiger Paketentwickler degradieren oder es nicht doch besser zu einer Aufgabe und zu einem Ziel der ganzen Distribution hätte machen sollen.
Natürlich ist jeder User immer ein Stück weit selbst für die Sicherheit seines Systems verantwortlich. Dennoch sollte es eine Möglichkeit geben zu überprüfen, ob es sich bei den heruntergeladenen Paketen auch wirklich um die offiziellen handelt und nicht möglicherweise doch um kompromittierte.
Seit dem Artikel sind sechs Monate vergangen und ein Blick auf die offizielle ArchLinux-Seite zeigt, dass man das Problem zumindest nicht versucht zu verbergen. Es gibt eine eigene Wikiseite zum Thema "Pacman package signing" und auch die FAQ listet unter dem Punkt "Warum man Arch nicht nutzen sollte" auf, dass man dann auf eine sichere Paketsignierung nicht verzichten muss.

Arch Linux ist nicht die einzige Distribution, die eine solche Verifizierung noch nicht vorgesehen hat. Sie wird deswegen auch nicht nutzlos. Selbst Debian hatte nicht von Anfang an eine Möglichkeit um die Echtheit von Paketen zu überprüfen. Doch im Gegensatz zu Arch Linux gab es bereits vor elf Jahren eine breite Diskussion zu diesem Thema. In der Dokumentation zur Absicherung von Debian finden sich hier zwei Links zu den wöchentlichen Neuigkeiten aus dem Jahr 2000 und 2001.
Wenn man etwas daraus lernen kann dann das, man sollte jede Distribution darauf überprüfen, ob sie zu den persönlichen Anforderungen passt. Wenn ich mich auf meine Software zu 100% in jeder Situation verlassen muss, greife ich eher zu Debian Stable als zu Arch Linux. Wenn ich der Meinung bin, dass das Risiko auf ein paar älteren privaten Laptops vernachlässigbar ist und die Distribution ansonsten wunderbar für mich funktioniert, werde ich die betreffende Distribution auch weiterhin verwenden. Ganz allgemein gesprochen kann es nicht schaden die vielen Drittquellen, wozu z.B auch die PPAs bei Ubuntu gehören, genauer unter die Lupe zu nehmen und nicht jedes Paket blindlings herunterzuladen. Schließlich sollte doch ein zentrales und vor allem sicheres Paketmanagement Linux von anderen Betriebssystemen positiv unterscheiden.