Security + Administration im Debian-Projekt

Dieser Abschnitt ist Teil eines Vortrags, den mehrere Debian-Entwickler gemeinsam auf derm LinuxTag 2005 halten. Mir kommt dabei die Ehre zuteil, über Debian Security und Debian System Administration zu reden.

Die folgenden Texte sind für die offiziele Dokumentation des LinuxTag 2005 geschrieben und werden dort leider nur auf der Konferenz-DVD dieses Jahres veröffentlicht.

In der folgenden Abbildung ist grob schematisch dargstellt, welche Schritte das Sicherheitsteam von Debian für eine einzige Aktualisierung eines Pakets aufgrund von Sicherheitsproblemen durchführen muß. Um die Übersichtlichkeit nicht noch mehr zu gefährden wurde die Verarbeitung nicht bis ins letzte Detail beschrieben. Die Details werden im Vortrag beschrieben.

Das Sicherheitsteam von Debian kann von unterschiedlichen Seiten über ein Sicherheitsproblem in einem Paket informiert werden, das in einer stabilen Debian-Distribution enthalten ist. Dabei handelt es sich teilweise um öffentliche und teilweise um nicht-öffentliche Quellen. Letztere verkomplizieren die Verarbeitung ein wenig.

• Über die Mailing-Listen bugtraq und full-disclosure werden viele Software-Fehler berichtet, diese Quelle ist öffentlich und wird entsprechend gefiltert.
• Einige Anwender berichten über Sicherheitsprobleme und schreiben einen Fehlerbericht, der dem Sicherheitsteam direkt oder indirekt zugänglich gemacht wird.
• Das Debian Security Audit-Projekt und weitere externe Forscher informieren das Sicherheitsteam direkt über gefundene Probleme. Diese sind dann erst einmal nicht öffentlich.
• Über vendor-sec erfahren wir von weiteren Problemen, teils öffentlich und teils nicht öffentlich.
• In seltenen Fällen werden wir auch von MITRE vorab informiert oder erhalten über die öffentliche CVE-Datenbank Informationen über bekannt gewordene Sicherheitsprobleme.

Wenn das Problem öffentlich ist, kann direkt mit der Fortführung weitergefahren werden. Wenn das jedoch nicht der Fall ist, muß koordiniert werden, wer wann und wie diese Probleme veröffentlicht. In ernsten Fällen wird sich auch mit anderen Distributionen über vendor-sec koordiniert, damit das Problem bei Bekanntgabe zeitgleich korrigiert werden kann.

Parallel dazu wird eine CVE-ID für das Problem vergeben. Im August 2002 wurde Debian zusammen mit Red Hat als erste Distributionen für GNU/Linux für CVE-kompatibel erklärt. Alle in diesen Distributionen veröffentlichten Fehler tragen seit dem auch eine CVE-ID. Das Common Vulnerabilities and Exposures Project (CVE) pflegt eine öffentliche Datenbank mit eindeutigen IDs für Verwundbarkeiten in Software.

Jedes Sicherheitsproblem, das in Debian korrigiert wird, muß folglich eine CVE-ID zugewiesen bekommen. Für nicht veröffentlichte Probleme kann eine ID aus einem kleinen Pool zugewiesener IDs verwendet werden. Bei öffentlichen Problemen muß MITRE selbst eine ID zuweisen.

Das Sicherheitsteam von Debian behandelt nur veröffentlichte Distributionen sowie die, die es werden wollen. Soll heißen, daß nur die jeweils stabile Distribution sowie eine zeitlang deren Vorgänger mit aktualisierten Paketen und Gutachten unterstützt wird. Kurz vor einem neuen Release wird auch die eingefrorene zukünftige Distribution unterstützt. Explizit nicht unterstützt wird die sich in der Entwicklung befindliche Distribution unstable.

Nach eine Korrektur entwickelt und getestet ist, werden neue Pakete gebaut. Dieses wird durch eine spezielle Instanz der Debian Archive Katie Suite (DAK) unterstützt. Das Sicherheitsteam muß dazu wie im normalen Archiv ein Paket vorbereiten und hochladen. Anschließend wird der Quellcode dem Netzwerk der Buildd-Rechner zur Verfügung gestellt, die das Paket automatisch bauen.

Nachdem die Logs signiert wurden, werden die Pakete in das private Archiv hochgeladen, in dem sie solange zwischengespeichert werden, bis das Sicherheitsgutachten schließlich veröffentlicht wird. Erst danach stehen die Pakete auch der Öffentlichkeit via HTTP und FTP zur Verfügung.

Zusammen mit dem Pfad und einer Kontrollsumme werden die aktualisierten Pakete in einem Sicherheitsgutachten veröffentlicht, das digital signiert über eine Mailing-Liste verteilt wird. Parallel dazu wird das Gutachten ins CVS-Archiv der Website importiert, damit es dort automatisch zur Verfügung steht.

Natürlich darf während dieses Prozesses der Paket-Betreuer nicht ausgeschlossen werden. Bei öffentlichen Problemen wird der Betreuer von Anfang an mit in die Entwicklung einbezogen. In einigen Fällen stammen die Korrekturen oder korrigierten Pakete sogar vom Betreuer selbst.

Bei bisher noch nicht veröffentlichten Problemen wird der Betreuer erst relativ spät in die Bearbeitung einbezogen, um die Gefahr vorzeitiger Veröffentlichung zu verhindern. Es besteht jedoch auf jeden Fall ausreichend Zeit, ein Paket vorzubereiten, so daß das Gutachten auch über korrigierte Pakete in der Distribution unstable berichten kann.

Die Liste vendor-sec ist für viele Personen ein schwarzes Loch oder bestenfalls ein Buch mit sieben Siegeln. Dabei handelt es sich jedoch um die wichtigste Ressource für die Kommunikation von Sicherheitsteams verschiedener Distributionen. Vertreten sind zudem auch einige Hersteller alter Unix-Systeme sowie die Sicherheitsteams mehrerer BSD-Varianten.

Über diese Liste können schwerwiegende Sicherheitsprobleme diskutiert und koordiniert werden. Insbesondere letzteres ist wichtig, denn bei schwerwiegenden Problemen sollten alle wichtigen Distributionen zeitgleich mit der Veröffentlichung des Fehlers auch eine Korrektur anbieten, um die globalen Auswirkungen so gering wie möglich zu halten.

Das ist insbesondere in Zeiten von automatischen Viren und Würmern wichtig, die derartige Sicherheitsprobleme ausnutzen und damit erheblichen Schaden anrichten könnten. Dazu muß man sich nur die Folgen der verschiedenen Sober-Viren o.ä. ansehen.

Ohne das Buildd-Netzwerk und die Katie-Suite wäre es heutzutage nicht mehr möglich, aktualisierte Pakete für Debian-Distributionen bereitzustellen. Für Debian 2.2 (potato) existierte diese großartige Errungenschaft noch nicht, wodurch jedes Paket erheblich Zeit und Aufwand bedeutet hat, da für sechs Architekturen manuell kompiliert werden und das Archiv selbst gepflegt werden mußte.

Mit dem Release von sarge müssen 22 Architekturen (11x Sarge und 11x Woody) zumindest zeitweise parallel gepflegt werden. Das ist ohne derartige Unterstützung allein aufgrund der Menge unterschiedlicher Architekturen sowie unterschiedlicher Pakete gar nicht mehr möglich.

Das Debian-Projekt betreibt gut 40 Rechner unterschiedlicher Bauart, um das Projekt aufrecht zu erhalten und um die Distribution zu verwalten und zu bauen. Das Adminstrationsteam sorgt zusammen mit einen Site-Admin für die Wartung der Maschinen, die überall auf der Welt verteilt aufgestellt sind.

Der Site-Admin ist die Person vor Ort, die (im Notfall) physikalischen Zugriff zum Computer hat, und die hauptsächlich im Fall von Schäden an der Hardware in Anspruch genommen werden. Für die normale Administration wird sie meistens nicht benötigt und muß daher für das Debian-Projekt auch nicht übermäßig Zeit aufwenden.

Die meisten dieser Rechner stehen allen Projekt-Teilnehmern gleichermaßen zur Verfügung, damit sie die im Projekt erforderlichen Aufgaben erledigen können. Ein Teil der Rechner steht jedoch nur einem kleinen Teil des Projekts für administrative Aufgaben zur Verfügung.

Daraus ergibt sich auch schon das erste Problem, denn wie sollen die Accounts auf 40 Rechnern verwaltet werden? In der Anfangszeit stand dem Projekt nur ein einziger Rechner zur Verfügung, später dann zwei. Da konnte man noch mit paralleler Erzeugung von Accounts arbeiten und unterschiedliche Paßwörter akzeptieren.

Bei 40 Rechnern sieht das jedoch schon anders aus. Die Debian-Administratoren haben sich daher für eine zentrale Verwaltung der Accounts entschieden, die regelmäßig auf den Rechnen synchronisiert werden. Diese Daten werden zentral gewartet und sind über passende Frontends für die Administratoren und Entwickler zugänglich.

Dafür wird der Mechanismus "System Databases and Name Service Switch" der GLIBC ausgenutzt, mit dem eine zweite Account-Datenbank verwendet werden kann. Dieses wird in regelmäßigen Abständen mit dem zentralen Server abgeglichen. Dadurch wird verhindert, daß bei einer Störung im Netzwerk gleich alle Accounts mit ausfallen.

Als Bonus dieser Lösung ist db.debian.org als zentrales Register von und für Debian-Entwickler entstanden. Darüber können die persönlichen Daten im Verzeichnisdienst manipuliert oder das Paßwort gesetzt werden. Über einen Mail-Robot können zudem Rechner in der speziellen DNS-Zone "debian.net" registriert werden.

Darüberhinaus müssen die verschiedenen Rechner auf einem aktuellen Stand gehalten und bei Sicherheitsproblemen aktualisiert werden. Dazu ist ein Programm im Einsatz, das den Server mit den aktualisierten Paketen überwacht und eine Mail verschickt, wenn ein Paket aktualisiert werden muß.

Um zudem gleiche Aktionen auf mehreren Rechnern auszuführen, stehen mehrere Werkzeuge zur Verfügung. Ryan Murray und James Troup verwenden das gnome-terminal, das derartige Funktionalität zur Verfügung stellt. Ich verwende ein Skript, das sich auf einer festzulegenden Anzahl Rechner nacheinander einloggt und Programme ausführt.