debsecan
Hand auf's Herz: Die meisten von uns setzen – entgegen aller Empfehlungen – statt Debian “stable” doch Debian “unstable” (oder zumindest “testing”) auf Produktionssystemen ein. Mit debsecan gibt es nun eine Möglichkeit, auch für solche Systeme Warnhinweise zu Sicherheitsproblemen zu beziehen.
Offiziellen Sicherheitsunterstützung vom Debian-Security-Team gibt es zwar nur für Debian “stable”, aber das Debian testing security team
pflegt eine Schwachstellendatenbank, die das komplette Debian-Archiv abdeckt. Ursprünglich lag der Fokus auf “testing” (wie der Name besagt), aber wenn einmal die ganzen historischen Debian-Security-Advisories einsortiert sind, erfordert die Abdeckung von “unstable” (und auch “stable”) nur geringen zusätzlichen Aufwand, so daß die Daten auch für andere Zwecke einzusetzen sind (siehe auch die Erläuterungen zur Arbeitsweise des Testing-Security-Teams).
Im Vergleich zu anderen Schwachstellendatenbanken (wie CVE, OSVDB, VuXML oder auch OVAL) liegt die Besonderheit darin, daß die Schwachstellen mit Debian-Paketen und deren Versionen verknüpft werden – und zwar so, daß eine maschinelle Auswertung möglich ist. Wenn man diese Datenbanken mit der Debian-Paketdatenbank verknüpft (was diese Webanwendung macht), dann erhält man einen ziemlich guten Überblick, wie es um die Sicherheit von Debian als Distribution bestellt ist (ich war überrascht: gar nicht so schlecht).
Naturgemäß interessiert den Systemadministrator nicht so sehr, wie die Distribution im allgemeinen dasteht, sondern welche Schwachstellen für seine eigenen Systeme relevant sind. Hier kommt debsecan ins Spiel. Dieses kleine Programm lädt eine kondensierte Fassung der Debian-Schwachstellendatenbank herunter und ermittelt mit diesen Daten den Sicherheitsstatus der lokal installierten Pakete. In Kürze wird die Version 0.2 verfügbar sein, die einen äußerst peinlichen Fehler behebt: Der ganze Aufwand zur korrekten Versionsanlyse verpuffte weitgehend wirkungslos, weil nur Pakete korrekt berücksichtigt wurden, deren Namen gleich dem Quellpaket ist (also “binary package” gleich “source package”). Die neue Version erkennt daher weitaus mehr Pakete als verwundbar.
Ein kleines Skript, debsecan-create-cron, kam ebenfalls hinzu: Damit kann man einen cron-Eintrag anlegen, der dafür sorgt, daß der Systemadministrator root einmal am Tag den Sicherheitsstatus des Systems mitgeteilt bekommt (sofern sich etwas geändert hat). Ein bißchen ist das ein Schritt Richtung Erfüllung eines langgehegten Traumes: maßgeschneiderte Sicherheitshinweise, die nur möglichst relevante Schwachstellen melden. Letztlich ist das freilich utopisch, da wegen der außerordentlichen Konfigurierbarkeit von GNU/Linux-Systemen Ansätze wie das eingangs erwähnte OVAL scheitern müssen. Aber selbst wenn nur ein Drittel der von debsecan gemeldeten Schwachstellen tatsächlich relevant sind, ist das allemal besser, als selbst fünf bis zehn Mailinglisten zu lesen.
Was debsecan allerdings noch fehlt, ist die Unterstützung von “APT pinning” (oder genauer: das Mischen von Paketen aus verschiedenen Releases). In diesem Fall muß man entweder --suite sid angeben, was zur fälschlicherweise als verwundbar gekennzeichneten Paketen führt, oder die mehrheitlich eingesetzte Suite, wodurch mitunter Schwachstellen ausgelassen werden. Keine der Alternativen ist wirklich überzeugend. Ich fand aber mittlerweile heraus, wie eine Lösung grundsätzlich aussieht, so daß keine prinzipiellen Hürden mehr bestehen. Allerdings ist einiges an Programmierarbeit erforderlich, bevor diese Ideen auch wirklich umgesetzt sind.
Wer sich mit Sicherheitsmanagement von Linux-Systemen näher beschäftigt hat, kennt auch noch ein weiteres Problem, von dem alle GNU/Linux-Distributionen betroffen sind: die Kernel-Entwickler, die die kernel.org-Kernels bereitstellen, betreiben keine Sicherheitsunterstützung. Momentan werden für Debian die benötigten Details zu Schwachstellen weitab des eigentlichen Kernel-Entwicklungsprozesses extrahiert, was halbwegs funktioniert, aber nicht besonders effizient ist. Hinzu kommt auf Debian-Seite der Wildwuchs an Kernel-Paketen in “sarge”, der erst für die 2.6-Kernels in “etch”, dem Nachfolger, vollständig abgeschafft wird. Deswegen liefert debsecan nur dann brauchbare Ergebnisse, was Kernel-Schwachstellen angeht, wenn von linux-2.6 abgeleitete Pakete installiert sind, weil nur für diese Pakete der Sicherheitsstatus (immerhin auf dem Stand der CVE-Datenbank, also aktueller als die meisten Distributions-Advisories) geführt wird.
Ein weiteres Problem ist inzwischen aufgetaucht: Viele Debian-Installationen enthalten verwaiste Pakete, die inzwischen durch neue Fassungen mit anderem Namen ersetzt wurden. Wenn das “source package” als korrigiert gemeldet wird, geht debsecan im Moment davon aus, daß auch ein Update für das “binary package” verfügbar ist. Das stimmt aber nicht, weil das “binary package” mittlerweile gar nicht mehr von diesem “source package” gebaut wird. Die Korrekt sieht in diesem Fall so aus, daß das alte Paket entfernt wird. Ich weiß im Moment allerdings nicht, wie hier Abhilfe möglich ist, ohne komplette Paketlisten hin- und herzuschicken.
Trotz dieser Mängel hoffe ich, daß debsecan bereits in der vorliegenden Form hilfreich ist und Systemadministratoren dabei unterstützt, unnötige (weil im Prinzip durch Debian bereits korrigierte) Schwachstellen auszumerzen.
Note: Seit Version 0.3 unterstützt
debsecanPinning und kennzeichnet verwaiste Pakete.
Revisions
2005-12-19 21:15: Veröffentlicht.
2005-12-28: Nachtrag hinzugefügt.