[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ weiter ]
Debian hat ein Sicherheitsteam, das aus fünf Mitgliedern und zwei Sekretären besteht. Es ist für die Sicherheit in der Stable-Veröffentlichung verantwortlich. Das bedeutet, dass es Sicherheitslücken nachgeht, die in Software auftauchen (indem es Foren wie bugtraq oder vuln-dev beobachtet), und ermittelt, ob davon die Stable-Veröffentlichung betroffen ist.
Das Sicherheitsteam von Debian ist auch der Ansprechpartner für Probleme, die
von den Programmautoren oder Organisationen wie CERT
behandelt werden und die mehrere
Linux-Anbieter betreffen können. Das gilt für alle Probleme, die nicht
debianspezifisch sind. Es gibt zwei Möglichkeiten, um mit dem Sicherheitsteam
in Verbindung zu treten:
team@security.debian.org
, die
nur die Mitglieder des Sicherheitsteams lesen.
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).
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.
Wenn das Sicherheitsteam ein mögliches Problem erhält, wird es untersuchen, ob
die Stable-Veröffentlichung davon betroffen ist. Wenn dies der Fall
ist, wird eine Ausbesserungen des Quellcodes vorgenommen. Diese Ausbesserung
schließt manchmal ein, dass Patches der Programmautoren zurückportiert werden
(da das Originalprogramm gewöhnlich eine Versionen weiter ist als das in
Debian). Nachdem die Ausbesserung getestet wurde, werden neue Pakete
vorbereitet und auf der Seite security.debian.org
veröffentlicht, damit
sie mit apt
abgerufen werden können (siehe Ausführen von Sicherheitsupdates,
Abschnitt 4.2). Zur gleichen Zeit wird eine
Debian-Sicherheitsanweisung (DSA) auf der Webseite veröffentlicht und
an öffentliche Mailinglisten einschließlich debian-security-announce
und bugtraq geschickt.
Einige andere häufige Fragen zum Sicherheitsteam von Debian können unter Fragen zum Sicherheitsteam von Debian, Abschnitt 11.3 gefunden werden.
Debian-Sicherheitsanweisungen 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:
Versionsnummer der Ausbesserung.
Art des Problems.
Ob es aus der Ferne oder lokal ausnutzbar ist.
Kurze Beschreibung des Pakets.
Beschreibung des Problems.
Beschreibung des Exploits.
Beschreibung der Ausbesserung.
DSAs werden sowohl auf der Hauptseite
von Debian
als auch auf den Sicherheitsseiten von Debian
veröffentlicht. Das passiert normalerweise nicht bis die Website neu erstellt
wurde (alle vier Stunden). Daher könnten sie nicht sofort vorhanden sein.
Somit ist die vorzugswürdige Informationsquelle die Mailingliste
debian-security-announce.
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 [44] werden nicht an die Sicherheitsmailinglisten geschickt, sondern sind direkt auf der Webseite enthalten.
Debian stellt eine vollständige Tabelle mit
Querverweisen
zur Verfügung, die alle verfügbaren Verweise für die
Anweisungen seit 1998 enthält. Diese Tabelle soll die Verweisübersicht
von CVE
ergänzen.
Sie werden bemerkt haben, dass die Tabelle Verweise auf Sicherheitsdatenbanken
wie Bugtraq
,
CERT/CC Anweisungen
und US-CERT Vulnerability Notes
Database
und auf die CVE-Bezeichnungen (siehe unten) enthält. Diese
Verweise werden zur Nutzerfreundlichkeit angeboten, aber nur der CVE-Verweise
werden regelmäßig überprüft und eingefügt. Dieses Feature wurde im Juni 2002
der Webseite hinzugefügt.
Das Hinzufügen von Querverweisen auf diese Sicherheitsdatenbanken hat folgende Vorteile:
Es erleichtert Nutzern von Debian zu erkennen und nachzuvollziehen, welche allgemeinen (veröffentlichten) Anweisungen schon von Debian abgedeckt wurden.
Systemadministratoren können mehr über die Verwundbarkeit und ihre Auswirkungen lernen, wenn sie den Querverweisen folgen.
Diese Informationen können benutzt werden, um Ausgaben von Verwundbarkeitsscannern, die Verweise auf CVE enthalten, zu überprüfen, um falsche Positivmeldungen auszusortieren (vergleichen Sie Der Scanner X zur Einschätzung der Verwundbarkeit sagt, dass mein Debian-System verwundbar wäre?, Abschnitt 11.2.1).
Debians Sicherheitsanweisungen wurden am 24. Februar 2004 CVE-kompatibel
erklärt
[45].
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 Prozess zur
Verwaltung der Sicherheit auf Grundlage von CVE
zu entwickeln.
Das Projekt Common Vulnerabilities and
Exposures (CVE)
wird von der MITRE Corporation betreut und stellt
eine Liste von standardisierten Bezeichnungen für Verwundbarkeiten und
Sicherheitslücken zur Verfügung.
Debian ist überzeugt, dass es außerordentlich wichtig ist, die 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.
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 Suchmaschine
gesucht werden.
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 CAN-2002-0001
)
oder nach einem Teilbegriff (z.B. alle Kandidaten von 2002, die in Anweisungen
enthalten sind, finden Sie mit der Suche nach CAN-2002
)
durchgeführt werden. Beachten Sie, dass Sie das Wort "advisory"
zusammen mit der CVE-Bezeichnung eingeben müssen, um nur die
Sicherheitsanweisungen zu erhalten.
In einige Fällen finden Sie eine bestimmte CVE-Bezeichnung in veröffentlichten Anweisungen nicht:
Keine Produkte von Debian sind von der Verwundbarkeit betroffen.
Es gibt noch keine Anweisung, die die Verwundbarkeit abdeckt (das
Sicherheitsproblem wurde vielleicht als Sicherheitsfehler
gemeldet, aber eine Ausbesserung wurde noch nicht getestet und hochgeladen).
Eine Anweisung wurde veröffentlicht, bevor eine CVE-Bezeichnung einer bestimmten Verwundbarkeit zugewiesen wurde (sehen Sie auf der Webseite nach einer Aktualisierung).
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.
Während früher die Sicherheitsaktualisierungen von Hand erstellt wurden, so
gilt das heute nicht mehr, wie Anthony Towns in einer
Mail
beschreibt, die am 8. Juni 2002 an die Mailingliste
debian-devel-announce geschickt wurde.
Pakete, die vom Sicherheitsteam mit einem passenden Patch (auf security.debian.org:/org/security.debian.org/queue/unchecked
oder ftp://security.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 alle 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.
Folglich arbeitet das Archiv der Sicherheitsuploads nach dem folgenden Ablauf (dieser wird "Accepted-Autobuilding" genannt):
Jemand findet ein Sicherheitsproblem.
Jemand löst das Problem und lädt die Lösung in den Eingang von security.debian.org hoch (dieser jemand ist normalerweise ein Mitglied des Sicherheitsteams, kann aber auch ein Paketbetreuer mit einer passenden Verbesserung sein, der sich zuvor mit dem Sicherheitsteam in Verbindung gesetzt hat). Die Änderungsübersicht (changelog) beinhaltet ein testing-security oder stable-security als Zieldistribution.
Die hochgeladenen Dateien werden von einem Debian-System überprüft, verarbeitet und in die Warteschleife der angenommenen Dateien weitergeleitet. Danach werden die Buildds benachrichtigt. Auf die Dateien in der Warteschleife kann das Sicherheitsteam und (auf indirektem Wege) die Buildds zugreifen.
Buildds, die Sicherheit unterstützen, holen sich das Quellpaket (mit einer höheren Priorität als normale Paketerstellungen), erstellen Pakete und schicken die Logs ans Sicherheitsteam.
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.
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
das Paket im Sicherheitsarchiv installiert,
die Paket-, Quell- und Veröffentlichungsdateien von security.debian.org auf dem
gewöhnlichen Weg aktualisiert (dpkg-scanpackages
,
dpkg-scansources
, ...),
eine Vorlage einer Anweisung erstellt, die das Sicherheitsteam fertig stellen kann und
(wahlweise) die Pakete zu den vorgeschlagenen Aktualisierungen weiterleitet, so dass sie sobald wie möglich in die echten Archive eingefügt werden können.
Dieser Ablauf, der früher per Hand durchgeführt wurde, wurde während des Freezing-Abschnitts von Debian 3.0 Woody (Juli 2002) getestet und umgesetzt. Dank dieser Infrastruktur war es dem Sicherheitsteam möglich, aktualisierte Pakete für Apache- und OpenSSH-Probleme für alle unterstützen Architekturen (fast 20) in weniger als einem Tag bereitzustellen.
Diese Mail wurde von Wichert Akkerman an die 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.
Beachten Sie, dass die aktuelle Referenz für diese Informationen die Debian-Entwicklerreferenz
und dieser Abschnitt demnächst entfernt wird.
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 Sicherheitsanweisungen verantwortlich und betreuen security.debian.org.
Beachten Sie bitte, dass Sicherheitsanweisungen nur für veröffentlichte Distributionen erteilt werden, nicht für Testing, Unstable (siehe Wie wird die Sicherheit für Testing und Unstable gehandhabt?, Abschnitt 11.3.7) und ältere Distributionen (siehe Ich verwende eine ältere Version von Debian. Wird sie vom Debian-Sicherheitsteam unterstützt?, Abschnitt 11.3.8).
Es gibt einige Möglichkeiten, wie ein Entwickler von Sicherheitsproblemen erfahren kann:
Er bemerkt sie in einem öffentlichem Forum (Mailingliste, Webseite, etc.).
Jemand reicht einen Fehlerbericht ein (es sollte das Security-Tag verwendet oder vom Entwickler hinzugefügt werden).
Jemand informiert ihn in einer privaten E-Mail.
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:
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.
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.
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).
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.
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.
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.
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.
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.
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.
Zu guter Letzt ein paar technische Dinge, die Entwickler bedenken sollten:
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 <codename>-proposed-updates.
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.
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.
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
pbuilder
und debootstrap
können dafür hilfreich
sein).
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.debian.org/pub/SecurityUploadQueue/ hochgeladen.
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.
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.
Wenn ein Mitglied des Sicherheitsteams ein Paket akzeptiert, wird es auf security.debian.org und als passendes <codename>-proposed-updates auf ftp-master oder im Non-US-Archiv installiert.
Sicherheitsanweisungen 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 Debian-Sicherheitsanweisungen, Abschnitt 7.2 beschrieben.
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 [46].
Derzeit (Stand Mai 2005) stellt Debian keine signierten Pakete für die Distribution zur Verfügung, und die Woody- und Sarge-Veröffentlichung (3.0 und 3.1) werden diese Fähigkeit nicht integrieren. Es gibt eine Lösung für signierte Pakete, die – hoffentlich – in der nächsten Veröffentlichung (Codename Etch) enthalten sein wird. Diese neue Fähigkeit ist in apt 0.6 enthalten (ist im Moment Bestandteil der Sid-Distribution, vergleiche Apt-secure, Abschnitt 7.4.2).
Dieses Problem wird besser im Strong-Distribution-Howto
von V. Alex Brennen beschrieben.
Der derzeitige Plan zur Prüfung von Paketsignaturen mit apt
ist:
Die Release-Datei enthält die MD5-Summe von Packages.gz (die die MD5-Summen der Pakete enthält) und wird signiert. Die Signatur stammt aus einer vertrauenswürdigen Quelle.
Diese signierte Release-Datei wird beim "apt-get update" herunter geladen und zusammen mit Packages.gz gespeichert.
Wenn ein Paket installiert werden soll, wird es zuerst herunter geladen, und dann wird die MD5-Summe erstellt.
Die signierte Release-Datei wird überprüft (ob die Signatur in Ordnung ist) und die MD5-Summe der Packages.gz-Datei extrahiert. Die MD5-Summe der Packages.gz-Datei wird erstellt und geprüft, und - wenn sie übereinstimmt - wird die MD5-Summe des heruntergeladenen Paketes aus ihr extrahiert.
Wenn die MD5-Summe des heruntergeladenen Paketes die gleiche ist wie in der Packages.gz-Datei, wird das Paket installiert. Andernfalls wird der Administrator alarmiert, und das Paket wird im Zwischenspeicher gehalten (so dass der Administrator entscheiden kann, ob es installiert werden soll oder nicht). Wenn das Paket nicht in Packages.gz enthalten ist, und der Administrator das System so konfiguriert hat, dass nur geprüfte Pakete installiert werden können, wird das Paket ebenfalls nicht installiert.
Durch diese Kette von MD5-Summen ist apt
in der Lage, zu
verifizieren, dass ein Paket aus einer bestimmten Veröffentlichung stammt.
Dies ist zwar unflexibler als jedes Paket einzeln zu signieren, kann aber auch
mit den unten aufgeführten Plänen kombiniert werden.
Im Moment ist diese Vorgehensweise vollständig in apt 0.6 enthalten
,
das nun im Unstable-Zweig enthalten ist; weitere Informationen finden Sie unter
Apt-secure, Abschnitt 7.4.2. Pakete, die ein Frontend
für apt anbieten, müssen verändert werden, um an diese neue Fähigkeit angepasst
zu werden. Das gilt für aptitude
, das verändert
wurde, um zu dieser Vorgehensweise zu passen. Frontends, die bekanntermaßen
zurzeit mit dieser Fähigkeit umgehen können, sind aptitude
und
synaptic
.
Die Signierung von Paketen wurde innerhalb des Debian-Projekts ausführlich
diskutiert. Mehr Informationen hierzu finden Sie unter http://www.debian.org/News/weekly/2001/8/
und http://www.debian.org/News/weekly/2000/11/
.
Die Veröffentlichung von apt 0.6 enthält apt-secure, das ein Werkzeug
ist, mit dem ein Systemadministrator die Integrität von heruntergeladenen
Paketen mit dem oben dargestellten Verfahren überprüfen kann. Diese
Veröffentlichung enthält das Werkzeug apt-key
, um neue Schlüssel
zum Schlüsselbund von apt hinzuzufügen, welcher standardmäßig nur den aktuellen
Signierungsschlüssel des Debian-Archivs enthält.
Diese Veränderungen basieren auf dem Patch für apt
(verfügbar in
Fehler
#203741
), der diese Erweiterung zur Verfügung stellt.
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 sich dieses Paket vor seiner endgültigen Veröffentlichung
noch ziemlich verändern werden kann). Falls Sie die aktuelle Version benutzen,
schicken Sie einen Fehlerbericht für das Paket apt
.
Beachten Sie, dass, wenn Sie diese Version von apt einsetzen, kein zusätzlicher
Aufwand auf Ihrer Seite notwendig sein sollte, wenn Sie keine Debian-fremden
Quellen verwenden. In diesen Fällen wird eine zusätzliche Bestätigung von
apt-get erfordert. Dies wird verhindert, wenn Release- und Release.gpg-Dateien
in den Debian-fremden Quellen zur Verfügung stehen. Die Release-Datei kann mit
apt-ftparchive
(ist in apt-utils 0.5.0 und später enthalten)
erstellt werden, die Release.gpg ist nur die abgetrennte Signatur. Beide
können mit folgender einfacher Prozedur erstellt werden:
$ rm -f dists/unstable/Release $ apt-ftparchive release dists/unstable > dists/unstable/Release $ gpg --sign -ba -o dists/unstable/Release.gpg dists/unstable/Release
Dieser zusätzliche Entwurf, jedes Paket einzeln zu signieren, erlaubt es, Pakete zu prüfen, selbst wenn sie nicht mehr in irgendeiner Packages-Datei erwähnt werden. Und so können auch Pakete von Dritten, für die es nie eine Packages-Datei gab, unter Debian installiert werden. Dies wird aber kein Standard werden.
Dieser Entwurf zur Paketsignierung kann mit debsig-verify
und
debsigs
umgesetzt werden. Diese beiden Pakete können in einer
.deb-Datei eingebettete Signaturen erstellen und prüfen. Debian hat bereits
jetzt die Möglichkeiten, dies zu tun. Aber das Regelwerk und die Werkzeuge
hierfür werden erst nach der Woody-Veröffentlichung eingeführt.
Die aktuellen Versionen von dpkg (seit 1.9.21) beinhalten einen Patch
,
der diese Funktionen zur Verfügung stellt, sobald debsig-verify
installiert ist.
HINWEIS: Derzeit wird /etc/dpkg/dpkg.cfg
standardmäßig mit der
Option "no-debsig" ausgeliefert.
HINWEIS 2: Signaturen von Entwicklern werden im Moment entfernt, wenn sie in das Paketarchiv gelangen, da die derzeit vorzugswürdige Methode die Überprüfung der Release-Datei ist, wie es oben beschrieben wurde.
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 (obwohl wir wirklich das Testen schätzen würden), 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.
Dieser Beispielscode, umbenannt nach apt-check sigs
, sollte auf
die folgende Art benutzt werden:
# apt-get update # apt-check-sigs (... Ergebnisse ...) # apt-get dist-upgrade
Zuerst müssen Sie jedoch Folgendes tun:
Holen Sie sich den Schlüssel, den die Archiv-Software verwendet, um
Release-Dateien zu signieren, http://ftp-master.debian.org/ziyi_key_2003.asc
und fügen Sie ihn ~/.gnupg/trustedkeys.gpg
hinzu (was
standardmäßig von gpgv
benutzt wird).
gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2003.asc
Entfernen Sie alle Zeilen aus /etc/apt/sources.list
, die nicht die
normale "dists"-Struktur benutzen, oder ändern Sie das Skript, so
dass es auch mit denen funktioniert.
Ignorieren Sie die Tatsache, dass Sicherheitsaktualisierungen von Debian keine signierten Release-Dateien haben, und das Quelldateien (noch) keine richtigen Prüfsummen in der Release-Datei haben.
Bereiten Sie sich darauf vor, zu prüfen, dass die richtigen Quellen durch den richtigen Schlüssel signiert wurden.
Dies ist der Beispielscode für apt-check-sigs
. Die neuste Fassung
ist unter http://people.debian.org/~ajt/apt-check-sigs
erhältlich. Dieser Code befindet sich im Moment noch im Beta-Stadium. Für
weitere Informationen sollten Sie http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg00421.html
lesen.
#!/bin/bash # Copyright (c) 2001 Anthony Towns <ajt@debian.org> # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. rm -rf /tmp/apt-release-check mkdir /tmp/apt-release-check || exit 1 cd /tmp/apt-release-check >OK >MISSING >NOCHECK >BAD arch=`dpkg --print-installation-architecture` am_root () { [ `id -u` -eq 0 ] } get_md5sumsize () { cat "$1" | awk '/^MD5Sum:/,/^SHA1:/' | MYARG="$2" perl -ne '@f = split /\s+/; if ($f[3] eq $ENV{"MYARG"}) { print "$f[1] $f[2]\n"; exit(0); }' } checkit () { local FILE="$1" local LOOKUP="$2" Y="`get_md5sumsize Release "$LOOKUP"`" Y="`echo "$Y" | sed 's/^ *//;s/ */ /g'`" if [ ! -e "/var/lib/apt/lists/$FILE" ]; then if [ "$Y" = "" ]; then # No file, but not needed anyway echo "OK" return fi echo "$FILE" >>MISSING echo "MISSING $Y" return fi if [ "$Y" = "" ]; then echo "$FILE" >>NOCHECK echo "NOCHECK" return fi X="`md5sum < /var/lib/apt/lists/$FILE | cut -d\ -f1` `wc -c < /var/lib /apt/lists/$FILE`" X="`echo "$X" | sed 's/^ *//;s/ */ /g'`" if [ "$X" != "$Y" ]; then echo "$FILE" >>BAD echo "BAD" return fi echo "$FILE" >>OK echo "OK" } echo echo "Checking sources in /etc/apt/sources.list:" echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" echo (echo "You should take care to ensure that the distributions you're downloading " echo "are the ones you think you are downloading, and that they are as up to" echo "date as you would expect (testing and unstable should be no more than" echo "two or three days out of date, stable-updates no more than a few weeks" echo "or a month)." ) | fmt echo cat /etc/apt/sources.list | sed 's/^ *//' | grep '^[^#]' | while read ty url dist comps; do if [ "${url%%:*}" = "http" -o "${url%%:*}" = "ftp" ]; then baseurl="${url#*://}" else continue fi echo "Source: ${ty} ${url} ${dist} ${comps}" rm -f Release Release.gpg lynx -reload -dump "${url}/dists/${dist}/Release" >/dev/null 2>&1 wget -q -O Release "${url}/dists/${dist}/Release" if ! grep -q '^' Release; then echo " * NO TOP-LEVEL Release FILE" >Release else origline=`sed -n 's/^Origin: *//p' Release | head -1` lablline=`sed -n 's/^Label: *//p' Release | head -1` suitline=`sed -n 's/^Suite: *//p' Release | head -1` codeline=`sed -n 's/^Codename: *//p' Release | head -1` dateline=`grep "^Date:" Release | head -1` dscrline=`grep "^Description:" Release | head -1` echo " o Origin: $origline/$lablline" echo " o Suite: $suitline/$codeline" echo " o $dateline" echo " o $dscrline" if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeline" ]; then echo " * WARNING: asked for $dist, got $suitline/$codeline" fi lynx -reload -dump "${url}/dists/${dist}/Release.gpg" >/dev/null 2>&1 wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg" gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/null 2>&1 | sed -n "s/^\[GNUPG:\] //p" | (okay=0; err=""; while read gpgcode rest; do if [ "$gpgcode" = "GOODSIG" ]; then if [ "$err" != "" ]; then echo " * Signed by ${err# } key: ${rest#* }" else echo " o Signed by: ${rest#* }" okay=1 fi err="" elif [ "$gpgcode" = "BADSIG" ]; then echo " * BAD SIGNATURE BY: ${rest#* }" err="" elif [ "$gpgcode" = "ERRSIG" ]; then echo " * COULDN'T CHECK SIGNATURE BY KEYID: ${rest %% *}" err="" elif [ "$gpgcode" = "SIGREVOKED" ]; then err="$err REVOKED" elif [ "$gpgcode" = "SIGEXPIRED" ]; then err="$err EXPIRED" fi done if [ "$okay" != 1 ]; then echo " * NO VALID SIGNATURE" >Release fi) fi okaycomps="" for comp in $comps; do if [ "$ty" = "deb" ]; then X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Release" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Release") Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Packages" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Packages") if [ "$X $Y" = "OK OK" ]; then okaycomps="$okaycomps $comp" else echo " * PROBLEMS WITH $comp ($X, $Y)" fi elif [ "$ty" = "deb-src" ]; then X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Release" | sed 's,//*,_,g'`" "${comp}/source/Release") Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Sources" | sed 's,//*,_,g'`" "${comp}/source/Sources") if [ "$X $Y" = "OK OK" ]; then okaycomps="$okaycomps $comp" else echo " * PROBLEMS WITH component $comp ($X, $Y)" fi fi done [ "$okaycomps" = "" ] || echo " o Okay:$okaycomps" echo done echo "Results" echo "~~~~~~~" echo allokay=true cd /tmp/apt-release-check diff <(cat BAD MISSING NOCHECK OK | sort) <(cd /var/lib/apt/lists && find . -type f -maxdepth 1 | sed 's,^\./,,g' | grep '_' | sort) | sed -n 's/^> //p' >UNVALIDATED cd /tmp/apt-release-check if grep -q ^ UNVALIDATED; then allokay=false (echo "The following files in /var/lib/apt/lists have not been validated." echo "This could turn out to be a harmless indication that this script" echo "is buggy or out of date, or it could let trojaned packages get onto" echo "your system." ) | fmt echo sed 's/^/ /' < UNVALIDATED echo fi if grep -q ^ BAD; then allokay=false (echo "The contents of the following files in /var/lib/apt/lists does not" echo "match what was expected. This may mean these sources are out of date," echo "that the archive is having problems, or that someone is actively" echo "using your mirror to distribute trojans." if am_root; then echo "The files have been renamed to have the extension .FAILED and" echo "will be ignored by apt." cat BAD | while read a; do mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED done fi) | fmt echo sed 's/^/ /' < BAD echo fi if grep -q ^ MISSING; then allokay=false (echo "The following files from /var/lib/apt/lists were missing. This" echo "may cause you to miss out on updates to some vulnerable packages." ) | fmt echo sed 's/^/ /' < MISSING echo fi if grep -q ^ NOCHECK; then allokay=false (echo "The contents of the following files in /var/lib/apt/lists could not" echo "be validated due to the lack of a signed Release file, or the lack" echo "of an appropriate entry in a signed Release file. This probably" echo "means that the maintainers of these sources are slack, but may mean" echo "these sources are being actively used to distribute trojans." if am_root; then echo "The files have been renamed to have the extension .FAILED and" echo "will be ignored by apt." cat NOCHECK | while read a; do mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED done fi) | fmt echo sed 's/^/ /' < NOCHECK echo fi if $allokay; then echo 'Everything seems okay!' echo fi rm -rf /tmp/apt-release-check
Sie müssen vielleicht bei Sid diesen Patch verwenden, da
md5sum
ein '-' an die Summe anfügt, wenn die Ausgabe auf stdin
erfolgt:
@@ -37,7 +37,7 @@ local LOOKUP="$2" Y="`get_md5sumsize Release "$LOOKUP"`" - Y="`echo "$Y" | sed 's/^ *//;s/ */ /g'`" + Y="`echo "$Y" | sed 's/-//;s/^ *//;s/ */ /g'`" if [ ! -e "/var/lib/apt/lists/$FILE" ]; then if [ "$Y" = "" ]; then @@ -55,7 +55,7 @@ return fi X="`md5sum < /var/lib/apt/lists/$FILE` `wc -c < /var/lib/apt/lists/$FILE`" - X="`echo "$X" | sed 's/^ *//;s/ */ /g'`" + X="`echo "$X" | sed 's/-//;s/^ *//;s/ */ /g'`" if [ "$X" != "$Y" ]; then echo "$FILE" >>BAD echo "BAD"
[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ weiter ]
Anleitung zum Absichern von Debian
Version: 3.2, Thu, 27 Oct 2005 23:34:55 +0000jfs@debian.org