Apt-secure: Unterschied zwischen den Versionen

Aus Foxwiki
Keine Bearbeitungszusammenfassung
 
(12 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 2: Zeile 2:


== Beschreibung ==
== Beschreibung ==
Beginnend mit Version 0.6 enthält APT Code, der die Signatur der Release-Datei für alle Depots prüft.
Beginnend mit Version 0.6 enthält APT Code, der die Signatur der Release-Datei für alle Depots prüft
* Dies stellt sicher, dass Daten wie Pakete im Archiv nicht von Leuten geändert werden können, die keinen Zugriff auf den Signierschlüssel der Release-Datei haben.
* Dies stellt sicher, dass Daten wie Pakete im Archiv nicht von Leuten geändert werden können, die keinen Zugriff auf den Signierschlüssel der Release-Datei haben
* Beginnend mit Version 1.1 erfordert APT von Depots aktuelle Authentifizierungsinformationen für den ungestörten Gebrauch des Depots bereitzustellen.
* Beginnend mit Version 1.1 erfordert APT von Depots aktuelle Authentifizierungsinformationen für den ungestörten Gebrauch des Depots bereitzustellen
* Seit Version 1.5 müssen Informationen, die in der Release-Datei über das Depot enthalten sind, bestätigt werden, bevor APT mit den Aktualisierungen aus diesem Depot fortfährt.
* Seit Version 1.5 müssen Informationen, die in der Release-Datei über das Depot enthalten sind, bestätigt werden, bevor APT mit den Aktualisierungen aus diesem Depot fortfährt


Hinweis: Alle APT-basierten Paketverwaltungsoberflächen wie apt-get(8), aptitude(8) und synaptic(8) unterstützen diese Authentifizierungsfunktionalität, daher verwendet diese Handbuchseite der Einfachheit halber exemplarisch für alle APT.
; Hinweis
: Alle APT-basierten Paketverwaltungsoberflächen wie [[apt-get]], [[aptitude]] und [[synaptic]] unterstützen diese Authentifizierungsfunktionalität, daher verwendet diese Handbuchseite der Einfachheit halber exemplarisch für alle APT


== NICHT SIGNIERTE DEPOTS ==
== Nicht signierte depots ==
Falls ein Archiv eine nicht signierte oder überhaupt keine Release-Datei hat, werden alle aktuellen APT-Versionen das Herunterladen von Daten von dort standardmäßig in update-Aktionen verweigern.
Falls ein Archiv eine nicht signierte oder überhaupt keine Release-Datei hat, werden alle aktuellen APT-Versionen das Herunterladen von Daten von dort standardmäßig in update-Aktionen verweigern
* Sogar wenn Oberflächen wie apt-get(8) zum Herunterladen gezwungen werden, wird eine explizite Bestätigung benötigt, falls eine Installationsanfrage ein Paket aus einem derartigen nicht authentifizierten Archiv enthält.
* Sogar wenn Oberflächen wie apt-get(8) zum Herunterladen gezwungen werden, wird eine explizite Bestätigung benötigt, falls eine Installationsanfrage ein Paket aus einem derartigen nicht authentifizierten Archiv enthält


Sie können erzwingen, dass alle APT-Clients nur Warnungen ausgeben, indem Sie die Konfigurationsoption Acquire::AllowInsecureRepositories auf true setzen. Über die sources.list(5)-Option allow-insecure=yes kann auch erlaubt werden, dass individuelle Depots unsicher sind.
Sie können erzwingen, dass alle APT-Clients nur Warnungen ausgeben, indem Sie die Konfigurationsoption Acquire::AllowInsecureRepositories auf true setzen. Über die sources.list(5)-Option allow-insecure=yes kann auch erlaubt werden, dass individuelle Depots unsicher sind
* Beachten Sie, dass von unsicheren Depots eindringlich abgeraten wird und alle Optionen, die APT zwingen, sie weiterhin zu unterstützen, irgendwann entfernt werden.
* Beachten Sie, dass von unsicheren Depots eindringlich abgeraten wird und alle Optionen, die APT zwingen, sie weiterhin zu unterstützen, irgendwann entfernt werden
* Benutzern steht auch die Option Trusted zur Verfügung, um sogar Warnungen auszuschalten, seien Sie sich aber sicher, dass Sie die in sources.list(5) erklärten Konsequenzen verstanden haben.
* Benutzern steht auch die Option Trusted zur Verfügung, um sogar Warnungen auszuschalten, seien Sie sich aber sicher, dass Sie die in sources.list(5) erklärten Konsequenzen verstanden haben


Ein Depot, das vorher authentifiziert war, diesen Status jedoch bei einer update-Aktion verlieren würde, gibt auf allen APT-Clients, ungeachtet der Option, die die Verwendung unsicherer Depots erlaubt oder verbietet, einen Fehler aus.
Ein Depot, das vorher authentifiziert war, diesen Status jedoch bei einer update-Aktion verlieren würde, gibt auf allen APT-Clients, ungeachtet der Option, die die Verwendung unsicherer Depots erlaubt oder verbietet, einen Fehler aus
* Der Fehler kann durch zusätzliches Setzen von Acquire::AllowDowngradeToInsecureRepositories auf true oder für individuelle Depots mit der sources.list(5)-Option allow-downgrade-to-insecure=yes übergangen werden.
* Der Fehler kann durch zusätzliches Setzen von Acquire::AllowDowngradeToInsecureRepositories auf true oder für individuelle Depots mit der sources.list(5)-Option allow-downgrade-to-insecure=yes übergangen werden


== SIGNIERTE DEPOTS ==
== Signierte depots ==
Eine Kette des Vertrauens von einem APT-Archiv zum Endanwender wird durch verschiedene Schritte erreicht.
Eine Kette des Vertrauens von einem APT-Archiv zum Endanwender wird durch verschiedene Schritte erreicht
* apt-secure ist der letzte Schritt in dieser Kette.
* apt-secure ist der letzte Schritt in dieser Kette
* Einem Archiv zu vertrauen bedeutet nicht, dass Sie vertrauen, dass das Paket keinen schadhaften Code enthält, aber es bedeutet, dass Sie dem Archivbetreuer vertrauen.
* Einem Archiv zu vertrauen bedeutet nicht, dass Sie vertrauen, dass das Paket keinen schadhaften Code enthält, aber es bedeutet, dass Sie dem Archivbetreuer vertrauen
* Der Archivbetreuer ist dafür verantwortlich, dass er die Korrektheit der Integrität des Archivs aufrechterhält.
* Der Archivbetreuer ist dafür verantwortlich, dass er die Korrektheit der Integrität des Archivs aufrechterhält


apt-secure überprüft keine Signaturen auf einer Stufe der Pakete.
apt-secure überprüft keine Signaturen auf einer Stufe der Pakete
* Falls Sie ein Werkzeug benötigen, das dies tut, sollten Sie einen Blick auf debsig-verify und debsign werfen (bereitgestellt von den Paketen debsig-verify beziehungsweise devscripts).
* Falls Sie ein Werkzeug benötigen, das dies tut, sollten Sie einen Blick auf debsig-verify und debsign werfen (bereitgestellt von den Paketen debsig-verify beziehungsweise devscripts)


Die Kette des Vertrauens in Debian beginnt (z.B.), wenn ein Betreuer ein neues Paket oder eine neue Version eines Pakets in das Debian-Archiv hochlädt.
Die Kette des Vertrauens in Debian beginnt (z.B.), wenn ein Betreuer ein neues Paket oder eine neue Version eines Pakets in das Debian-Archiv hochlädt
* Damit es in Kraft tritt muss dieses Hochladen mit einem Schlüssel signiert werden, der sich in einem der Schlüsselbunde der Debian-Betreuer befindet (verfügbar im Paket »debian-keyring«).
* Damit es in Kraft tritt muss dieses Hochladen mit einem Schlüssel signiert werden, der sich in einem der Schlüsselbunde der Debian-Betreuer befindet (verfügbar im Paket »debian-keyring«)
* Betreuerschlüssel werden von anderen Betreuern gemäß vorbestimmter Regeln signiert, um die Identität des Schlüsselinhabers sicherzustellen. Ähnliche Abläufe existieren in allen Debian-basierten Distributionen.
* Betreuerschlüssel werden von anderen Betreuern gemäß vorbestimmter Regeln signiert, um die Identität des Schlüsselinhabers sicherzustellen. Ähnliche Abläufe existieren in allen Debian-basierten Distributionen


Sobald das hochgeladene Paket überprüft und dem Archiv hinzugefügt wurde, wird die Betreuersignatur entfernt, Prüfsummen des Pakets werden berechnet und in die Datei Packages abgelegt.
Sobald das hochgeladene Paket überprüft und dem Archiv hinzugefügt wurde, wird die Betreuersignatur entfernt, Prüfsummen des Pakets werden berechnet und in die Datei Packages abgelegt
* Die Prüfsummen aller Packages-Dateien werden berechnet und in der Release-Datei abgelegt.
* Die Prüfsummen aller Packages-Dateien werden berechnet und in der Release-Datei abgelegt
* Dann wird die Release-Datei durch den Archivschlüssel für diese Debian-Veröffentlichung signiert und zusammen mit den Paketen und Packages-Dateien auf Debian-Spiegel verteilt.
* Dann wird die Release-Datei durch den Archivschlüssel für diese Debian-Veröffentlichung signiert und zusammen mit den Paketen und Packages-Dateien auf Debian-Spiegel verteilt
* Die Schlüssel sind im Debian-Archivschlüsselbund im Paket debian-archive-keyring verfügbar.
* Die Schlüssel sind im Debian-Archivschlüsselbund im Paket debian-archive-keyring verfügbar


Endanwender können die Signatur der Release-Datei prüfen, die Prüfsumme eines Paketes daraus entpacken und mit der Prüfsumme des Pakets vergleichen, das sie manuell heruntergeladen haben – oder sich darauf verlassen, dass APT dies automatisch tut.
Endanwender können die Signatur der Release-Datei prüfen, die Prüfsumme eines Paketes daraus entpacken und mit der Prüfsumme des Pakets vergleichen, das sie manuell heruntergeladen haben – oder sich darauf verlassen, dass APT dies automatisch tut


Beachten Sie, dass sich dies vom Prüfen gvonn Signaturen auf Paketbasis unterscheidet.
Beachten Sie, dass sich dies vom Prüfen gvonn Signaturen auf Paketbasis unterscheidet
* Es wurde entworfen, um zwei mögliche Angriffe zu verhindern:
* Es wurde entworfen, um zwei mögliche Angriffe zu verhindern
»Man-in-the-middle«-Netzwerkangriffe
»Man-in-the-middle«-Netzwerkangriffe
* Ohne Signaturprüfung kann ein schädlicher Mittelsmann sich selbst in das Herunterladen von Paketen einbringen und Schadsoftware bereitstellen.
* Ohne Signaturprüfung kann ein schädlicher Mittelsmann sich selbst in das Herunterladen von Paketen einbringen und Schadsoftware bereitstellen
* Dies kann entweder durch Steuerung eines Netzwerkelements (Router, Switch, usw.) oder durch Umleiten des Netzverkehrs zu einem bösartigen Server (durch ARP- oder DNS-Manipulationsangriffe) erfolgen.
* Dies kann entweder durch Steuerung eines Netzwerkelements (Router, Switch, usw.) oder durch Umleiten des Netzverkehrs zu einem bösartigen Server (durch ARP- oder DNS-Manipulationsangriffe) erfolgen
Spiegelnetzwerk-Gefährdung
Spiegelnetzwerk-Gefährdung
* Ohne Signaturprüfung kann ein schädlicher Mittelsmann einen Spiegelserver kompromittieren und die Dateien darauf verändern, um schädliche Software an alle Benutzer zu verbreiten, die Pakete von diesem Rechner herunterladen.
* Ohne Signaturprüfung kann ein schädlicher Mittelsmann einen Spiegelserver kompromittieren und die Dateien darauf verändern, um schädliche Software an alle Benutzer zu verbreiten, die Pakete von diesem Rechner herunterladen


Es schützt jedoch nicht gegen eine Kompromittierung des Hauptservers selbst (der die Pakete signiert) oder gegen eine Kompromittierung des Schlüssels, der zum Signieren der Release-Dateien benutzt wird.
Es schützt jedoch nicht gegen eine Kompromittierung des Hauptservers selbst (der die Pakete signiert) oder gegen eine Kompromittierung des Schlüssels, der zum Signieren der Release-Dateien benutzt wird
* In jedem Fall kann dieser Mechanismus eine paketbasierte Signatur ergänzen.
* In jedem Fall kann dieser Mechanismus eine paketbasierte Signatur ergänzen


== INFORMATIONSÄNDERUNGEN ==
== Informationsänderungen ==
Eine Release-Datei enthält neben der Prüfsumme für die Dateien in dem Depot auch allgemeine Informationen über das Depot wie die Herkunft, den Codenamen oder die Versionsnummer der Veröffentlichung.
Eine Release-Datei enthält neben der Prüfsumme für die Dateien in dem Depot auch allgemeine Informationen über das Depot wie die Herkunft, den Codenamen oder die Versionsnummer der Veröffentlichung


Diese Informationen werden an verschiedenen Stellen angezeigt, daher sollte ein Depot-Besitzer immer die Richtigkeit sicherstellen können.
Diese Informationen werden an verschiedenen Stellen angezeigt, daher sollte ein Depot-Besitzer immer die Richtigkeit sicherstellen können
* Des Weiteren kann weitere Benutzerkonfiguration wie apt_preferences(5) kann von diesen Informationen abhängen und sie benutzen.
* Des Weiteren kann weitere Benutzerkonfiguration wie apt_preferences(5) kann von diesen Informationen abhängen und sie benutzen
* Seit Version 1.5 muss der Benutzer daher Änderungen explizit bestätigen, um erkennen zu lassen, dass er ausreichend darauf vorbereitet ist, z. B. auf das neue Major Release der Distribution, das im Depot ausgeliefert wird (z. B. durch den Codenamen angegeben).
* Seit Version 1.5 muss der Benutzer daher Änderungen explizit bestätigen, um erkennen zu lassen, dass er ausreichend darauf vorbereitet ist, z. B. auf das neue Major Release der Distribution, das im Depot ausgeliefert wird (z. B. durch den Codenamen angegeben)


== BENUTZERKONFIGURATION ==
== Benutzerkonfiguration ==
apt-key ist das Programm, das die Liste der von APT verwendeten Schlüssel verwaltet, aufgrund derer es Depots vertraut.
apt-key ist das Programm, das die Liste der von APT verwendeten Schlüssel verwaltet, aufgrund derer es Depots vertraut
* Es kann benutzt werden, um Schlüssel hinzuzufügen oder zu entfernen, sowie um vertrauenswürdige Schlüssel aufzulisten.
* Es kann benutzt werden, um Schlüssel hinzuzufügen oder zu entfernen, sowie um vertrauenswürdige Schlüssel aufzulisten
* Welche(r)
* Welche(r)
Schlüssel welches Archiv signieren kann/können, kann per Signed-By in sources.list(5) eingeschränkt werden.
Schlüssel welches Archiv signieren kann/können, kann per Signed-By in sources.list(5) eingeschränkt werden


Beachten Sie, dass eine Standardinstallation bereits alle Schlüssel zum sicheren Beschaffen von Paketen aus den Standarddepots enthält, daher ist das Frickeln mit apt-key nur nötig, wenn Drittanbieterdepots hinzugefügt werden.
Beachten Sie, dass eine Standardinstallation bereits alle Schlüssel zum sicheren Beschaffen von Paketen aus den Standarddepots enthält, daher ist das Frickeln mit apt-key nur nötig, wenn Drittanbieterdepots hinzugefügt werden


Um einen neuen Schlüssel hinzuzufügen, müssen Sie ihn zuerst herunterladen (Sie sollten sicherstellen, dass Sie einen vertrauenswürdigen Kommunikationskanal benutzen, wenn Sie ihn herunterladen), ihn mit apt-key hinzufügen und dann apt-get update ausführen, so dass APT die Dateien InRelease oder Release.gpg der von Ihnen konfigurierten Archive herunterladen und prüfen kann.
Um einen neuen Schlüssel hinzuzufügen, müssen Sie ihn zuerst herunterladen (Sie sollten sicherstellen, dass Sie einen vertrauenswürdigen Kommunikationskanal benutzen, wenn Sie ihn herunterladen), ihn mit apt-key hinzufügen und dann apt-get update ausführen, so dass APT die Dateien InRelease oder Release.gpg der von Ihnen konfigurierten Archive herunterladen und prüfen kann


== DEPOTKONFIGURATION ==
== Depotkonfiguration ==
Wenn Sie Archivsignaturen in einem von Ihnen betreuten Archiv zur Verfügung stellen möchten, müssen Sie:
Wenn Sie Archivsignaturen in einem von Ihnen betreuten Archiv zur Verfügung stellen möchten, müssen Sie
* Eine Release-Datei der obersten Stufe erzeugen, wenn sie nicht bereits existiert.
* Eine Release-Datei der obersten Stufe erzeugen, wenn sie nicht bereits existiert
* Sie können dies erledigen, indem Sie apt-ftparchive release (aus apt-utils) ausführen.
* Sie können dies erledigen, indem Sie apt-ftparchive release (aus apt-utils) ausführen
* Sie signieren.
* Sie signieren
* Sie können dies tun, indem Sie gpg --clearsign -o InRelease Release und gpg -abs -o Release.gpg Release ausführen.
* Sie können dies tun, indem Sie gpg --clearsign -o InRelease Release und gpg -abs -o Release.gpg Release ausführen
* Den Schlüsselfingerabdruck veröffentlichen, damit Ihre Benutzer wissen, welchen Schlüssel sie importieren müssen, um die Dateien im Archiv zu authentifizieren.
* Den Schlüsselfingerabdruck veröffentlichen, damit Ihre Benutzer wissen, welchen Schlüssel sie importieren müssen, um die Dateien im Archiv zu authentifizieren
* Am besten liefern Sie Ihren Schlüssel in einem eigenen Paket aus, wie dies Debian mit debian-archive-keyring macht, um später automatisch Aktualisierungen und Schlüsselwechsel durchführen zu können.
* Am besten liefern Sie Ihren Schlüssel in einem eigenen Paket aus, wie dies Debian mit debian-archive-keyring macht, um später automatisch Aktualisierungen und Schlüsselwechsel durchführen zu können
* Anweisungen geben, wie Ihr Archiv und Ihr Schlüssel hinzugefügt werden können.
* Anweisungen geben, wie Ihr Archiv und Ihr Schlüssel hinzugefügt werden können
* Falls Ihre Benutzer Ihren Schlüssel nicht auf sichere Weise beschaffen können, ist die oben beschriebene Kette des Vertrauens unterbrochen.
* Falls Ihre Benutzer Ihren Schlüssel nicht auf sichere Weise beschaffen können, ist die oben beschriebene Kette des Vertrauens unterbrochen
* Wie Sie Benutzern helfen können, Ihren Schlüssel hinzuzufügen, hängt von Ihrem Archiv und Ihrer Zielgruppe ab und reicht von der Bereitstellung des Schlüsselrings als Teil eines anderen Archivs, das bei Ihren Benutzern bereits konfiguriert ist (wie den Standarddepots ihrer Distribution), bis hin zum Nutzen des Vertrauensnetzes.
* Wie Sie Benutzern helfen können, Ihren Schlüssel hinzuzufügen, hängt von Ihrem Archiv und Ihrer Zielgruppe ab und reicht von der Bereitstellung des Schlüsselrings als Teil eines anderen Archivs, das bei Ihren Benutzern bereits konfiguriert ist (wie den Standarddepots ihrer Distribution), bis hin zum Nutzen des Vertrauensnetzes


Immer wenn sich die Inhalte des Archivs ändern (neue Pakete hinzugefügt oder entfernt werden), muss der Archivbetreuer den zwei ersten der oben skizzierten Schritten folgen.
Immer wenn sich die Inhalte des Archivs ändern (neue Pakete hinzugefügt oder entfernt werden), muss der Archivbetreuer den zwei ersten der oben skizzierten Schritten folgen


== SIEHE AUCH ==
<noinclude>
 
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/apt}}
==== Links ====
===== Manpages =====
# apt.conf(5)
# apt.conf(5)
# apt-get(8)
# apt-get(8)
Zeile 91: Zeile 98:
# debsig-verify(1)
# debsig-verify(1)
# gpg(1)
# gpg(1)
# apt-get(8)
# aptitude(8)
# synaptic(8)


Um weitere Hintergrundinformationen zu erhalten, können Sie das Kapitel Die Infrastruktur für Sicherheit in Debian[1] des Handbuchs »Anleitung zum Absichern von Debian« (auch im Paket harden-doc verfügbar) und das Strong Distribution HOWTO[2] von V.&nbsp;Alex Brennen lesen.
# Die Infrastruktur für Sicherheit in Debian https://www.debian.org/doc/manuals/securing-debian-howto/ch7
# Strong Distribution HOWTO http://www.cryptnet.net/fdp/crypto/strong_distro.html
# APT-Fehlerseite https://bugs.debian.org/src:apt
<noinclude>
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
==== Links ====
===== Weblinks =====
===== Weblinks =====
# Infrastruktur für Sicherheit in Debian
#: https://www.debian.org/doc/manuals/securing-debian-howto/ch7
# Strong Distribution HOWTO
#: http://www.cryptnet.net/fdp/crypto/strong_distro.html
# APT-Fehlerseite
#: https://bugs.debian.org/src:apt


[[Kategorie:APT]]
[[Kategorie:APT]]
</noinclude>
</noinclude>

Aktuelle Version vom 8. September 2024, 11:12 Uhr

apt-secure - Archivauthentifizierungsunterstützung für APT

Beschreibung

Beginnend mit Version 0.6 enthält APT Code, der die Signatur der Release-Datei für alle Depots prüft

  • Dies stellt sicher, dass Daten wie Pakete im Archiv nicht von Leuten geändert werden können, die keinen Zugriff auf den Signierschlüssel der Release-Datei haben
  • Beginnend mit Version 1.1 erfordert APT von Depots aktuelle Authentifizierungsinformationen für den ungestörten Gebrauch des Depots bereitzustellen
  • Seit Version 1.5 müssen Informationen, die in der Release-Datei über das Depot enthalten sind, bestätigt werden, bevor APT mit den Aktualisierungen aus diesem Depot fortfährt
Hinweis
Alle APT-basierten Paketverwaltungsoberflächen wie apt-get, aptitude und synaptic unterstützen diese Authentifizierungsfunktionalität, daher verwendet diese Handbuchseite der Einfachheit halber exemplarisch für alle APT

Nicht signierte depots

Falls ein Archiv eine nicht signierte oder überhaupt keine Release-Datei hat, werden alle aktuellen APT-Versionen das Herunterladen von Daten von dort standardmäßig in update-Aktionen verweigern

  • Sogar wenn Oberflächen wie apt-get(8) zum Herunterladen gezwungen werden, wird eine explizite Bestätigung benötigt, falls eine Installationsanfrage ein Paket aus einem derartigen nicht authentifizierten Archiv enthält

Sie können erzwingen, dass alle APT-Clients nur Warnungen ausgeben, indem Sie die Konfigurationsoption Acquire::AllowInsecureRepositories auf true setzen. Über die sources.list(5)-Option allow-insecure=yes kann auch erlaubt werden, dass individuelle Depots unsicher sind

  • Beachten Sie, dass von unsicheren Depots eindringlich abgeraten wird und alle Optionen, die APT zwingen, sie weiterhin zu unterstützen, irgendwann entfernt werden
  • Benutzern steht auch die Option Trusted zur Verfügung, um sogar Warnungen auszuschalten, seien Sie sich aber sicher, dass Sie die in sources.list(5) erklärten Konsequenzen verstanden haben

Ein Depot, das vorher authentifiziert war, diesen Status jedoch bei einer update-Aktion verlieren würde, gibt auf allen APT-Clients, ungeachtet der Option, die die Verwendung unsicherer Depots erlaubt oder verbietet, einen Fehler aus

  • Der Fehler kann durch zusätzliches Setzen von Acquire::AllowDowngradeToInsecureRepositories auf true oder für individuelle Depots mit der sources.list(5)-Option allow-downgrade-to-insecure=yes übergangen werden

Signierte depots

Eine Kette des Vertrauens von einem APT-Archiv zum Endanwender wird durch verschiedene Schritte erreicht

  • apt-secure ist der letzte Schritt in dieser Kette
  • Einem Archiv zu vertrauen bedeutet nicht, dass Sie vertrauen, dass das Paket keinen schadhaften Code enthält, aber es bedeutet, dass Sie dem Archivbetreuer vertrauen
  • Der Archivbetreuer ist dafür verantwortlich, dass er die Korrektheit der Integrität des Archivs aufrechterhält

apt-secure überprüft keine Signaturen auf einer Stufe der Pakete

  • Falls Sie ein Werkzeug benötigen, das dies tut, sollten Sie einen Blick auf debsig-verify und debsign werfen (bereitgestellt von den Paketen debsig-verify beziehungsweise devscripts)

Die Kette des Vertrauens in Debian beginnt (z.B.), wenn ein Betreuer ein neues Paket oder eine neue Version eines Pakets in das Debian-Archiv hochlädt

  • Damit es in Kraft tritt muss dieses Hochladen mit einem Schlüssel signiert werden, der sich in einem der Schlüsselbunde der Debian-Betreuer befindet (verfügbar im Paket »debian-keyring«)
  • Betreuerschlüssel werden von anderen Betreuern gemäß vorbestimmter Regeln signiert, um die Identität des Schlüsselinhabers sicherzustellen. Ähnliche Abläufe existieren in allen Debian-basierten Distributionen

Sobald das hochgeladene Paket überprüft und dem Archiv hinzugefügt wurde, wird die Betreuersignatur entfernt, Prüfsummen des Pakets werden berechnet und in die Datei Packages abgelegt

  • Die Prüfsummen aller Packages-Dateien werden berechnet und in der Release-Datei abgelegt
  • Dann wird die Release-Datei durch den Archivschlüssel für diese Debian-Veröffentlichung signiert und zusammen mit den Paketen und Packages-Dateien auf Debian-Spiegel verteilt
  • Die Schlüssel sind im Debian-Archivschlüsselbund im Paket debian-archive-keyring verfügbar

Endanwender können die Signatur der Release-Datei prüfen, die Prüfsumme eines Paketes daraus entpacken und mit der Prüfsumme des Pakets vergleichen, das sie manuell heruntergeladen haben – oder sich darauf verlassen, dass APT dies automatisch tut

Beachten Sie, dass sich dies vom Prüfen gvonn Signaturen auf Paketbasis unterscheidet

  • Es wurde entworfen, um zwei mögliche Angriffe zu verhindern

»Man-in-the-middle«-Netzwerkangriffe

  • Ohne Signaturprüfung kann ein schädlicher Mittelsmann sich selbst in das Herunterladen von Paketen einbringen und Schadsoftware bereitstellen
  • Dies kann entweder durch Steuerung eines Netzwerkelements (Router, Switch, usw.) oder durch Umleiten des Netzverkehrs zu einem bösartigen Server (durch ARP- oder DNS-Manipulationsangriffe) erfolgen

Spiegelnetzwerk-Gefährdung

  • Ohne Signaturprüfung kann ein schädlicher Mittelsmann einen Spiegelserver kompromittieren und die Dateien darauf verändern, um schädliche Software an alle Benutzer zu verbreiten, die Pakete von diesem Rechner herunterladen

Es schützt jedoch nicht gegen eine Kompromittierung des Hauptservers selbst (der die Pakete signiert) oder gegen eine Kompromittierung des Schlüssels, der zum Signieren der Release-Dateien benutzt wird

  • In jedem Fall kann dieser Mechanismus eine paketbasierte Signatur ergänzen

Informationsänderungen

Eine Release-Datei enthält neben der Prüfsumme für die Dateien in dem Depot auch allgemeine Informationen über das Depot wie die Herkunft, den Codenamen oder die Versionsnummer der Veröffentlichung

Diese Informationen werden an verschiedenen Stellen angezeigt, daher sollte ein Depot-Besitzer immer die Richtigkeit sicherstellen können

  • Des Weiteren kann weitere Benutzerkonfiguration wie apt_preferences(5) kann von diesen Informationen abhängen und sie benutzen
  • Seit Version 1.5 muss der Benutzer daher Änderungen explizit bestätigen, um erkennen zu lassen, dass er ausreichend darauf vorbereitet ist, z. B. auf das neue Major Release der Distribution, das im Depot ausgeliefert wird (z. B. durch den Codenamen angegeben)

Benutzerkonfiguration

apt-key ist das Programm, das die Liste der von APT verwendeten Schlüssel verwaltet, aufgrund derer es Depots vertraut

  • Es kann benutzt werden, um Schlüssel hinzuzufügen oder zu entfernen, sowie um vertrauenswürdige Schlüssel aufzulisten
  • Welche(r)

Schlüssel welches Archiv signieren kann/können, kann per Signed-By in sources.list(5) eingeschränkt werden

Beachten Sie, dass eine Standardinstallation bereits alle Schlüssel zum sicheren Beschaffen von Paketen aus den Standarddepots enthält, daher ist das Frickeln mit apt-key nur nötig, wenn Drittanbieterdepots hinzugefügt werden

Um einen neuen Schlüssel hinzuzufügen, müssen Sie ihn zuerst herunterladen (Sie sollten sicherstellen, dass Sie einen vertrauenswürdigen Kommunikationskanal benutzen, wenn Sie ihn herunterladen), ihn mit apt-key hinzufügen und dann apt-get update ausführen, so dass APT die Dateien InRelease oder Release.gpg der von Ihnen konfigurierten Archive herunterladen und prüfen kann

Depotkonfiguration

Wenn Sie Archivsignaturen in einem von Ihnen betreuten Archiv zur Verfügung stellen möchten, müssen Sie

  • Eine Release-Datei der obersten Stufe erzeugen, wenn sie nicht bereits existiert
  • Sie können dies erledigen, indem Sie apt-ftparchive release (aus apt-utils) ausführen
  • Sie signieren
  • Sie können dies tun, indem Sie gpg --clearsign -o InRelease Release und gpg -abs -o Release.gpg Release ausführen
  • Den Schlüsselfingerabdruck veröffentlichen, damit Ihre Benutzer wissen, welchen Schlüssel sie importieren müssen, um die Dateien im Archiv zu authentifizieren
  • Am besten liefern Sie Ihren Schlüssel in einem eigenen Paket aus, wie dies Debian mit debian-archive-keyring macht, um später automatisch Aktualisierungen und Schlüsselwechsel durchführen zu können
  • Anweisungen geben, wie Ihr Archiv und Ihr Schlüssel hinzugefügt werden können
  • Falls Ihre Benutzer Ihren Schlüssel nicht auf sichere Weise beschaffen können, ist die oben beschriebene Kette des Vertrauens unterbrochen
  • Wie Sie Benutzern helfen können, Ihren Schlüssel hinzuzufügen, hängt von Ihrem Archiv und Ihrer Zielgruppe ab und reicht von der Bereitstellung des Schlüsselrings als Teil eines anderen Archivs, das bei Ihren Benutzern bereits konfiguriert ist (wie den Standarddepots ihrer Distribution), bis hin zum Nutzen des Vertrauensnetzes

Immer wenn sich die Inhalte des Archivs ändern (neue Pakete hinzugefügt oder entfernt werden), muss der Archivbetreuer den zwei ersten der oben skizzierten Schritten folgen


Anhang

Siehe auch

Links

Manpages
  1. apt.conf(5)
  2. apt-get(8)
  3. sources.list(5)
  4. apt-key(8)
  5. apt-ftparchive(1)
  6. debsign(1)
  7. debsig-verify(1)
  8. gpg(1)
  9. apt-get(8)
  10. aptitude(8)
  11. synaptic(8)
Weblinks
  1. Infrastruktur für Sicherheit in Debian
    https://www.debian.org/doc/manuals/securing-debian-howto/ch7
  2. Strong Distribution HOWTO
    http://www.cryptnet.net/fdp/crypto/strong_distro.html
  3. APT-Fehlerseite
    https://bugs.debian.org/src:apt