Unsichere Schlüssel-Automatik für die Clients

Jetzt können Clients Pakete von hier installieren. Beim ersten Versuch lädt die Paketverwaltung automatisch den Schlüssel herunter und fordert den Benutzer auf, diesen zu prüfen und fragt, ob er ihn installieren will (Abbildung 3). Manuell geht das mit:

Abbildung 3: Die neue Paketquelle ist dem System noch nicht bekannt, beim ersten Zugriff muss der Admin deshalb die Echtheit der Signatur bestätigen.

$ rpm --import http://example.net/repo/RPM-GPG-KEY-Mustermann

Komfortabler, aber auch unsicherer, ist es, ein Paket zu bauen, das Konfiguration und Signaturschlüssel schon enthält. Das hat den Vorteil, dass Anwender den Schlüssel nicht mehr über das Internet herunterladen müssen. Zwar stellt das RPM-Paket jetzt die Datei-Integrität sicher, und der Benutzer ist gegen DNS-Manipulationen gewappnet, aber prinzipiell kann so auch jedermann ein signiertes Paket bauen und veröffentlichen, die Signatur ist praktisch wertlos.

Trotzdem kann das Vorgehen auch nützlich sein: Der Anwender bekommt automatisch Aktualisierungen für die Repository-Konfiguration, zum Beispiel wenn neue Softwareversionen auftauchen. Wer das einrichten will, ersetzt

gpgkey=http://example.net/repo/RPM-GPG-KEY-Max-Mustermann

in der Repository-Definition durch:

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Max-Mustermann

Auch das Spec-File für dieses Paket ist recht trivial, wie Listing 6 zeigt. Der Entwickler könnte sogar noch einen Schritt weiter gehen und den Schlüssel ebenfalls automatisch durch das Paket installieren lassen. Dazu fügt er folgenden Abschnitt zur Spec-Datei hinzu:

01 Name:           mustermann-release
02 Version:        1.0
03 Release:        1%{?dist}
04 Summary:        Max Mustermann's RPM packages
05 Summary(de):    Max Mustermanns RPM Pakete
06
07 Group:          System Environment/Base
08 License:        GPLv2
09 URL:            http://example.net/repo
10 Source0:        mustermann.repo
11 Source1:        RPM-GPG-KEY-Mustermann.asc
12 BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
13 BuildArch:      noarch
14
15 %description
16 This package contains the repository definiton and signing keys for Max
17 Mustermann's RPM packages.
18
19 %description -l de
20 Dieses Pakete enthält die Informationen und GPG Schlüssel für Max Mustermanns
21 RPM Pakete.
22
23 %prep
24 # nichts zu entpacken
25
26 %build
27 # nichts zu bauen
28
29 %install
30 rm -rf %{buildroot}
31 install -Dpm 0644 %{SOURCE0} %{buildroot}%{_sysconfdir}/yum.repos.d/mustermann.repo
32 install -Dpm 0644 %{SOURCE1} %{buildroot}%{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-Mustermann
33
34 %clean
35 rm -rf %{buildroot}
36
37 %files
38 %defattr(-,root,root,-)
39 %doc
40 %{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-Mustermann
41 %{_sysconfdir}/yum.repos.d/mustermann.repo
42
43 %changelog
44 * Sun Apr 17 2011 Max Mustermann <max.mustermann@example.net> - 1.0-1
45 - Initial release

%post
rpm --import etc/pki/rpm-gpg/RPM-GPG-KEY-Max-Mustermann || :

Der vollautomatische Import des Schlüssels ist aber nicht immer erwünscht, eigentlich sollte der Benutzer den Schlüssel ja prüfen und bestätigen, ansonsten hält sich der Sicherheitsgewinn in Grenzen.

Bitte bestätigen

Wenn jetzt der Entwickler noch die Authentizität des Paketes garantiert, das den Schlüssel enthält, ist der Anwender auf der sicheren Seite. Dafür gibt es leider nur den altmodischen Weg über eine Prüfsumme aus beispielsweise SHA1sum, wiederum per GPG-Schlüssel signiert:

$ sha1sum mustermann-release-1.0-1.fc14.noarch.rpm > SHA1SUM
$ gpg --textmode --detach-sign --local-userC6B8BAFB SHA1SUMS

Auch die beiden Dateien »SHA1SUMS« und »SHA1SUMS.sig« muss der Admin jetzt zum Download bereitstellen.

Damit wäre theoretisch die Kette des Vertrauens komplett: Ein garantiert authentisches Paket installiert die Konfiguration, die es ermöglicht, weitere authentische Pakete zu installieren.