Manpages

NAME

apt-secure − Archivauthentifizierungsunterstützung für APT

BESCHREIBUNG

Starting with version 0.6, APT contains code that does signature checking of the Release file for all repositories. This ensures that data like packages in the archive can't be modified by people who have no access to the Release file signing key. Starting with version 1.1 APT requires repositories to provide recent authentication information for unimpeded usage of the repository. Since version 1.5 changes in the information contained in the Release file about the repository need to be confirmed before APT continues to apply updates from this repository.

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.

UNSIGNED REPOSITORIES

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−Transaktionen 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. Anwendern 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−Transaktion 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.

SIGNED REPOSITORIES

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 das Paket, dem Sie vertrauen, 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 sicherstellt.

apt−secure überprüft keine Signaturen auf einer Ebene des Pakets. 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 Prozeduren 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 Paketdateien 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 dies verschieden von geprüften Signaturen auf Paketbasis ist. Es wurde entworfen, um zwei mögliche Angriffe zu verhindern:

• Network "man in the middle" attacks. Ohne Signaturprüfung kann ein schädlicher Mittelsmann sich selbst in das Herunterladen von Paketen einbringen und Schadsoftware bereitstellen. Dies kann entweder durch Kontrolle eines Netzwerkelements (Router, Switch, etc.) oder durch Umleiten des Netzverkehrs zu einem bösartigen Server (durch ARP− oder DNS−Manipulationsangriffe) erfolgen.

• Mirror network compromise. Ohne Signaturprüfung kann ein schädlicher Mittelsmann einen Spiegelserver kompromittieren und die Dateien darauf verändern, um schädliche Software an alle Anwender 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 Signatur pro Paket ergänzen.

INFORMATION CHANGES

A Release file contains beside the checksums for the files in the repository also general information about the repository like the origin, codename or version number of the release.

This information is shown in various places so a repository owner should always ensure correctness. Further more user configuration like apt_preferences(5) can depend and make use of this information. Since version 1.5 the user must therefore explicitly confirm changes to signal that the user is sufficiently prepared e.g. for the new major release of the distribution shipped in the repository (as e.g. indicated by the codename).

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.

REPOSITORY CONFIGURATION

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

erzeugt einer Release−Datei der obersten Stufe, wenn sie nicht bereits existiert. Sie können dies erledigen, indem Sie apt−ftparchive release (aus apt−utils) ausführen.

Signieren Sie es. Sie können dies tun, indem Sie gpg −−clearsign −o InRelease Release und gpg −abs −o Release.gpg Release ausführen.

Veröffentlichen Sie den Schlüsselfingerabdruck, damit Ihre Anwender 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 wie dies Debian mit debian−archive−keyring macht, um später automatisch Aktualisierungen und Schlüsselwechsel durchführen zu können.

Geben Sie Anweisungen, 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 Anwendern helfen können, Ihren Schlüssel hinzuzufügen, hängt von Ihrem Archiv ab und reicht von der Bereitstellung des Schlüsselrings als Teil eines 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 beiden zuerst skizzierten Schritten folgen.

SIEHE AUCH

apt.conf(5), apt-get(8), sources.list(5), apt-key(8), apt-ftparchive(1), debsign(1), debsig-verify(1), gpg(1)

Um weitere Hintergrundinformationen zu erhalten, können Sie die Die Infrastruktur für Sicherheit in Debian [1] −Kapitel des Handbuchs »Anleitung zum Absichern von Debian« (auch verfügbar im Paket harden−doc) und das Strong Distribution HOWTO [2] von V. Alex Brennen lesen.

BUGS

APT bug page [3] . If you wish to report a bug in APT, please see /usr/share/doc/debian/bug−reporting.txt or the reportbug(1) command.

AUTHOR

APT was written by the APT team <apt [AT] packages.org>.

AUTOREN DER HANDBUCHSEITE

Diese Handbuchseite basiert auf der Arbeit von Javier Fernández−Sanguino Peña, Isaac Jones, Colin Walters, Florian Weimer und Michael Vogt.

TRANSLATION

The english translation was done by John Doe <john [AT] doe.org> in 2009, 2010 and Daniela Acme <daniela [AT] acme.us> in 2010 together with the Debian Dummy l10n Team <debian−l10n−dummy [AT] lists.org>.

Note that this translated document may contain untranslated parts. This is done on purpose, to avoid losing content when the translation is lagging behind the original content.

AUTOREN

Jason Gunthorpe

APT team

FUßNOTEN

1.

Die 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 bug page

http://bugs.debian.org/src:apt

COMMENTS