[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ weiter ]
Debian hat ein Sicherheitsteam, das aus fünf Mitgliedern und zwei Sekretären besteht. Es ist für die Sicherheit in der Stable-Veröffentlichung verantwortlich. Das bedeutet, dass es Sicherheitslücken nachgeht, die in Software auftauchen (indem es Foren wie Bugtraq oder vuln-dev beobachtet), und ermittelt, ob davon die Stable-Veröffentlichung betroffen ist.
Das Sicherheitsteam von Debian ist auch der Ansprechpartner für Probleme, die
von den Programmautoren oder Organisationen wie CERT
behandelt werden und die mehrere
Linux-Anbieter betreffen können. Das gilt für alle Probleme, die nicht
debianspezifisch sind. Die Kontaktadresse des Sicherheitsteams ist team@security.debian.org
, die
nur die Mitglieder des Sicherheitsteams lesen.
Heikle Informationen sollten an die erste Adresse geschickt werden und unter Umständen mit dem Schlüssel von Debian Security Contact (der sich in Debians Schlüsselbund befindet) verschlüsselt werden.
Wenn das Sicherheitsteam ein mögliches Problem erhält, wird es untersuchen,
ob die Stable-Veröffentlichung davon betroffen ist. Wenn dies der
Fall ist, wird eine Ausbesserungen des Quellcodes vorgenommen. Diese
Ausbesserung schließt manchmal ein, dass Patches der Programmautoren
zurückportiert werden (da das Originalprogramm gewöhnlich einige Versionen
weiter ist als das in Debian). Nachdem die Ausbesserung getestet wurde, werden
neue Pakete vorbereitet und auf der Seite security-master.debian.org
veröffentlicht, damit sie mit apt
abgerufen werden können (siehe
Ausführen von
Sicherheitsaktualisierungen, Abschnitt 4.2). Zur gleichen Zeit wird eine
Debian-Sicherheits-Ankündigung (DSA) auf der Webseite veröffentlicht
und an öffentliche Mailinglisten einschließlich debian-security-announce
und Bugtraq geschickt.
Einige andere häufige Fragen zum Sicherheitsteam von Debian können unter Fragen zu Debians Sicherheitsteam, Abschnitt 12.3 gefunden werden.
Debian-Sicherheits-Ankündigungen (DSA) werden erstellt, sobald eine Sicherheitslücke entdeckt wird, die ein Debian-Paket betrifft. Diese Ankündigungen, die von einem Mitglied des Sicherheitsteams signiert sind, enthalten Informationen zu den betroffenen Versionen und den Orten der Aktualisierungen und ihrer MD5-Summen. Die Informationen sind:
Versionsnummer der Ausbesserung
Art des Problems
Ob es aus der Ferne oder lokal ausnutzbar ist
Kurze Beschreibung des Pakets
Beschreibung des Problems
Beschreibung des Exploits
Beschreibung der Ausbesserung
DSAs werden sowohl auf der Hauptseite
von Debian
als auch auf den Sicherheitsseiten von Debian
veröffentlicht. Das passiert normalerweise nicht, bis die Website neu
erstellt wurde (alle vier Stunden). Daher könnten sie nicht sofort vorhanden
sein. Somit ist die vorzugswürdige Informationsquelle die Mailingliste
debian-security-announce.
Interessierte Benutzer können auch den RDF-Kanal verwenden, um die DSAs
automatisch auf ihren Desktop herunterzuladen (dies wird auf einigen Portalen
über Debian gemacht). Einige Anwendungen, wie etwa Evolution
(ein E-Mail-Client und Hilfsprogramm für persönliche Informationen) und
Multiticker
(ein GNOME-Applet) können verwendet werden, um die
Ankündigungen automatisch herunterzuladen. Der RDF-Kanal befindet sich unter
http://www.debian.org/security/dsa.rdf
.
DSAs, die auf der Webseite veröffentlicht wurden, können aktualisiert werden, nachdem sie an öffentliche Mailinglisten verschickt wurden. Eine typische Aktualisierung ist, einen Querverweis auf Datenbanken mit Sicherheitslücken hinzuzufügen. Auch Übersetzungen der DSAs [57] werden nicht an die Sicherheitsmailinglisten geschickt, sondern sind direkt auf der Webseite enthalten.
Debian stellt eine vollständige Tabelle mit
Querverweisen
zur Verfügung, die alle verfügbaren Verweise für
die Ankündigungen seit 1998 enthält. Diese Tabelle soll die Verweisübersicht
von CVE
ergänzen.
Sie werden bemerken, dass die Tabelle Verweise auf Sicherheitsdatenbanken wie
Bugtraq
, CERT/CC Ankündigungen
und
US-CERT Vulnerability Notes
Database
und auf die CVE-Bezeichnungen (siehe unten) enthält.
Diese Verweise werden zur Nutzerfreundlichkeit angeboten, aber nur der
CVE-Verweise werden regelmäßig überprüft und eingefügt. Dieses Feature
wurde im Juni 2002 der Webseite hinzugefügt.
Das Hinzufügen von Querverweisen auf diese Sicherheitsdatenbanken hat folgende Vorteile:
Es erleichtert Benutzern von Debian zu erkennen und nachzuvollziehen, welche allgemeinen (veröffentlichten) Ankündigungen schon von Debian abgedeckt sind.
Systemadministratoren können mehr über die Verwundbarkeit und ihre Auswirkungen lernen, wenn sie den Querverweisen folgen.
Diese Informationen können benutzt werden, um Ausgaben von Verwundbarkeitsscannern, die Verweise auf CVE enthalten, zu überprüfen, um falsche Positivmeldungen auszusortieren (vergleichen Sie Der Scanner X zur Einschätzung der Verwundbarkeit sagt, dass mein Debian-System verwundbar wäre?, Abschnitt 12.2.1).
Debians Sicherheitsankündigungen wurden am 24. Februar 2004 CVE-kompatibel
erklärt
[58].
Die Entwickler von Debian wissen von der Notwendigkeit, genaue und aktuelle
Informationen über den Lage der Sicherheit in der Debian-Distribution zur
Verfügung zu stellen. Dies ermöglicht es den Benutzern, mit den Risiken
durch neue Sicherheitslücken umzugehen. CVE versetzt uns in die Lage,
standardisierte Verweise anzubieten, die es Benutzern ermöglicht, einen
Prozess zur
Verwaltung der Sicherheit auf Grundlage von CVE
zu entwickeln.
Das Projekt Common Vulnerabilities and
Exposures (CVE)
wird von der MITRE Corporation betreut und stellt
eine Liste von standardisierten Bezeichnungen für Verwundbarkeiten und
Sicherheitslücken zur Verfügung.
Debian ist überzeugt, dass es außerordentlich wichtig ist, die Benutzer mit zusätzlichen Informationen im Zusammenhang mit Sicherheitsproblemen, welche die Debian-Distribution betreffen, zu versorgen. Indem CVE-Bezeichnungen in den Ankündigungen enthalten sind, können Benutzer leichter allgemeine Verwundbarkeiten mit bestimmten Aktualisierungen von Debian in Verbindung bringen. Dies verringert die Zeit, die benötigt wird, um Verwundbarkeiten, die unsere Benutzer betreffen, abzuarbeiten. Außerdem vereinfacht es die Organisation der Sicherheit in einer Umgebung, in der schon Sicherheitswerkzeuge, die CVE verwenden, wie Erkennungssysteme von Eindringlingen in Netzwerk oder Host oder Werkzeuge zur Bewertung der Sicherheit eingesetzt werden, unabhängig davon, ob sie auf der Debian-Distribution beruhen.
Debian stellt CVE-Bezeichnungen sind in allen DSAs seit September 1998 zur Verfügung. Alle Ankündigungen können auf der Webseite von Debian abgerufen werden. Auch Ankündigungen von neuen Verwundbarkeiten enthalten CVE-Bezeichnungen, wenn sie zum Zeitpunkt ihrer Veröffentlichung verfügbar waren. Ankündigungen, die mit einer bestimmten CVE-Bezeichnung verbunden sind, können direkt über Debians Sicherheitsdatenbank (Debian Security Tracker) gesucht werden (siehe unten).
In einige Fällen finden Sie eine bestimmte CVE-Bezeichnung in veröffentlichten Ankündigungen nicht. Beispiele dafür sind:
Keine Produkte von Debian sind von der Verwundbarkeit betroffen.
Es gibt noch keine Ankündigung, welche die Verwundbarkeit abdeckt; das
Sicherheitsproblem wurde vielleicht als Sicherheitsfehler
gemeldet, aber eine Ausbesserung wurde noch nicht getestet und hochgeladen.
Eine Ankündigung wurde veröffentlicht, bevor eine CVE-Bezeichnung einer bestimmten Verwundbarkeit zugewiesen wurde (sehen Sie auf der Webseite nach einer Aktualisierung).
Die zentrale Datenbank darüber, welche Erkenntnisse Debians Sicherheitsteam
von Verwundbarkeiten hat, ist der Debian Security Tracker
.
Sie enthält Querverweise zwischen Paketen, verwundbaren und ausgebesserten
Versionen für unterschiedliche Veröffentlichungen, CVE-Namen, Nummern von
Debian-Fehlerberichten, DSAs sowie unterschiedliche Anmerkungen. Die Datenbank
kann durchsucht werden, z.B. nach dem CVE-Namen, um zu sehen, welche
Debian-Pakete davon betroffen sind oder bereits Ausbesserungen enthalten, oder
z.B. nach einem bestimmten Paket, um zu sehen, welche ungelösten
Sicherheitsprobleme es hat. Die einzigen Informationen, die in der Datenbank
fehlen, sind vertrauliche Informationen, die das Sicherheitsteam während eines
Embargos erhalten hat.
Das Paket debsecan
verwendet die Informationen in der Datenbank,
zum den Administrator eines Systems darüber zu informieren, welche der
installierten Pakete verwundbar sind und für welche Pakete
Sicherheitsaktualisierungen verfügbar sind.
Da Debian im Moment eine große Anzahl von Architekturen unterstützt, fragen Administratoren manchmal, ob es bei einer bestimmten Architektur bis zu einer Sicherheitsaktualisierung länger dauert als bei einer anderen. Tatsächlich sind Aktualisierungen auf allen Architekturen zur selben Zeit verfügbar, abgesehen von seltenen Umständen.
Pakete im Sicherheitsarchiv werden automatisch erstellt, genauso wie im normalen Archiv. Allerdings werden Sicherheitsaktualisierungen etwas anderes behandelt als normale Aktualisierungen, die von den Paketbetreuern vorgenommen werden, da in manchen Fällen vor einer Veröffentlichung die Aktualisierungen nochmals getestet werden müssen, eine Ankündigung geschrieben werden muss oder eine Woche oder mehr gewartet werden muss, um zu verhindern, dass der Fehler veröffentlicht wird, bevor nicht alle Linux-Anbieter eine vernünftige Chance hatten, ihn zu beheben.
Folglich arbeitet das Archiv der Sicherheitsuploads nach dem folgenden Ablauf :
Jemand findet ein Sicherheitsproblem.
Jemand löst das Problem und lädt die Lösung in den Eingang von security-master.debian.org hoch (dieser jemand ist normalerweise ein Mitglied des Sicherheitsteams, kann aber auch ein Paketbetreuer mit einer passenden Verbesserung sein, der sich zuvor mit dem Sicherheitsteam in Verbindung gesetzt hat). Die Änderungsübersicht (changelog) beinhaltet ein testing-security oder stable-security als Zieldistribution.
Die hochgeladenen Dateien werden von einem Debian-System überprüft, verarbeitet und in die Warteschleife der angenommenen Dateien weitergeleitet. Danach werden die Buildds benachrichtigt. Auf die Dateien in der Warteschleife kann das Sicherheitsteam und (auf indirektem Wege) die Buildds zugreifen.
Buildds, die Sicherheit unterstützen, holen sich das Quellpaket (mit einer höheren Priorität als normale Paketerstellungen), erstellen Pakete und schicken die Protokolle ans Sicherheitsteam.
Das Sicherheitsteam antwortet auf die Protokolle und die neu erstellten Pakete werden in die Warteschleife der ungeprüften Dateien hochgeladen, wo sie von einem Debian-System verarbeitet und in die Warteschleife der angenommenen Dateien verschoben werden.
Wenn das Sicherheitsteam ein Quellpaket akzeptiert (d.h. dass es für alle Architekturen korrekt Pakete erstellt, und dass es die Sicherheitslücke schließt und keine neuen Probleme hervorruft), führt es ein Skript aus, das:
das Paket im Sicherheitsarchiv installiert,
die Paket
-, Quell
- und
Veröffentlichungsdateien
von security.debian.org auf dem
gewöhnlichen Weg aktualisiert (dpkg-scanpackages
,
dpkg-scansources
, ...),
eine Vorlage einer Ankündigung erstellt, die das Sicherheitsteam fertig stellen kann und
die Pakete zu den vorgeschlagenen Aktualisierungen weiterleitet, so dass sie sobald wie möglich in die echten Archive eingefügt werden können.
Dieser Ablauf, der früher per Hand durchgeführt wurde, wurde während des Freezing-Abschnitts von Debian 3.0 Woody (Juli 2002) getestet und umgesetzt. Dank dieser Infrastruktur war es dem Sicherheitsteam möglich, aktualisierte Pakete für Apache- und OpenSSH-Probleme für alle unterstützen Architekturen (fast 20) in weniger als einem Tag bereitzustellen.
Debian Entwickler, die mit dem Sicherheitsteam zusammenarbeiten müssen, um in
ihren Pakete Probleme zu lösen, sollten in der Entwicklerreferenz im Abschnitt
Handhabung
von sicherheitsrelevanten Fehlern
nachsehen.
Dieser Abschnitt könnte auch mit »Wie man sein Debian GNU/Linux-System sicher upgraded/aktualisiert« überschrieben werden. Es verdient hauptsächlich deshalb einen eigenen Abschnitt, weil es einen wichtigen Teil der Infrastruktur der Sicherheit darstellt. Die Signierung von Paketen ist ein wichtiges Thema, da es die Manipulation von Paketen in Spiegel und von heruntergeladenen Dateien durch Man-in-the-Middle-Angriffen verhindert. Die automatische Aktualisierung von Software ist eine wichtige Fähigkeit, aber es ist auch wichtig, Gefahren für die Sicherheit zu entfernen, die die Verbreitung von Trojanern und den Einbruch ins System während der Aktualisierung fördern können.[59]
Debian stellt keine signierten Pakete zur Verfügung. Es gibt aber seit Debian 4.0 (Codename Etch) eine Verfahrensweise, mit der die Integrität von heruntergeladenen Paketen überprüft werden kann.[60] Weiterführende Hinweise können Sie unter Secure Apt, Abschnitt 7.5.2 finden.
Dieses Problem wird besser im Strong-Distribution-Howto
von V. Alex Brennen beschrieben.
Die aktuelle Methode zur Prüfung von Paketsignaturen mit apt
ist:
Die Release
-Datei enthält die MD5-Summe von
Packages.gz
(welche die MD5-Summen der Pakete enthält) und wird
signiert. Die Signatur stammt aus einer vertrauenswürdigen Quelle.
Diese signierte Release
-Datei wird beim »apt-get update«
herunter geladen und zusammen mit Packages.gz
gespeichert.
Wenn ein Paket installiert werden soll, wird es zuerst herunter geladen, und dann wird die MD5-Summe erstellt.
Die signierte Release
-Datei wird überprüft (ob die Signatur in
Ordnung ist) und die MD5-Summe der Packages.gz
-Datei extrahiert.
Die MD5-Summe der Packages.gz
-Datei wird erstellt und geprüft,
und – wenn sie übereinstimmt – wird die MD5-Summe des
heruntergeladenen Paketes aus ihr extrahiert.
Wenn die MD5-Summe des heruntergeladenen Paketes die gleiche ist wie in der
Packages.gz
-Datei, wird das Paket installiert. Andernfalls wird
der Administrator alarmiert und das Paket wird im Zwischenspeicher gehalten (so
dass der Administrator entscheiden kann, ob es installiert werden soll oder
nicht). Wenn das Paket nicht in Packages.gz
enthalten ist und der
Administrator das System so konfiguriert hat, dass nur geprüfte Pakete
installiert werden können, wird das Paket ebenfalls nicht installiert.
Durch diese Kette von MD5-Summen ist apt
in der Lage, zu
verifizieren, dass ein Paket aus einer bestimmten Veröffentlichung stammt.
Dies ist zwar unflexibler als jedes Paket einzeln zu signieren, kann aber auch
mit den unten aufgeführten Plänen kombiniert werden.
Diese Vorgehensweise ist seit der Veröffentlichung von Debian 4.0 verfügbar
und vollständig in apt 0.6 enthalten
;
weitere Informationen finden Sie unter Secure Apt,
Abschnitt 7.5.2. Pakete, die ein Frontend für apt anbieten, müssen
verändert werden, um an diese neue Fähigkeit angepasst zu werden. Das gilt
für aptitude
, das verändert
wurde, um zu dieser Vorgehensweise zu passen. Frontends, die bekanntermaßen
zurzeit mit dieser Fähigkeit umgehen können, sind aptitude
und
synaptic
.
Die Signierung von Paketen wurde innerhalb des Debian-Projekts ausführlich
diskutiert. Mehr Informationen hierzu finden Sie unter http://www.debian.org/News/weekly/2001/8/
und http://www.debian.org/News/weekly/2000/11/
.
Die Veröffentlichung von apt 0.6, das seit Debian 4.0 (Etch)
verfügbar ist, enthält apt-secure (auch als Secure Apt
bekannt), das ein Werkzeug ist, mit dem ein Systemadministrator die Integrität
von heruntergeladenen Paketen mit dem oben dargestellten Verfahren überprüfen
kann. Diese Veröffentlichung enthält das Werkzeug apt-key
, um
neue Schlüssel zum Schlüsselbund von apt hinzuzufügen, welcher
standardmäßig nur den aktuellen Signierungsschlüssel des Debian-Archivs
enthält.
Diese Veränderungen basieren auf dem Patch für apt
(verfügbar
in Fehler
#203741
), der diese Erweiterung zur Verfügung stellt.
Secure Apt überprüft die Distribution mit der Release
-Datei.
Dies wurde schon unter Überprüfung der
Distribution mit der Release
-Datei, Abschnitt 7.5.3
dargestellt. Typischerweise erfordert dieser Vorgang kein Mitwirken des
Administrators. Aber jedes Jahr müssen Sie eingreifen[61], um den neuen Schlüssel des
Archivs hinzuzufügen, wenn dieser ausgewechselt wurde. Weitere Informationen
zu den dazu notwendigen Schritten finden Sie unter Auf sichere Weise einen Schlüssel hinzufügen,
Abschnitt 7.5.3.7.
Diese Fähigkeit befindet sich noch im Entwicklungsstadium. Wenn Sie glauben,
dass Sie Fehler gefunden haben, stellen Sie zuerst sicher, dass Sie die neuste
Version verwenden (da dieses Paket vor seiner endgültigen Veröffentlichung
noch ziemlich verändern werden kann). Falls Sie die aktuelle Version
benutzen, schicken Sie einen Fehlerbericht für das Paket apt
.
Weiterführende Informationen finden Sie im Debian-Wiki
und in der
offiziellen Dokumentation unter Migration to APT
0.6
und APT
Signature Checking
.
Release
-Datei
Dieser Abschnitt beschreibt, wie die Überprüfung der Distribution mit Hilfe
der Release
-Datei funktioniert. Dies wurde von Joey Hess
geschrieben und ist auch im Debian-Wiki
abrufbar.
Es gibt ein paar grundlegende Konzepte, die Sie brauchen, um den Rest dieses Abschnitts verstehen zu können.
Eine Prüfsumme ist eine Methode, bei der eine Datei auf eine relativ kurze Zahl heruntergekocht wird, mit welcher der Inhalt der Datei eindeutig identifiziert werden kann. Dies ist wesentlich schwieriger, als es zunächst erscheinen mag. Der am weitesten verbreiteteste Typ von Prüfsummen, MD5, wird gerade unbrauchbar.
Verschlüsselung mit öffentlichen Schlüsseln fußt auf einem Schlüsselpaar: einem öffentlichen Schlüssel und einem privaten Schlüssel. Der öffentliche Schlüssel wird an die Allgemeinheit verteilt. Der private muss geheim bleiben. Jeder, der den öffentlichen Schlüssel hat, kann eine Nachricht verschlüsseln, so dass sie nur noch der Besitzer des privaten Schlüssels lesen kann. Es besteht daneben die Möglichkeit, mit einem privaten Schlüssel eine Datei zu signieren. Wenn eine Datei mit einer digitalen Unterschrift versehen wurde, kann jeder, der den öffentlichen Schlüssel hat, überprüfen, ob die Datei mit diesem Schlüssel unterschrieben wurde. Ohne den privaten Schlüssel lässt sich eine solche Signatur nicht nachmachen.
Diese Schlüssel bestehen aus ziemlich langen Zahlen (1024 oder 2048 Ziffern oder sogar länger). Damit sie leichter zu verwenden sind, haben sie eine kürzere Schlüssel-ID (eine Zahl mit nur acht oder 16 Stellen), mit der sie bezeichnet werden können.
Secure Apt verwendet gpg
, um Dateien zu unterschreiben und ihre
Signaturen zu überprüfen.
Mit dem Programm apt-key
wird der Schlüsselbund von GPG für
Secure Apt verwaltet. Der Schlüsselbund befindet sich in der Datei
/etc/apt/trusted.gpg
(nicht zu verwechseln mit der verwandten,
aber nicht sehr interessanten Datei /etc/apt/trustdb.gpg
).
apt-key
kann dazu verwendet werden, die Schlüssel im
Schlüsselbund anzuzeigen oder um Schlüssel hinzuzufügen oder zu entfernen.
Release
-Datei
Jedes Archiv von Debian enthält eine Release
-Datei, die jedes Mal
aktualisiert wird, wenn ein Paket im Archiv geändert wird. Unter anderem
enthält die Release
-Datei MD5-Summen von anderen Dateien, die
sich im Archiv befinden. Ein Auszug einer Release
-Datei:
MD5Sum: 6b05b392f792ba5a436d590c129de21f 3453 Packages 1356479a23edda7a69f24eb8d6f4a14b 1131 Packages.gz 2a5167881adc9ad1a8864f281b1eb959 1715 Sources 88de3533bf6e054d1799f8e49b6aed8b 658 Sources.gz
Die Release
-Datei enthält auch SHA1-Prüfsummen, was nützlich
wird, wenn MD5-Summen vollständig unbrauchbar sind. Allerdings unterstützt
apt SHA1 noch nicht.
Werfen wir einen Blick in eine Packages
-Datei: Wir sehen weitere
MD5-Summen, eine für jedes darin aufgeführte Paket. Beispiel:
Package: uqm Priority: optional ... Filename: unstable/uqm_0.4.0-1_i386.deb Size: 580558 MD5sum: 864ec6157c1eea88acfef44d0f34d219
Mit diesen beiden Prüfsummen kann überprüft werden, ob Sie eine getreue
Kopie der Packages
-Datei heruntergeladen haben, also mit einer
MD5-Summe, die mit der in der Release
-Datei übereinstimmt. Und
wenn ein einzelnes Paket heruntergeladen wird, kann auch die MD5-Summe mit dem
Inhalt der Packages
-Datei verglichen werden. Wenn bei einem
dieser Schritte ein Fehler auftauchen sollte, bricht Apt den Vorgang ab.
Nichts davon ist neu in Secure Apt, sondern bietet nur die Grundlage für
Secure Apt. Beachten Sie, dass es bis jetzt eine Datei gibt, die Apt nicht
überprüfen kann: die Release
-Datei. Bei Secure Apt dreht sich
alles darum, dass Apt die Release
-Datei überprüft, bevor es
irgendetwas anderes damit macht. Wenn man das schafft, besteht eine
lückenlose Authentifizierungskette von dem Paket, das Sie installieren
möchten, bis zum Anbieter des Pakets.
Release
-Datei
Damit die Release
-Datei überprüft werden kann, wird sie mit GPG
signiert. Diese Unterschrift kommt in die Datei Release.gpg
, die
mit der Release
-Datei abgerufen werden kann. Sie sieht in etwa
so[62] aus, obwohl sich für
gewöhnlich nur GPG ihren Inhalt ansieht:
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCqKO1nukh8wJbxY8RAsfHAJ9hu8oGNRAl2MSmP5+z2RZb6FJ8kACfWvEx UBGPVc7jbHHsg78EhMBlV/U= =x6og -----END PGP SIGNATURE-----
Release.gpg
mit Apt
überprüfen
Wenn Secure Apt eine Release
-Datei herunterlädt, lädt es immer
auch die Release.gpg
-Datei herunter. Falls dies misslingen sollte
oder die Signatur nicht stimmt, wird es eine Rückmeldung machen und hinweisen,
dass die Packages
-Dateien, auf welche die
Release
-Datei verweist, und alle darin enthaltenen Pakete von
einer nicht vertrauenswürdigen Quelle stammen. So würde dies während
apt-get update
aussehen:
W: GPG error: http://ftp.us.debian.org testing Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F
Beachten Sie, dass die zweite Hälfte der langen Nummer die Schlüssel-ID des Schlüssels ist, von dem Apt nichts weiß. Im Beispiel ist sie 2D230C5F.
Falls Sie diese Warnung ignorieren und später versuchen, ein Paket zu installieren, wird Sie Apt nochmals warnen:
WARNUNG: Die folgenden Pakete können nicht authentifiziert werden! libglib-perl libgtk2-perl Diese Pakete ohne Überprüfung installieren [j/N]?
Wenn Sie nun »J« drücken, haben Sie keine Möglichkeit festzustellen, ob die Datei, die Sie bekommen, wirklich diejenige ist, die Sie auch installieren möchten, oder ob sie eine ganz andere ist, die Ihnen jemand, der die Verbindung mit dem Server abgefangen hat[63], mit einer gemeinen Überraschung unterschieben will.
Hinweis: Sie können diese Abfragen abschalten, indem Sie apt
mit
--allow-unauthenticated laufen lassen.
Es lohnt sich auch noch darauf hinzuweisen, dass der Installer von Debian
während des Debootstraps des Basissystems, solange Apt noch nicht verfügbar
ist, denselben Mechanismus mit signierten Release
-Dateien
verwendet. Der Installer benutzt sogar dieses Verfahren, um Teile von sich
selbst zu überprüfen, die er aus dem Netz gezogen hat. Debian signiert im
Moment nicht die Release
-Dateien auf den CDs. Apt kann aber so
eingerichtet werden, dass es immer den Paketen von CDs vertraut, so dass dies
nicht ein so großes Problem darstellt.
Die ganze Sicherheit des Verfahrens beruht also darauf, dass es eine
Release.gpg
-Datei gibt, die eine Release
-Datei
signiert, und dass diese Signatur von apt
mit Hilfe von GPG
überprüft wird. Dazu muss es den öffentlichen Schlüssel der Person kennen,
welche die Datei unterschrieben hat. Diese Schlüssel werden in Apts eigenem
Schlüsselbund (/etc/apt/trusted.gpg
) gespeichert. Bei der
Verwaltung dieser Schlüssel kommt Secure Apt ins Spiel.
Standardmäßig befindet sich bei Debian-Systemen der Schlüssel des Debian-Archivs im Schlüsselbund.
# apt-key list /etc/apt/trusted.gpg -------------------- pub 1024D/4F368D5D 2005-01-31 [expires: 2006-01-31] uid Debian Archive Automatic Signing Key (2005) <ftpmaster@debian.org>
Im Beispiel ist 4F368D5D die Schlüssel-ID. Beachten Sie, dass dieser Schlüssel nur für ein Jahr gültig ist. Debian tauscht die Schlüssel als letzte Verteidigungslinie gegen Sicherheitsrisiken, die das Knacken eines Schlüssels umfassen, regelmäßig aus.
Mit dem Schlüssel des Archivs wird apt
dem offiziellen Archiv von
Debian vertrauen. Wenn Sie aber weitere Paketdepots zu
/etc/apt/sources.list
hinzufügen wollen, müssen Sie Apt Ihre
Schlüssel mitteilen, wenn Sie wollen, dass Apt ihnen vertraut. Sobald Sie den
Schlüssel haben und ihn überprüft haben, müssen Sie nur apt-key add
Datei
laufen lassen, um den Schlüssel hinzuzufügen. Der
schwierigste Teil dabei ist, den Schlüssel zu bekommen und ihn zu
überprüfen.
Mit dem Paket debian-archive-keyring
werden Schlüssel für
apt
bereitgestellt. Aktualisierungen dieses Pakets führen dazu,
dass GPG-Schlüssel für das Debian-Hauptarchiv hinzugefügt (oder gelöscht)
werden.
Für andere Archive gibt noch keinen standardisierten Ort, wo sich der Schlüssel für ein Paketdepot befinden soll. Es besteht die grobe Übereinkunft, dass der Schlüssel auf der Webseite des Paketdepots oder im Depot selbst zu finden sein sollte. Wie gesagt ist dies kein echter Standard, so dass Sie den Schlüssel unter Umständen suchen müssen.
Der Schlüssel des Debian-Archivs ist unter http://ftp-master.debian.org/ziyi_key_2006.asc
(ersetzen Sie 2006 mit dem aktuellen Jahr) erhältlich.[64]
gpg
besitzt mit den Schlüsselservern eine standardisierte
Möglichkeit, Schlüssel zu verbreiten. Damit kann GPG einen Schlüssel
herunterladen und ihn zum Schlüsselbund hinzufügen. Beispiel:
$ gpg --keyserver pgpkeys.mit.edu --recv-key 2D230C5F gpg: requesting key 2D230C5F from hkp server pgpkeys.mit.edu gpg: key 2D230C5F: public key "Debian Archive Automatic Signing Key (2006) <ftpm aster@debian.org>" imported gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1 gpg: importiert: 1
Sie können dann den Schlüssel aus Ihrem Schlüsselbund exportieren und ihn an
apt-key
weiterreichen:
$ gpg -a --export 2D230C5F | sudo apt-key add - gpg: kein uneingeschränkt vertrauenswürdiger Schlüssel 080F67F4 gefunden OK
Die Warnung »gpg: kein uneingeschränkt vertrauenswürdiger Schlüssel 080F67F4 gefunden« bedeutet, dass GPG nicht so konfiguriert wurde, um einem Schlüssel vollständig zu vertrauen. Das Zuweisen von Vertrauensstufen ist Teil des Web-of-Trust von OpenPGP, was hier nicht Gegenstand ist. Daher ist die Warnung unproblematisch. Für gewöhnlich wird dem eignen Schlüssel eines Benutzers vollständig vertraut.
Indem Sie einen Schlüssel zu Apts Schlüsselbund hinzufügen, lassen Sie Apt
wissen, dass es allem vertrauen soll, was mit diesem Schlüssel signiert wurde.
Dadurch stellen Sie sicher, dass Apt nichts installiert, was nicht vom Inhaber
des privaten Schlüssels signiert wurde. Mit ausreichender Paranoia erkennen
Sie aber, dass dies das Problem nur um eine Stufe verlagert: Anstatt sich nun
darum Sorgen zu machen, ob ein Paket oder eine Release
-Datei
korrekt ist, müssen Sie überprüfen, ob Sie tatsächlich den richtigen
Schlüssel haben. Ist die Datei http://ftp-master.debian.org/ziyi_key_2006.asc
,
die oben erwähnt wird, wirklich der Signierungsschlüssel des Debian-Archivs
oder wurde sie verändert (oder wird gar in diesem Dokument gelogen)?
Es ist gut, in Sicherheitsfragen Vorsicht walten zu lassen. Aber ab hier wird
es schwieriger, Dinge zu überprüfen. gpg
arbeitet mit dem
Konzept der Kette des Vertrauens (chain of trust), die bei jemandem beginnt,
dem Sie vertrauen und der einen anderen Schlüssel unterschreibt usw., bis Sie
beim Schlüssel des Archivs sind. Wenn Sie vorsichtig sind, wollen Sie
nachprüfen, dass Ihr Archivschlüssel von einem Schlüssel unterschrieben
wurde, dem Sie vertrauen können, weil seine Kette des Vertrauens zu jemandem
zurückgeht, den Sie persönlich kennen. Dazu sollten Sie eine
Debian-Konferenz oder eine lokale LUG zum Unterschreiben der Schlüssel
besuchen[65].
Wenn Sie diese Sicherheitsbedenken nicht teilen (können), unternehmen Sie, was auch immer Sie passend finden, wenn Sie eine neue Apt-Quelle oder einen neuen Schlüssel verwenden. Sie könnten demjenigen, der den Schlüssel anbietet, eine Mail schreiben, um den Schlüssel zu überprüfen. Oder Sie vertrauen auf Ihr Glück und gehen davon aus, dass Sie den richten heruntergeladen haben. Das wichtige ist, dass Secure Apt, indem es das Problem darauf reduziert, welchen Archivschlüsseln Sie vertrauen, Sie so vorsichtig und sicher vorgehen lässt, wie es Ihnen passend und notwendig erscheint.
Sie können dazu sowohl den Fingerabdruck als auch die Unterschriften des
Schlüssels überprüfen. Den Fingerabdruck kann man aus verschiedenen Quellen
erhalten. Sie können im Buch The Debian
System
nachsehen, im IRC mit Debian-Entwicklern reden oder
Mailinglisten lesen, wo ein Wechsel des Schlüssel angekündigt werden wird,
oder jede andere erdenkliche Methode verwenden, um den Fingerabdruck zu
überprüfen. Zum Beispiel können Sie auch Folgendes machen:
$ GET http://ftp-master.debian.org/ziyi_key_2006.asc | gpg --import gpg: key 2D230C5F: public key "Debian Archive Automatic Signing Key (2006) <ftpmaster&debian.org>" imported gpg: Total number processed: 1 gpg: imported: 1 $ gpg --check-sigs --fingerprint 2D230C5F pub 1024D/2D230C5F 2006-01-03 [expires: 2007-02-07] Key fingerprint = 0847 50FC 01A6 D388 A643 D869 0109 0831 2D23 0C5F uid Debian Archive Automatic Signing Key (2006) <ftpmaster@debian.org> sig!3 2D230C5F 2006-01-03 Debian Archive Automatic Signing Key (2006) <ftpmaster@debian.org> sig! 2A4E3EAA 2006-01-03 Anthony Towns <aj@azure.humbug.org.au> sig! 4F368D5D 2006-01-03 Debian Archive Automatic Signing Key (2005) <ftpmaster@debian.org> sig! 29982E5A 2006-01-04 Steve Langasek <vorlon@dodds.net> sig! FD6645AB 2006-01-04 Ryan Murray <rmurray@cyberhqz.com> sig! AB2A91F5 2006-01-04 James Troup <james@nocrew.org>
und dann von Ihrem Schlüssel (oder einem Schlüssel, dem Sie vertrauen) den
Pfad
des Vertrauens
zu wenigstens einem der Schlüssel, der verwendet
wurde, um den Archivschlüssel zu unterschreiben, überprüfen. Wenn Sie
vorsichtig sein wollen, sollten Sie Apt mitteilen, dass es dem Schlüssel nur
vertrauen darf, wenn es einen passenden Pfad gefunden hat:
$ gpg --export -a 2D230C5F | sudo apt-key add - Ok
Hinweis: Der aktuelle Schlüssel ist mit dem vorhergehenden Archivschlüssel unterschrieben, so dass Sie theoretisch auf Ihrem alten Vertrauen aufbauen können.
Wie schon erwähnt wird der Schlüssel, mit dem das Debian-Archiv signiert wird, jedes Jahr im Januar ausgetauscht. Da Secure Apt noch jung ist, haben wir noch nicht sehr viel Erfahrung damit und es gibt noch ein paar haarige Stellen.
Im Januar 2006 wurde ein neuer Schlüssel für 2006 erstellt und die
Release
-Datei wurde damit unterschrieben. Um aber zu vermeiden,
dass Systeme, die noch den alten Schlüssel von 2005 verwenden, nicht mehr
korrekt arbeiten, wurde die Release
-Datei auch mit dem alten
Schlüssel unterschrieben. Es war geplant, dass Apt je nach dem verfügbaren
Schlüssel eine der beiden Unterschriften akzeptieren würde. Aber es zeigte
sich ein Fehler in Apt, da es sich weigerte, der Datei zu vertrauen, wenn es
nicht beide Schlüssel hatte und somit beide Unterschriften überprüfen
konnte. Dies wurde in der Version 0.6.43.1 ausgebessert. Es gab auch
Verwirrung darüber, wie der Schlüssel an Benutzer verteilt wird, die bereits
Secure Apt auf ihrem System laufen lassen. Am Anfang wurde er auf die Webseite
hochgeladen, ohne Ankündigung und ohne eine echte Möglichkeit, ihn zu
überprüfen, und die Benutzer mussten ihn per Hand herunterladen.
Ein nicht offensichtliches Problem ist, dass Secure Apt nicht funktioniert, wenn Ihre Uhr sehr verstellt ist. Wenn sie auf ein Datum in der Vergangenheit wie 1999 eingestellt ist, wird Apt mit einer nichts sagenden Ausgabe wie dieser abbrechen:
W: GPG error: http://archive.progeny.com sid Release: Unknown error executing gpg
Dagegen macht apt-key
das Problem deutlich:
gpg: key 2D230C5F was created 192324901 seconds in the future (time warp or clock problem) gpg: key 2D230C5F was created 192324901 seconds in the future (time warp or clock problem) pub 1024D/2D230C5F 2006-01-03 uid Debian Archive Automatic Signing Key (2006) <ftpmaster@debian.org>
Falls die Uhr nicht zu weit vorgeht, behandelt Apt die Schlüssel als abgelaufen.
Wenn Sie Testing oder Unstable verwenden, gibt es ein Problem, wenn Sie in
letzter Zeit nicht apt-get update
ausgeführt haben und mit
apt-get
ein Paket installieren möchten. Apt könnte sich
darüber beschweren, dass es nicht authentifiziert werden konnte (Warum
passiert das bloß?). apt-get update
löst das Problem.
Für den Fall, dass Sie nun zusätzliche Sicherheitsprüfungen einführen wollen, aber nicht die neuste Version von apt einsetzen wollen oder können[66], können Sie das folgende Skript von Anthony Towns benutzen. Dieses Skript führt automatisch neue Sicherheitsüberprüfungen durch, damit ein Benutzer sicher gehen kann, dass die Software, die er herunterlädt, die gleiche ist wie die, die von Debian bereitgestellt wird. Das verhindert, dass sich Debian-Entwickler in ein fremdes System einhacken können, ohne dass eine Zurechnung und Rückverfolgung möglich wäre, die durch das Hochladen eines Pakets auf das Hauptarchiv gewährleistet werden. Es kann auch verhindern, dass ein Spiegel etwas fast genau abbildet, das aber eben doch nicht ganz wie in Debian, oder dass veraltete Versionen von instabilen Paketen mit bekannten Sicherheitslücken zur Verfügung gestellt werden.
Dieser Beispielscode, umbenannt nach apt-check sigs
, sollte auf
die folgende Art benutzt werden:
# apt-get update # apt-check-sigs (... Ergebnisse ...) # apt-get dist-upgrade
Zuerst müssen Sie jedoch Folgendes tun:
Holen Sie sich den Schlüssel, den die Archiv-Software verwendet, um
Release
-Dateien zu signieren, also http://ftp-master.debian.org/ziyi_key_2006.asc
,
und fügen Sie ihn ~/.gnupg/trustedkeys.gpg
hinzu (was
standardmäßig von gpgv
benutzt wird).
gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2006.asc
Entfernen Sie alle Zeilen aus /etc/apt/sources.list
, die nicht die
normale »dists«-Struktur benutzen, oder ändern Sie das Skript, so dass es
auch mit denen funktioniert.
Ignorieren Sie die Tatsache, dass Sicherheitsaktualisierungen von Debian keine
signierten Release
-Dateien haben, und das
Sources
-Dateien (noch) keine richtigen Prüfsummen in der
Release
-Datei haben.
Bereiten Sie sich darauf vor, zu prüfen, dass die richtigen Quellen durch den richtigen Schlüssel signiert wurden.
Dies ist der Beispielscode für apt-check-sigs
. Die neuste
Fassung ist unter http://people.debian.org/~ajt/apt-check-sigs
erhältlich. Dieser Code befindet sich im Moment noch im Beta-Stadium. Für
weitere Informationen sollten Sie http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg00421.html
lesen.
#!/bin/bash # Copyright (c) 2001 Anthony Towns <ajt@debian.org> # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. rm -rf /tmp/apt-release-check mkdir /tmp/apt-release-check || exit 1 cd /tmp/apt-release-check >OK >MISSING >NOCHECK >BAD arch=`dpkg --print-installation-architecture` am_root () { [ `id -u` -eq 0 ] } get_md5sumsize () { cat "$1" | awk '/^MD5Sum:/,/^SHA1:/' | MYARG="$2" perl -ne '@f = split /\s+/; if ($f[3] eq $ENV{"MYARG"}) { print "$f[1] $f[2]\n"; exit(0); }' } checkit () { local FILE="$1" local LOOKUP="$2" Y="`get_md5sumsize Release "$LOOKUP"`" Y="`echo "$Y" | sed 's/^ *//;s/ */ /g'`" if [ ! -e "/var/lib/apt/lists/$FILE" ]; then if [ "$Y" = "" ]; then # No file, but not needed anyway echo "OK" return fi echo "$FILE" >>MISSING echo "MISSING $Y" return fi if [ "$Y" = "" ]; then echo "$FILE" >>NOCHECK echo "NOCHECK" return fi X="`md5sum < /var/lib/apt/lists/$FILE | cut -d\ -f1` `wc -c < /var/lib /apt/lists/$FILE`" X="`echo "$X" | sed 's/^ *//;s/ */ /g'`" if [ "$X" != "$Y" ]; then echo "$FILE" >>BAD echo "BAD" return fi echo "$FILE" >>OK echo "OK" } echo echo "Checking sources in /etc/apt/sources.list:" echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" echo (echo "You should take care to ensure that the distributions you're downloading " echo "are the ones you think you are downloading, and that they are as up to" echo "date as you would expect (testing and unstable should be no more than" echo "two or three days out of date, stable-updates no more than a few weeks" echo "or a month)." ) | fmt echo cat /etc/apt/sources.list | sed 's/^ *//' | grep '^[^#]' | while read ty url dist comps; do if [ "${url%%:*}" = "http" -o "${url%%:*}" = "ftp" ]; then baseurl="${url#*://}" else continue fi echo "Source: ${ty} ${url} ${dist} ${comps}" rm -f Release Release.gpg lynx -reload -dump "${url}/dists/${dist}/Release" >/dev/null 2>&1 wget -q -O Release "${url}/dists/${dist}/Release" if ! grep -q '^' Release; then echo " * NO TOP-LEVEL Release FILE" >Release else origline=`sed -n 's/^Origin: *//p' Release | head -1` lablline=`sed -n 's/^Label: *//p' Release | head -1` suitline=`sed -n 's/^Suite: *//p' Release | head -1` codeline=`sed -n 's/^Codename: *//p' Release | head -1` dateline=`grep "^Date:" Release | head -1` dscrline=`grep "^Description:" Release | head -1` echo " o Origin: $origline/$lablline" echo " o Suite: $suitline/$codeline" echo " o $dateline" echo " o $dscrline" if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeline" ]; then echo " * WARNING: asked for $dist, got $suitline/$codeline" fi lynx -reload -dump "${url}/dists/${dist}/Release.gpg" >/dev/null 2>&1 wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg" gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/null 2>&1 | sed -n "s/^\[GNUPG:\] //p" | (okay=0; err=""; while read gpgcode rest; do if [ "$gpgcode" = "GOODSIG" ]; then if [ "$err" != "" ]; then echo " * Signed by ${err# } key: ${rest#* }" else echo " o Signed by: ${rest#* }" okay=1 fi err="" elif [ "$gpgcode" = "BADSIG" ]; then echo " * BAD SIGNATURE BY: ${rest#* }" err="" elif [ "$gpgcode" = "ERRSIG" ]; then echo " * COULDN'T CHECK SIGNATURE BY KEYID: ${rest %% *}" err="" elif [ "$gpgcode" = "SIGREVOKED" ]; then err="$err REVOKED" elif [ "$gpgcode" = "SIGEXPIRED" ]; then err="$err EXPIRED" fi done if [ "$okay" != 1 ]; then echo " * NO VALID SIGNATURE" >Release fi) fi okaycomps="" for comp in $comps; do if [ "$ty" = "deb" ]; then X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Release" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Release") Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Packages" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Packages") if [ "$X $Y" = "OK OK" ]; then okaycomps="$okaycomps $comp" else echo " * PROBLEMS WITH $comp ($X, $Y)" fi elif [ "$ty" = "deb-src" ]; then X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Release" | sed 's,//*,_,g'`" "${comp}/source/Release") Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Sources" | sed 's,//*,_,g'`" "${comp}/source/Sources") if [ "$X $Y" = "OK OK" ]; then okaycomps="$okaycomps $comp" else echo " * PROBLEMS WITH component $comp ($X, $Y)" fi fi done [ "$okaycomps" = "" ] || echo " o Okay:$okaycomps" echo done echo "Results" echo "~~~~~~~" echo allokay=true cd /tmp/apt-release-check diff <(cat BAD MISSING NOCHECK OK | sort) <(cd /var/lib/apt/lists && find . -type f -maxdepth 1 | sed 's,^\./,,g' | grep '_' | sort) | sed -n 's/^> //p' >UNVALIDATED cd /tmp/apt-release-check if grep -q ^ UNVALIDATED; then allokay=false (echo "The following files in /var/lib/apt/lists have not been validated." echo "This could turn out to be a harmless indication that this script" echo "is buggy or out of date, or it could let trojaned packages get onto" echo "your system." ) | fmt echo sed 's/^/ /' < UNVALIDATED echo fi if grep -q ^ BAD; then allokay=false (echo "The contents of the following files in /var/lib/apt/lists does not" echo "match what was expected. This may mean these sources are out of date," echo "that the archive is having problems, or that someone is actively" echo "using your mirror to distribute trojans." if am_root; then echo "The files have been renamed to have the extension .FAILED and" echo "will be ignored by apt." cat BAD | while read a; do mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED done fi) | fmt echo sed 's/^/ /' < BAD echo fi if grep -q ^ MISSING; then allokay=false (echo "The following files from /var/lib/apt/lists were missing. This" echo "may cause you to miss out on updates to some vulnerable packages." ) | fmt echo sed 's/^/ /' < MISSING echo fi if grep -q ^ NOCHECK; then allokay=false (echo "The contents of the following files in /var/lib/apt/lists could not" echo "be validated due to the lack of a signed Release file, or the lack" echo "of an appropriate entry in a signed Release file. This probably" echo "means that the maintainers of these sources are slack, but may mean" echo "these sources are being actively used to distribute trojans." if am_root; then echo "The files have been renamed to have the extension .FAILED and" echo "will be ignored by apt." cat NOCHECK | while read a; do mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED done fi) | fmt echo sed 's/^/ /' < NOCHECK echo fi if $allokay; then echo 'Everything seems okay!' echo fi rm -rf /tmp/apt-release-check
Sie müssen vielleicht bei Sid diesen Patch verwenden, da
md5sum
ein »-« an die Summe anfügt, wenn die Ausgabe auf stdin
erfolgt:
@@ -37,7 +37,7 @@ local LOOKUP="$2" Y="`get_md5sumsize Release "$LOOKUP"`" - Y="`echo "$Y" | sed 's/^ *//;s/ */ /g'`" + Y="`echo "$Y" | sed 's/-//;s/^ *//;s/ */ /g'`" if [ ! -e "/var/lib/apt/lists/$FILE" ]; then if [ "$Y" = "" ]; then @@ -55,7 +55,7 @@ return fi X="`md5sum < /var/lib/apt/lists/$FILE` `wc -c < /var/lib/apt/lists/$FILE`" - X="`echo "$X" | sed 's/^ *//;s/ */ /g'`" + X="`echo "$X" | sed 's/-//;s/^ *//;s/ */ /g'`" if [ "$X" != "$Y" ]; then echo "$FILE" >>BAD echo "BAD"
Beachten Sie, dass, wenn Sie die neuste Version von Apt (mit Secure
Apt) einsetzen, kein zusätzlicher Aufwand auf Ihrer Seite notwendig sein
sollte, wenn Sie keine Debian-fremden Quellen verwenden. Anderenfalls
erfordert apt-get
eine zusätzliche Bestätigung. Dies wird
verhindert, wenn Release
- und Release.gpg
-Dateien in
den Debian-fremden Quellen zur Verfügung stehen. Die
Release
-Datei kann mit apt-ftparchive
(ist in
apt-utils
0.5.0 und später enthalten) erstellt werden, die
Release.gpg
ist nur die abgetrennte Signatur. Beide können mit
folgender einfacher Prozedur erstellt werden:
$ rm -f dists/unstable/Release $ apt-ftparchive release dists/unstable > dists/unstable/Release $ gpg --sign -ba -o dists/unstable/Release.gpg dists/unstable/Release
Dieser zusätzliche Entwurf, jedes Paket einzeln zu signieren, erlaubt es,
Pakete zu prüfen, selbst wenn sie nicht mehr in irgendeiner
Packages
-Datei erwähnt werden. Und so können auch Pakete von
Dritten, für die es nie eine Packages
-Datei gab, unter Debian
installiert werden. Dies wird aber kein Standard werden.
Dieser Entwurf zur Paketsignierung kann mit debsig-verify
und
debsigs
umgesetzt werden. Diese beiden Pakete können in einer
.deb-Datei eingebettete Unterschriften erstellen und prüfen. Debian hat
bereits jetzt die Möglichkeiten, dies zu tun. Aber es gibt keine Planung,
dieses Regelwerk oder ähnliche Werkzeuge umzusetzen, da nunmehr das Schema mit
der Signierung des Archivs bevorzugt wird. Die Werkzeuge werden dennoch für
Benutzer und Administratoren von Archiven zur Verfügung gestellt, wenn sie
diese Vorgehensweise bevorzugen.
Die aktuellen Versionen von dpkg
(seit 1.9.21) beinhalten einen
Patch
,
der diese Funktionen zur Verfügung stellt, sobald debsig-verify
installiert ist.
HINWEIS: Derzeit wird /etc/dpkg/dpkg.cfg
standardmäßig mit der
Option »no-debsig« ausgeliefert.
HINWEIS 2: Unterschriften von Entwicklern werden im Moment entfernt, wenn sie
in das Paketarchiv gelangen, da die derzeit vorzugswürdige Methode die
Überprüfung der Release
-Datei ist, wie es oben beschrieben
wurde.
[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ weiter ]
Securing Debian Manual
Version: 3.17,mailto:jfs@debian.org