<!-- CVS revision of original english document "1.28" -->

<chapt>Die Infrastruktur für Sicherheit in Debian

<sect id="debian-sec-team">Das Sicherheitsteam von Debian

<p>Debian hat ein Sicherheitsteam, das aus fünf Mitgliedern und zwei Sekretären
besteht. Es ist für die Sicherheit in der <em>Stable</em>-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 <em>Stable</em>-Veröffentlichung betroffen ist.

<p>Das Sicherheitsteam von Debian ist auch der Ansprechpartner für Probleme, die
von den Programmautoren oder Organisationen wie <url id="http://www.cert.org"
name="CERT"> behandelt werden und die mehrere Linux-Anbieter betreffen
können. Das gilt für alle Probleme, die nicht debianspezifisch sind. Es gibt
zwei Möglichkeiten, um mit dem Sicherheitsteam in Verbindung zu treten:

<list>

<item><url id="mailto:team@security.debian.org"
name="team@security.debian.org">, die nur die Mitglieder des Sicherheitsteams
lesen.

<item><url id="mailto:security@debian.org" name="security@debian.org">, die von
allen Debian-Entwicklern gelesen wird (einschließlich des
Sicherheitsteams). E-Mails, die an diese Liste geschickt werden, werden nicht
im Internet veröffentlicht (es handelt sich also nicht um eine öffentliche
Mailingliste).

</list>

<p>Heikle Informationen sollten an die erste Adresse geschickt werden und unter
Umständen mit dem Schlüssel von Debian Security Contact (Schlüssel-ID 363CCD95)
verschlüsselt werden.

<p>Wenn das Sicherheitsteam ein mögliches Problem erhält, wird es untersuchen,
ob die <em>Stable</em>-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 eine Versionen weiter ist als das in
Debian). Nachdem die Ausbesserung getestet wurde, werden neue Pakete
vorbereitet und auf der Seite <url id="security-master.debian.org"> veröffentlicht,
damit sie mit <prgn>apt</prgn> abgerufen werden können (siehe <ref
id="security-update">). Zur gleichen Zeit wird eine
<em>Debian-Sicherheits-Ankündigung</em> (DSA) auf der Webseite veröffentlicht und
an öffentliche Mailinglisten einschließlich <url
id="http://lists.debian.org/debian-security-announce" name="debian-security-announce">
und Bugtraq geschickt.

<p>Einige andere häufige Fragen zum Sicherheitsteam von Debian können unter <ref
id="debian-sec-team-faq"> gefunden werden.


<sect id="dsa">Debian-Sicherheits-Ankündigungen

<p>Debian-Sicherheits-Ankündigungen (DSA) werden erstellt, sobald eine Sicherheitslücke
entdeckt wird, die ein Debian-Paket berührt. Diese Anweisungen, 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:

<list>
<item>Versionsnummer der Ausbesserung.
<item>Art des Problems.
<item>Ob es aus der Ferne oder lokal ausnutzbar ist.
<item>Kurze Beschreibung des Pakets.
<item>Beschreibung des Problems.
<item>Beschreibung des Exploits.
<item>Beschreibung der Ausbesserung.
</list>

<p>DSAs werden sowohl auf der <url id="http://www.de.debian.org/"
name="Hauptseite von Debian"> als auch auf den <url
id="http://www.debian.org/security/" name="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.

<p>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
<footnote>
Übersetzungen sind in bis zu zehn verschiedenen Sprachen verfügbar.
</footnote>
werden nicht an die Sicherheitsmailinglisten geschickt, sondern sind direkt auf
der Webseite enthalten.


<sect1 id="crossreference">Querverweise der Verwundbarkeiten

<p>Debian stellt eine vollständige <url
id="http://www.de.debian.org/security/crossreferences" name="Tabelle mit
Querverweisen"> zur Verfügung, die alle verfügbaren Verweise für die
Anweisungen seit 1998 enthält. Diese Tabelle soll die <url
id="http://cve.mitre.org/cve/refs/refmap/source-DEBIAN.html"
name="Verweisübersicht von CVE"> ergänzen.

<p>Sie werden bemerkt haben, dass die Tabelle Verweise auf
Sicherheitsdatenbanken wie <url id="http://www.securityfocus.com/bid"
name="Bugtraq">,
<url id="http://www.cert.org/advisories/" name="CERT/CC Anweisungen">
und <url id="http://www.kb.cert.org/vuls" name="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.

<p>Das Hinzufügen von Querverweisen auf diese Sicherheitsdatenbanken hat
folgende Vorteile:

<list>

<item>Es erleichtert Benutzern von Debian zu erkennen und nachzuvollziehen,
welche allgemeinen (veröffentlichten) Anweisungen schon von Debian abgedeckt
wurden.

<item>Systemadministratoren können mehr über die Verwundbarkeit und ihre
Auswirkungen lernen, wenn sie den Querverweisen folgen.

<item>Diese Informationen können benutzt werden, um Ausgaben von
Verwundbarkeitsscannern, die Verweise auf CVE enthalten, zu überprüfen, um
falsche Positivmeldungen auszusortieren (vergleichen Sie <ref
id="vulnasses-false-positive">).

</list>
</sect1>


<sect1 id="cve-compatible">CVE-Kompatibilität

<p>Debians Sicherheitsankündigungen wurden am 24. Februar 2004 <url
id="http://www.de.debian.org/security/CVE-certificate.jpg"
name="CVE-kompatibel erklärt">
<footnote>
Der vollständige <url
id="http://cve.mitre.org/compatible/phase2/SPI_Debian.html"
name="Fragebogen zur Kompatibilität"> ist bei CVE erhältlich.
</footnote>.

<p>Die Entwickler von Debian verstehen die 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 Nutzern ermöglicht, einen <url
id="http://www.cve.mitre.org/compatible/enterprise.html" name="Prozess zur
Verwaltung der Sicherheit auf Grundlage von CVE"> zu entwickeln.

<p>Das Projekt <url id="http://cve.mitre.org" name="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.

<p>Debian ist überzeugt, dass es außerordentlich wichtig ist, die Nutzer mit
zusätzlichen Informationen im Zusammenhang mit Sicherheitsproblemen, die die
Debian-Distribution betreffen, zu versorgen. Indem CVE-Bezeichnungen in den
Anweisungen enthalten sind, können Nutzer leichter allgemeine Verwundbarkeiten
mit bestimmten Aktualisierungen von Debian in Verbindung bringen. Dies
verringert die Zeit, die benötigt wird, um Verwundbarkeiten, die unsere Nutzer
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.

<p>Debian begann im Juni 2002, CVE-Bezeichnung zu den DSAs hinzuzufügen. Jetzt
sind CVE-Bezeichnungen in allen DSAs seit September 1998 enthalten, nachdem die
Nachprüfungsphase im August 2002 begonnen wurde. Alle Anweisungen 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. Anweisungen, die mit einer bestimmten
CVE-Bezeichnung verbunden sind, können direkt über die <url
id="http://search.debian.org/" name="Suchmaschine"> gesucht werden.

<p>Benutzer, die nach einer bestimmten CVE-Bezeichnung suchen wollen, können
auch die Suchmaschine verwenden, die auf debian.org verfügbar ist, um die
verfügbaren Anweisungen (auf Englisch und Übersetzungen in andere Sprachen),
die mit den CVE-Bezeichnungen verbunden sind, abzurufen. Eine Suche kann nach
einem bestimmten Begriff (z.B. nach der Anweisung <url
id="http://search.debian.org/?q=advisory+%22CAN-2002-0001%22&amp;ps=50&amp;o=1&amp;m=all"
name="CAN-2002-0001">) oder nach einem Teilbegriff (z.B. alle Kandidaten von
2002, die in Anweisungen enthalten sind, finden Sie mit der Suche nach <url
id="http://search.debian.org/?q=advisory+%22CAN-2002%22&amp;ps=50&amp;o=1&amp;m=all"
name="CAN-2002">) durchgeführt werden. Beachten Sie, dass Sie das Wort
"advisory" zusammen mit der CVE-Bezeichnung eingeben müssen, um nur die
Sicherheitsankündigungen zu erhalten.

<p>In einige Fällen finden Sie eine bestimmte CVE-Bezeichnung in
veröffentlichten Anweisungen nicht. Beispiele dafür sind:

<list>
<item>Keine Produkte von Debian sind von der Verwundbarkeit betroffen.

<item>Es gibt noch keine Anweisung, die die Verwundbarkeit abdeckt. Das
Sicherheitsproblem wurde vielleicht als <url
id="http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security"
name="Sicherheitsfehler"> gemeldet, aber eine Ausbesserung wurde noch nicht
getestet und hochgeladen.

<item>Eine Anweisung wurde veröffentlicht, bevor eine CVE-Bezeichnung einer
bestimmten Verwundbarkeit zugewiesen wurde (sehen Sie auf der Webseite nach
einer Aktualisierung).

</list>
</sect1>

</sect>


<sect>Die Infrastruktur der Sicherheit bei der Paketerstellung in Debian
<!-- SB (20050426): auf englisch "Debian Security Build Infrastructure" -->

<p>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.

<p>Während früher die Sicherheitsaktualisierungen von Hand erstellt wurden, so
gilt das heute nicht mehr, wie Anthony Towns in <url
id="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00002.html"
name="einer Mail"> beschreibt, die am 8. Juni 2002 an die Mailingliste
debian-devel-announce geschickt wurde.

<p>Pakete, die vom Sicherheitsteam mit einem passenden Patch (auf <url
id="ftp://security-master.debian.org:/org/security.debian.org/queue/unchecked"> oder <url
id="ftp://security-master.debian.org/pub/SecurityUploadQueue">) hochgeladen werden,
werden innerhalb von 15 Minuten nach dem Hochladen auf Signaturen
überprüft. Danach werden sie zu der Liste der Autobuilder hinzugefügt (diese
führen nicht mehr einen tägliche Durchgang durch das Archiv durch). Dadurch
können die Pakete automatisch für <em>alle</em> Architekturen 30 Minuten oder
eine Stunde oder so nach dem Hochladen erstellt werden. 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 Anweisung 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.

<p>Folglich arbeitet das Archiv der Sicherheitsuploads nach dem folgenden
Ablauf (dieser wird <em>"Accepted-Autobuilding"</em> genannt):

<list>

<item>Jemand findet ein Sicherheitsproblem.

<item>Jemand löst das Problem und lädt die Lösung in den Eingang von
security-master.debian.org hoch (dieser <em>jemand</em> 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
<em>testing-security</em> oder <em>stable-security</em> als Zieldistribution.

<item>Die hochgeladenen Dateien werden von einem Debian-System überprüft,
verarbeitet und in die Warteschleife der angenommenen Dateien
<!-- SB (20050426): "and moved into queue/accepted" -->
weitergeleitet. Danach werden die Buildds benachrichtigt. Auf die Dateien in
der Warteschleife kann das Sicherheitsteam und (auf indirektem Wege) die
Buildds zugreifen.

<item>Buildds, die Sicherheit unterstützen, holen sich das Quellpaket (mit
einer höheren Priorität als normale Paketerstellungen), erstellen Pakete und
schicken die Logs ans Sicherheitsteam.

<item>Das Sicherheitsteam antwortet auf die Logs 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.

<item>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ühren sie ein Skript aus, das

<list>
<item>das Paket im Sicherheitsarchiv installiert,

<item>die <file>Paket</file>-, <file>Quell</file>- und <file>Veröffentlichungsdateien</file> von security.debian.org
auf dem gewöhnlichen Weg aktualisiert (<prgn>dpkg-scanpackages</prgn>,
<prgn>dpkg-scansources</prgn>, ...),

<item>eine Vorlage einer Anweisung erstellt, die das Sicherheitsteam fertig
stellen kann und

<item>(wahlweise) die Pakete zu den vorgeschlagenen Aktualisierungen
weiterleitet, so dass sie sobald wie möglich in die echten Archive eingefügt
werden können.

</list>

</list>

<p>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.


<sect1>Leitfaden über Sicherheitsaktualisierungen für Entwickler

<p>Diese Mail wurde von Wichert Akkerman an die <url
id="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00004.html"
name="Mailingliste debian-devel-announce"> geschickt, um zu beschreiben, wie
Entwickler von Debian Sicherheitsprobleme in ihren Paketen handhaben. Sie wird
hier veröffentlicht, sowohl um Entwicklern zu helfen als auch um Nutzern zu
verdeutlichen, wie mit Sicherheit in Debian umgegangen wird.

<p>FIXME: Beachten Sie, dass die aktuelle Referenz für diese Informationen die <url
id="http://www.debian.org/doc/manuals/developers-reference/ch-pkgs#bug-security"
name="Debian-Entwicklerreferenz"> ist und dieser Abschnitt demnächst entfernt
wird.
<!-- SB (20050426): Dies steht hier schon seit dem 11.08.2001. Außerdem gibt es
für die Entwicklerreferenz keine deutsche Übersetzung. -->


<sect2>Zusammenarbeit mit dem Sicherheitsteam

<p>Wenn ein Entwickler von einem Sicherheitsproblem erfährt, egal ob in seinem
Paket oder in einem anderen, sollte er das immer dem Sicherheitsteam melden
(unter team@security.debian.org). Sie gehen ungelösten Sicherheitsproblemen
nach, können Paketbetreuern mit Sicherheitsproblemen helfen oder sie selber
lösen, sind für den Versand von Sicherheitsankündigungen verantwortlich und
betreuen security.debian.org.

<p>Beachten Sie bitte, dass Sicherheitsankündigungen nur für veröffentlichte
Distributionen erteilt werden, nicht für Testing, Unstable
und ältere Distributionen.


<sect2>Erkennen von Sicherheitsproblemen

<p>Es gibt einige Möglichkeiten, wie ein Entwickler von Sicherheitsproblemen
erfahren kann:

<list>

<item>Er bemerkt sie in einem öffentlichem Forum (Mailingliste, Webseite,
etc.).

<item>Jemand reicht einen Fehlerbericht ein. Es sollte dann das
<em>Security</em>-Tag verwendet oder vom Entwickler hinzugefügt werden.

<item>Jemand informiert ihn in einer privaten E-Mail.

</list>

<p>In den ersten beiden Fällen ist die Information öffentlich verfügbar und es
ist daher wichtig, dass eine Ausbesserung so schnell wie möglich vorhanden
ist. Im letzten Fall könnte keine öffentliche Information vorliegen. In diesem
Fall gibt es ein paar Möglichkeiten, wie mit dem Problem umzugehen ist:

<list>

<item>Wenn es ein triviales Problem ist (wie unsichere temporäre Dateien),
gibt es keine Notwendigkeit, das Problem geheim zu halten, und eine
Ausbesserung sollte erstellt und veröffentlicht werden.

<item>Wenn es sich um ein ernst zunehmendes Problem handelt (aus der Ferne
ausnutzbar, Möglichkeit, Root-Rechte zu bekommen), ist es vorzugwürdig, die
Information mit anderen Linux-Anbietern zu teilen und eine Veröffentlichung zu
koordinieren. Das Sicherheitsteam hat Kontakte zu verschiedenen
Organisationen und Individuen und kann das erledigen.

</list>

<p>Wenn die Person, die das Problem gemeldet hat, darum bittet, die
Informationen nicht bekanntzugeben, sollte das respektiert werden, mit der
offensichtlichen Ausnahme der Mitteilung an das Sicherheitsteam (der Entwickler
sollte sichergehen, dass er dem Sicherheitsteam mitteilt, dass die
Informationen nicht bekanntgegeben werden sollen).

<p>Beachten Sie, dass in Fällen der Geheimhaltung der Entwickler auch keine
Ausbesserung nach Unstable (oder sonst irgendwo hin) hochladen darf, da die
Änderungsübersicht für Unstable öffentlich zugänglich ist.

<p>Es gibt zwei Gründe, um Informationen zu veröffentlichen, selbst wenn um
Geheimhalten gebeten wurde oder diese notwendig ist: Das Problem ist schon zu
lange bekannt oder es wurde öffentlich bekannt.


<sect2>Erstellen eines Pakets

<p>Wenn ein neues Paket erstellt wird, das ein Sicherheitsproblem löst, ist die
wichtigste Richtlinie, so wenige Änderungen wie möglich vorzunehmen. Menschen
hängen von demselben Verhalten einer Veröffentlichung ab. Jede Veränderung
könnte also das System von jemanden unbenutzbar machen. Dies gilt besonders für
Bibliotheken: Der Entwickler muss sichergehen, dass er niemals die API oder ABI
verändert, egal wie klein die Änderungen sind.

<p>Das bedeutet, dass das Verwenden einer neuen Version des Originalprogramms
keine gute Lösung ist. Stattdessen sollten die relevanten Veränderung
zurückportiert werden. Gewöhnlich werden die Programmautoren dabei
gegebenenfalls behilflich sein, wenn Debians Sicherheitsteam nicht helfen kann.

<p>In einigen Fällen ist es nicht möglich, Sicherheitsverbesserungen
zurückzuportieren, z.B. wenn große Mengen des Quellcodes verändert oder neu
geschrieben werden müssten. Wenn das eintritt, kann es notwendig werden, eine
neue Version des Originalprogramms zu verwenden. Das sollte aber immer im
Voraus mit dem Sicherheitsteam abgestimmt werden.

<p>Damit hängt ein anderer wichtiger Punkt zusammen: Entwickler müssen immer
ihre Änderungen testen. Wenn es einen Exploit gibt, sollte der Entwickler
versuchen, ob er tatsächlich mit dem ungepatchten Paket gelingt und im
ausgebesserten Paket scheitert. Der Entwickler sollte auch den gewöhnlichen
Gebrauch ausprobieren, da manchmal eine Sicherheitsausbesserung fast
unmerklich den normalen Gebrauch beeinträchtigt.

<p>Zu guter Letzt ein paar technische Dinge, die Entwickler bedenken sollten:

<list>

<item>Stellen Sie sicher, dass Sie sich in Ihrer Debian-Änderungsübersicht auf
die richtige Distribution beziehen. Für Stable ist das stable-security und für
Testing testing-security. Beziehen Sie sich nicht auf
&lt;codename&gt;-proposed-updates.

<item>Stellen Sie sicher, dass die Versionsnummer korrekt ist. Sie muss größer
als die des aktuellen Pakets sein, aber niedriger als die Paketversionen in
späteren Distributionen. Für Testing bedeutet das, dass es eine höhere Version
als in Unstable sein muss. Falls es dort keine gibt (Testing und Unstable
haben z.B. die gleichen Versionen), laden Sie zuerst die neue Version nach
Unstable hoch.

<item>Laden Sie nicht nur die Quellen hoch (source-only upload), wenn Ihr Paket
nur binäre Pakete enthält (binary-all). Die Buildd-Infrastruktur wird diese
nicht erstellen.

<item>Wenn Sie ein Paket kompilieren, stellen Sie sicher, dass Sie es auf einem
reinen System kompilieren, auf dem nur Pakete aus der Distribution installiert
sind, für die Sie das Paket erstellen. Wenn Sie selbst ein solches System nicht
haben, können Sie es mit einer Maschine von debian.org versuchen (siehe
http://db.debian.org/machines.cgi) oder setzen Sie chroot ein (die Pakete
<package>pbuilder</package> und <package>debootstrap</package> können dafür
hilfreich sein).

</list>


<sect2>Hochladen von Sicherheitsausbesserungen

<p>Nachdem der Entwickler ein neues Paket erstellt und getestet hat, muss es
hochgeladen werden, damit es in den Archiven installiert werden
kann. Sicherheitsrelevante Dateien werden nach
ftp://security-master.debian.org/pub/SecurityUploadQueue/ hochgeladen.

<p>Wenn eine in die Sicherheitswarteschleife hochgeladene Datei akzeptiert
wurde, wird das Paket automatisch für alle Architekturen neu erstellt und zur
Überprüfung durch das Sicherheitsteam abgelegt.

<p>Nur das Sicherheitsteam kann auf hochgeladene Dateien, die auf Annahme oder
Überprüfung warten, zugreifen. Das ist notwendig, da es Ausbesserungen für
Sicherheitsprobleme geben könnte, die noch nicht offengelegt werden dürfen.

<p>Wenn ein Mitglied des Sicherheitsteams ein Paket akzeptiert, wird es auf
security.debian.org und als passendes &lt;codename&gt;-proposed-updates auf
ftp-master oder im Non-US-Archiv installiert.


<sect2>Die Sicherheitsankündigung

<p>Sicherheitsankündigungen werden vom Sicherheitsteam geschrieben und
veröffentlicht. Allerdings macht es ihnen gewiss nichts aus, wenn ein
Paketbetreuer den Text (teilweise) für sie erstellt. Informationen, die in
einer Anweisung enthalten seien sollten, werden in <ref id="dsa"> beschrieben.


<sect id="deb-pack-sign">Paketsignierung in Debian

<p>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.<footnote>
Einige Betriebssystem wurden schon von Problemen mit automatischen
Aktualisierungen heimgesucht, wie z.B. die <url
id="http://www.cunap.com/~hardingr/projects/osx/exploit.html" name="Mac OS X
Software-Update-Verwundbarkeit">.
<p>FIXME: probably the Internet Explorer vulnerability handling
certificate chains has an impact on security updates on Microsoft Windows.
</footnote>

<p>Debian stellt keine signierten Pakete zur Verfügung. Es gibt aber
seit Debian 4.0 (Codename <em>Etch</em>) eine Verfahrensweise, mit der
die Integrität von heruntergeladenen Paketen überprüft werden
kann.<footnote>Ältere Veröffentlichungen wie Debian 3.1
(<em>Sarge</em>) können mit zurückportierten Versionen des
Paketmanagers auf diese Methode zugreifen.</footnote> Weiterführende
Hinweise können Sie unter <ref id="apt-0.6"> finden.

<p>Dieses Problem wird besser im <url
id="http://www.cryptnet.net/fdp/crypto/strong_distro.html"
name="Strong-Distribution-Howto"> von V. Alex Brennen beschrieben.


<sect1>Die aktuelle Methode zur Prüfung von Paketsignaturen

<p>Die aktuelle Methode zur Prüfung von Paketsignaturen mit <prgn>apt</prgn>
ist:

<list>

<item>Die <file>Release</file>-Datei enthält die MD5-Summe von <file>Packages.gz</file> (die
die MD5-Summen der Pakete enthält) und wird signiert. Die Signatur
stammt aus einer vertrauenswürdigen Quelle.

<item>Diese signierte <file>Release</file>-Datei wird beim »apt-get update« herunter
geladen und zusammen mit <file>Packages.gz</file> gespeichert.

<item>Wenn ein Paket installiert werden soll, wird es zuerst herunter
geladen, und dann wird die MD5-Summe erstellt.

<item>Die signierte <file>Release</file>-Datei wird überprüft (ob die
Signatur in Ordnung ist) und die MD5-Summe der <file>Packages.gz</file>-Datei extrahiert.
Die MD5-Summe der <file>Packages.gz</file>-Datei wird erstellt und geprüft, und -
wenn sie übereinstimmt &ndash; wird die MD5-Summe des heruntergeladenen
Paketes aus ihr extrahiert.

<item>Wenn die MD5-Summe des heruntergeladenen Paketes die gleiche ist
wie in der <file>Packages.gz</file>-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 <file>Packages.gz</file> 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.
</list>

<p>Durch diese Kette von MD5-Summen ist <prgn>apt</prgn> 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.

<p>Diese Vorgehensweise ist seit der Veröffentlichung von Debian 4.0
verfügbar und vollständig in apt 0.6 <url
id="http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg01986.html"
name="enthalten">; weitere
Informationen finden Sie unter <ref
id="apt-0.6">. 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
<prgn>aptitude</prgn>, das <url
id="http://lists.debian.org/debian-devel/2005/03/msg02641.html"
name="verändert"> wurde, um zu dieser Vorgehensweise zu passen. Frontends, die
bekanntermaßen zurzeit mit dieser Fähigkeit umgehen können, sind
<prgn>aptitude</prgn> und <prgn>synaptic</prgn>.

<p>Die Signierung von Paketen wurde innerhalb des Debian-Projekts
ausführlich diskutiert. Mehr Informationen hierzu finden Sie unter 
<url id="http://www.debian.org/News/weekly/2001/8/"> und
<url id="http://www.debian.org/News/weekly/2000/11/">.


<sect1 id="apt-0.6">Secure Apt

<p>Die Veröffentlichung von apt 0.6, das seit Debian 4.0 (<em>Etch</em>) verfügbar ist,
enthält <em>apt-secure</em> (auch als <em>Secure Apt</em> 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 <prgn>apt-key</prgn>, um neue
Schlüssel zum Schlüsselbund von apt hinzuzufügen, welcher standardmäßig nur den
aktuellen Signierungsschlüssel des Debian-Archivs enthält.

<p>Diese Veränderungen basieren auf dem Patch für <prgn>apt</prgn> (verfügbar
in <url id="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203741"
name="Fehler #203741">), der diese Erweiterung zur Verfügung stellt.

<p>Secure Apt überprüft die Distribution mit der <file>Release</file>-Datei. Dies wurde
schon unter <ref id="check-releases"> dargestellt. Typischerweise erfordert
dieser Vorgang kein Mitwirken des Administrators. Aber jedes Jahr müssen Sie
eingreifen<footnote>Bis ein automatischer Mechanismus entwickelt
wurde.</footnote>, um den neuen Schlüssel des Archivs hinzuzufügen, wenn dieser
ausgewechselt wurde. Weitere Informationen zu den dazu notwendigen Schritten
finden Sie unter <ref id="secure-apt-add-key">.

<p>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 <package>apt</package>.

<p>Weiterführende Informationen finden Sie im <url
id="http://wiki.debian.org/SecureApt" name="Debian-Wiki"> und in der
offiziellen Dokumentation unter <url
id="http://www.enyo.de/fw/software/apt-secure/" name="Migration to APT 0.6">
und <url id="http://www.syntaxpolice.org/apt-secure/" name="APT Signature
Checking">.


<sect1 id="check-releases">Überprüfung der Distribution mit der <file>Release</file>-Datei
<!-- SB (20060130): Auf Englisch "Per distribution release check" -->

<p>Dieser Abschnitt beschreibt, wie die Überprüfung der Distribution mit Hilfe
der <file>Release</file>-Datei funktioniert. Dies wurde von Joey Hess geschrieben und ist
auch im <url id="http://wiki.debian.org/SecureApt" name="Debian-Wiki">
abrufbar.

<sect2>Grundlegende Konzepte

<p>Es gibt ein paar grundlegende Konzepte, die Sie brauchen, um den Rest dieses
Abschnitts verstehen zu können.

<p>Eine Prüfsumme ist eine Methode, bei der eine Datei auf eine relativ kurze
Zahl heruntergekocht wird, mit der der Inhalt der Datei eindeutig identifiziert
werden kann. Dies ist wesentlich schwieriger, als es zunächst erscheinen
mag. Der am weitesten verbreitetste Typ von Prüfsummen, MD5, ist gerade
dabei, unbrauchbar zu werden.

<p>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 ein Geheimnis
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 deneben 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.

<p>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.

<p>Secure Apt verwendet <prgn>gpg</prgn>, um Dateien zu unterschreiben und ihre
Unterschriften zu überprüfen.

<p>Mit dem Programm <prgn>apt-key</prgn> wird der Schlüsselbund von GPG für
Secure Apt verwaltet. Der Schlüsselbund befindet sich in der Datei
<file>/etc/apt/trusted.gpg</file> (nicht zu verwechseln mit der verwandten,
aber nicht sehr interessanten Datei
<file>/etc/apt/trustdb.gpg</file>). <prgn>apt-key</prgn> kann dazu verwendet
werden, die Schlüssel im Schlüsselbund anzuzeigen oder um Schlüssel hinzuzufügen
oder zu entfernen.

<sect2>Prüfsummen der <file>Release</file>-Datei

<p>Jedes Archiv von Debian enthält eine <file>Release</file>-Datei, die
jedesmal aktualisiert wird, wenn ein Paket im Archiv geändert wird. Unter
anderem enthält die <file>Release</file>-Datei MD5-Summen von anderen Dateien, die sich im
Archiv befinden. Ein Auszug einer <file>Release</file>-Datei:

<example>
MD5Sum:
 6b05b392f792ba5a436d590c129de21f            3453 Packages
 1356479a23edda7a69f24eb8d6f4a14b            1131 Packages.gz
 2a5167881adc9ad1a8864f281b1eb959            1715 Sources
 88de3533bf6e054d1799f8e49b6aed8b             658 Sources.gz
</example>

<p>Die <file>Release</file>-Datei enthält auch SHA1-Prüfsummen, was nützlich ist, wenn
MD5-Summen vollständig unbrauchbar sind. Allerdings unterstützt apt SHA1 noch
nicht.

<p>Werfen wir einen Blick in eine <file>Paket</file>datei: wir sehen weitere MD5-Summen,
eine für jedes darin aufgeführte Paket. Beispiel:

<example>
    Package: uqm
    Priority: optional
    ...
    Filename: unstable/uqm_0.4.0-1_i386.deb
    Size: 580558
    MD5sum: 864ec6157c1eea88acfef44d0f34d219
</example>

<p>Mit diesen beiden Prüfsummen kann überprüft werden, ob Sie eine getreue
Kopie der <file>Paket</file>datei, also mit einer MD5-Summe, die mit der in der
<file>Release</file>-Datei übereinstimmt, heruntergeladen haben. Und wenn ein einzelnes
Paket heruntergeladen wird, kann auch die MD5-Summe mit dem Inhalt der
<file>Paket</file>datei verglichen werden. Wenn bei einem dieser Schritte ein Fehler
auftauchen sollte, bricht Apt den Vorgang ab.

<p>Nichts davon ist neu in Secure Apt, aber es bietet die Grundlage
dafür. Beachten Sie, dass es bis jetzt eine Datei gibt, die Apt nicht
überprüfen kann: die <file>Release</file>-Datei. Bei Secure Apt dreht sich alles darum, dass
Apt die <file>Release</file>-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.


<sect2>Überprüfung der <file>Release</file>-Datei

<p>Damit die <file>Release</file>-Datei überprüft werden kann, wird sie mit GPG
signiert. Diese Unterschrift kommt in die Datei <file>Release.gpg</file>, die
mit der <file>Release</file>-Datei abgerufen werden kann. Sie sieht in etwa
so<footnote>Genau genommen handelt es sich um eine ASCII-armored abgetrennte
GPG-Signatur.</footnote>
aus, obwohl sich für gewöhnlich nur GPG ihren Inhalt ansieht:

<example>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCqKO1nukh8wJbxY8RAsfHAJ9hu8oGNRAl2MSmP5+z2RZb6FJ8kACfWvEx
UBGPVc7jbHHsg78EhMBlV/U=
=x6og
-----END PGP SIGNATURE-----
</example>


<sect2><file>Release.gpg</file> mit <prgn>Apt</prgn> überprüfen

<p>Wenn Secure Apt eine <file>Release</file>-Datei herunterlädt, lädt es auch immer die
<file>Release.gpg</file>-Datei herunter. Falls dies misslingen sollte oder die
Signatur nicht stimmt, wird es eine Rückmeldung machen und hinweisen, dass die
Paketdateien, auf die die <file>Release</file>-Datei verweist, und alle darin enthaltenen
Pakete von einer nicht vertrauenswürdigen Quelle stammen. So würde dies während
<prgn>apt-get update</prgn> aussehen:

<example>
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
</example>

<p>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.

<p>Falls Sie diese Warnung ignorieren und später versuchen, ein Paket zu
installieren, wird Sie Apt nochmals warnen:

<example>
WARNUNG: Die folgenden Pakete können nicht authentifiziert werden!
  libglib-perl libgtk2-perl
Diese Pakete ohne Überprüfung installieren [j/N]?  
</example>

<p>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<footnote>
Oder Ihren DNS vergiftet hat oder den Server spooft oder die Datei auf einem
Spiegel platziert hat, den Sie verwenden, oder ...
</footnote>
mit einer gemeinen Überraschung, unterschieben will.

<p>Sie können diese Abfragen abschalten, indem Sie <prgn>apt</prgn> mit
<tt>--allow-unauthenticated</tt> laufen lassen.

<p>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 <file>Release</file>-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 <file>Release</file>-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.


<sect2>Wie man Apt sagt, wem es vertrauen soll

<p>Die ganze Sicherheit des Verfahrens beruht also darauf, dass es eine
<file>Release.gpg</file>-Datei gibt, die eine <file>Release</file>-Datei
signiert, und dass diese Signatur von <prgn>apt</prgn> mit Hilfe von GPG
überprüft wird. Dazu muss es den öffentlichen Schlüssel der Person kennen, die
die Datei unterschrieben hat. Diese Schlüssel werden in Apts eigenem
Schlüsselbund (<file>/etc/apt/trusted.gpg</file>) gespeichert. Bei der
Verwaltung dieser Schlüssel kommt Secure Apt ins Spiel.

<p>Standardmäßig befindet sich bei Debian-Systemen der Schlüssel des
Debian-Archivs im Schlüsselbund.

<example>
# apt-key list
/etc/apt/trusted.gpg
--------------------
pub   1024D/4F368D5D 2005-01-31 [expires: 2006-01-31]
uid                  Debian Archive Automatic Signing Key (2005) &lt;ftpmaster@debian.org&gt;
</example>

<p>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.

<p>Mit dem Schlüssel des Archivs wird <prgn>apt</prgn> dem offiziellen Archiv von Debian
vertrauen. Wenn Sie aber weitere Paketdepots zu
<file>/etc/apt/sources.list</file> 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 <prgn>apt-key add
<var>Datei</var></prgn> laufen lassen, um den Schlüssel hinzuzufügen. Der schwierigste Teil
dabei ist, den Schlüssel zu bekommen und ihn zu überprüfen.


<sect2>Den Schlüssel für Paketdepots finden

<p>Mit dem Paket <package>debian-archive-keyring</package> werden Schlüssel für
<prgn>apt</prgn> bereitgestellt. Aktualisierungen dieses Pakets führen dazu,
dass GPG-Schlüssel für das von Debian-Hauptarchiv hinzugefügt (oder gelöscht)
werden.

<p>Für die übrigen 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.

<p>Der Schlüssel des Debian-Archivs ist unter <url
id="http://ftp-master.debian.org/ziyi_key_2006.asc"> (ersetzen Sie 2006 mit dem
aktuellen Jahr) erhältlich.<footnote>"Ziyi" ist der Name des Werkzeugs, mit dem
die Debian-Server signiert werden, und beruht auf dem Namen einer <url
id="http://de.wikipedia.org/wiki/Ziyi_Zhang" name="chinesischen
Schauspielerin">.</footnote>

<p><prgn>gpg</prgn> 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:

<example>
$ 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) &lt;ftpm
aster@debian.org&gt;" imported
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                              importiert: 1
</example>

<p>Sie können dann den Schlüssel aus Ihrem Schlüsselbund exportieren und ihn an
<prgn>apt-key</prgn> weiterreichen:

<example>
$ gpg -a --export 2D230C5F | sudo apt-key add -
gpg: kein uneingeschränkt vertrauenswürdiger Schlüssel 080F67F4 gefunden
OK
</example>

<p>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.


<sect2 id="secure-apt-add-key">Auf sichere Weise einen Schlüssel hinzufügen

<p>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 <file>Release</file>-Datei korrekt
ist, müssen Sie überprüfen, ob Sie tatsächlich den richtigen Schlüssel
haben. Ist die Datei <url id="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)?

<p>Es ist gut, in Sicherheitsfragen Vorsicht walten zu lassen. Aber ab hier
wird es schwieriger, Dinge zu überprüfen. <prgn>gpg</prgn> 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<footnote>
Nicht alle Schlüssel der Apt-Depots sind überhaupt mit einem anderen Schlüssel
unterschrieben. Vielleicht hat derjenige, der das Depot einrichtet, keinen
anderen Schlüssel zur Verfügung, oder vielleicht ist es ihm unangenehm, einen
Schlüssel mit einer derartig wichtigen Funktion mit seinem Hauptschlüssel zu
unterschreiben. Hinweise, wie man einen Schlüssel für ein Depot einrichtet,
finden Sie unter <ref id="check-non-debian-releases">.
</footnote>.

<p>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.


<sect2>Die Integrität eines Schlüssels überprüfen

<p>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 <url
id="http://debiansystem.info/readers/changes/547-ziyi-key-2006" name="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:
<example>
$ GET http://ftp-master.debian.org/ziyi_key_2006.asc | gpg --import
gpg: key 2D230C5F: public key "Debian Archive Automatic Signing Key (2006)
  &lt;ftpmaster&amp;debian.org&gt;" imported
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                             unverändert: 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) &lt;ftpmaster@debian.org&gt;
sig!3        2D230C5F 2006-01-03  Debian Archive Automatic Signing Key
                                  (2006) &lt;ftpmaster@debian.org&gt;
sig!         2A4E3EAA 2006-01-03  Anthony Towns &lt;aj@azure.humbug.org.au&gt;
sig!         4F368D5D 2006-01-03  Debian Archive Automatic Signing Key
                                  (2005) &lt;ftpmaster@debian.org&gt;
sig!         29982E5A 2006-01-04  Steve Langasek &lt;vorlon@dodds.net&gt;
sig!         FD6645AB 2006-01-04  Ryan Murray &lt;rmurray@cyberhqz.com&gt;
sig!         AB2A91F5 2006-01-04  James Troup &lt;james@nocrew.org&gt;
</example>
<p>und dann von Ihrem Schlüssel (oder einem Schlüssel, dem Sie vertrauen) den
<url
id="http://www.de.debian.org/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign"
name="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:

<example>
$ gpg --export -a 2D230C5F | sudo apt-key add -
Ok
</example>

<p>Der aktuelle Schlüssel ist mit dem vorhergehenden Archivschlüssel
unterschrieben, so dass Sie theoretisch auf Ihrem alten Vertrauen aufbauen
können.


<sect2>Der jährliche Austausch des Archivschlüssels von Debian

<p>Wie schon oben 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.

<!-- SB: English version ambiguous. Check paragraphs from here ...-->
<p>Im Januar 2006 wurde ein neuer Schlüssel für 2006 erstellt und die
<file>Release</file>-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 <file>Release</file>-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.

<!-- SB: ... until here! (German version based on 1.26) -->

<!-- This is too vague to include here:
<p>Es wird erwartet, dass die Dinge 2007 wie folgt ablaufen:

<list>
<item>Anfang Januar wird ein neuer Schlüssel für 2007 erstellt. Vielleicht gibt
es dieses Mal auch eine Ankündigung und eine gute Kette des Vertrauens.

<item>Die <file>Release</file>-Datei wird mit diesem Schlüssel unterschrieben
werden, während sie auch mit dem Schlüssel von 2006 unterschrieben ist. Apt
und andere Werkzeuge werden beide Unterschriften akzeptieren.

<item>Zuvor wird ein neues Paket, <package>debian-archive-keyring</package>, auf
jedem System installiert werden. Es wird aktualisiert, damit es den Schlüssel
von 2007 enthält. Wenn Benutzer zur neuen Version wechseln, wird mit
<prgn>apt-key</prgn> ihr Schlüsselbund aktualisiert werden. Der Schlüssel von
2006 wird entfernt und der von 2007 hinzugefügt.

<item>Der Schlüssel von 2006 verliert am 31. Januar 2007 seine Gültigkeit.

</list>

<p>Noch nicht ganz sicher ist, was mit denen passiert, die im Januar gar keine
Aktualisierung durchführen, und wie diese Aktualisierung für Personen abläuft,
die Stable laufen lassen, wenn Secure Apt auch dort verfügbar ist.

-->


<sect2>Bekannte Probleme bei der Prüfung
<!-- SB (20060206): Known release checking problems -->

<p>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:

<example>
W: GPG error: http://archive.progeny.com sid Release: Unknown error executing gpg
</example>

<p>Dagegen macht <prgn>apt-key</prgn> das Problem deutlich:

<example>
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) &lt;ftpmaster@debian.org&gt;
</example>

<p>Falls die Uhr nicht zu weit vorgeht, behandelt Apt die Schlüssel als
abgelaufen.

<p>Wenn Sie Testing oder Unstable verwenden, gibt es ein Problem, wenn Sie in
letzter Zeit nicht <prgn>apt-get update</prgn> ausgeführt haben und mit <prgn>apt-get</prgn> ein Paket
installieren möchten. Apt könnte sich darüber beschweren, dass es nicht
authentifiziert werden konnte (Warum passiert das bloß?). <prgn>apt-get update</prgn> löst
das Problem.


<sect2 id="manual-check-releases">Prüfung von Hand

<p>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<footnote>
Entweder weil Sie Stable (<em>Sarge</em>) oder eine ältere Veröffentlichung
verwenden, oder weil Sie nicht die neuste Version von Apt einsetzen wollen,
obwohl wir das Testen wirklich schätzen würden.
</footnote>, können Sie das folgende Skript von
Anthony Towns benutzen. Dieses Skript führt automatisch neue
Sicherheitsüberprüfungen durch, damit ein Nutzer 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.

<p>Dieser Beispielscode, umbenannt nach <prgn>apt-check sigs</prgn>,
sollte auf die folgende Art benutzt werden:
<example>
# apt-get update
# apt-check-sigs
(... Ergebnisse ...)
# apt-get dist-upgrade
</example>

<p>Zuerst müssen Sie jedoch Folgendes tun:

<list>

<item>Holen Sie sich den Schlüssel, den die Archiv-Software
verwendet, um <file>Release</file>-Dateien zu signieren, <url
id="http://ftp-master.debian.org/ziyi_key_2006.asc">
und fügen Sie ihn <file>~/.gnupg/trustedkeys.gpg</file> hinzu (was
standardmäßig von <prgn>gpgv</prgn> benutzt wird).
<example>
  gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2006.asc
</example>

<item>Entfernen Sie alle Zeilen aus <file>/etc/apt/sources.list</file>,
die nicht die normale "dists"-Struktur benutzen, oder ändern Sie das Skript,
so dass es auch mit denen funktioniert.

<item>Ignorieren Sie die Tatsache, dass Sicherheitsaktualisierungen von Debian
keine signierten <file>Release</file>-Dateien haben, und das <file>Quell</file>dateien (noch)
keine richtigen Prüfsummen in der <file>Release</file>-Datei haben.

<item>Bereiten Sie sich darauf vor, zu prüfen, dass die richtigen
Quellen durch den richtigen Schlüssel signiert wurden.

</list>

<p>Dies ist der Beispielscode für <prgn>apt-check-sigs</prgn>. Die neuste
Fassung ist unter <url id="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 <url
id="http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg00421.html">
lesen.

<example>
#!/bin/bash

# Copyright (c) 2001 Anthony Towns &lt;ajt@debian.org&gt;
#
# 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
</example>

<p>Sie müssen vielleicht bei <em>Sid</em> diesen Patch verwenden, da
<prgn>md5sum</prgn> ein '-' an die Summe anfügt, wenn die Ausgabe auf stdin
erfolgt:

<example>
@@ -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"
</example>


<sect1 id="check-non-debian-releases">Prüfung von Debian-fremden Quellen
<!-- SB (20060206): "Release check of non Debian sources" -->

<p>Beachten Sie, dass, wenn Sie die neuste Version von Apt (mit <em>Secure
Apt</em>) einsetzen, kein zusätzlicher Aufwand auf Ihrer Seite notwendig sein
sollte, wenn Sie keine Debian-fremden Quellen verwenden. In diesen Fällen
erfordert <prgn>apt-get</prgn> eine zusätzliche Bestätigung. Dies wird verhindert, wenn
<file>Release</file>- und <file>Release.gpg</file>-Dateien in den Debian-fremden Quellen zur Verfügung
stehen. Die <file>Release</file>-Datei kann mit <prgn>apt-ftparchive</prgn> (ist in
<package>apt-utils</package> 0.5.0 und später enthalten) erstellt werden, die <file>Release.gpg</file> ist nur
die abgetrennte Signatur. Beide können mit folgender einfacher Prozedur
erstellt werden:

<example>
$ rm -f dists/unstable/Release
$ apt-ftparchive release dists/unstable > dists/unstable/Release
$ gpg --sign -ba -o dists/unstable/Release.gpg dists/unstable/Release
</example>


<sect1 id="check-pkg-sign">Alternativer Entwurf zur Einzelsignierung von
Paketen

<p>Dieser zusätzliche Entwurf, jedes Paket einzeln zu signieren, erlaubt es,
Pakete zu prüfen, selbst wenn sie nicht mehr in irgendeiner <file>Packages</file>-Datei
erwähnt werden. Und so können auch Pakete von Dritten, für die es nie eine
<file>Packages</file>-Datei gab, unter Debian installiert werden. Dies wird aber kein
Standard werden.

<p>Dieser Entwurf zur Paketsignierung kann mit <package>debsig-verify</package>
und <package>debsigs</package> 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.

<p>Die aktuellen Versionen von <prgn>dpkg</prgn> (seit 1.9.21) beinhalten einen <url
id="http://lists.debian.org/debian-dpkg/2001/debian-dpkg-200103/msg00024.html"
name="Patch">, der diese Funktionen zur Verfügung stellt, sobald
<package>debsig-verify</package> installiert ist.

<p>HINWEIS: Derzeit wird <file>/etc/dpkg/dpkg.cfg</file> standardmäßig mit der
Option "no-debsig" ausgeliefert.

<p>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 <file>Release</file>-Datei ist, wie es oben beschrieben wurde.

