Linux Systemd mit Ersatz für Syslog

Mit einem neuen Journal-Dämon wollen die Entwickler Lennart Poettering und Kay Sievers die Nachteile des Syslog-Protokolls überwinden. Dazu implementierten sie eine Erweiterung für den Init-Dämon Systemd.

Eine Erweiterung für den Init-Dämon Systemd soll den bisher in Linux-Distributionen genutzten Syslog-Dämon ersetzen. Das sogenannte Journal soll nach dem Willen der Erfinder Lennart Poettering und Kay Sievers einige Nachteile der klassischen Systemprotokollierung Syslog überwinden.

Nachteile von Syslog

In einer detaillierten Vorstellung des Journal-Dämons gehen Poettering und Sievers auf einzelne Probleme von Syslog ein. Demnach leide vor allem die Sicherheit bei der Verwendung von Syslog, da unter anderem Nutzer vollen Zugriff auf die Logdateien haben könnten. Auch lassen sich die Logdateien einfach manipulieren und dadurch könnten mögliche Angriffe vor Administratoren verschleiert werden. Dies geschah auch bei dem Einbruch auf Kernel.org.

Auch könnten mit Syslog keine Binärdaten aufgezeichnet werden. Ebenso sei es nur sehr schwer möglich, Aktionen in der frühen Startphase eines Rechners aufzuzeichnen. Darüber hinaus wird bemängelt, dass Zeitstempel keine Informationen über die Zeitzonen besäßen.

Eine weiteres Problem mit Syslog sei, dass es nur eines von vielen verschiedenen Log-Systemen im Betriebssystem sei. So gibt es neben Syslog auch noch Kernel-Logs, Firmware-Logs, anwendungsspezifische Log-Dateien und andere.

Journal

Diese und weitere Probleme seien nicht über Veränderungen an Syslog zu beseitigen. Deshalb schlagen die beiden Red-Hat-Angestellten eine Neuimplementierung vor, die an den Initialisierungsdämon Systemd gebunden ist. Ein erster Quellcode von Journal ist bereits veröffentlicht und im Git-Repositoy von Systemd eingepflegt.

Das Konzept von Journal ist offensichtlich: Es soll die Funktionen bereitstellen, die nach Meinung der Entwickler in Syslog fehlen. So sollen auch wesentlich mehr Metadaten in Log-Einträgen gespeichert beziehungsweise an diese angehängt werden können.

Um die Sicherheit zu erhöhen, werden Hashes für Log-Einträge berechnet. Diese werden dabei aus dem Eintrag selbst und dem Hashwert des vorangegangenen Eintrages erzeugt. So entsteht eine Kette von verifizierbaren Werten, die schwer zu manipulieren ist. Auch sollen die Log-Dateien von Nutzern und Administratoren in unterschiedlichen Dateien gespeichert werden und der Zugriff über Access-Controll-Lists steuerbar sein.

Optional können Entwickler 128 Bit lange Universally Unique Identifier (UUID) für Meldungen erzeugen. So sollen sich gleichartige Meldungen auffinden lassen, auch wenn sich der explizite String der Meldung ändert, was beispielsweise durch die Aktualisierung einer Anwendung geschehen kann. Auch sollen die Einträge mit einem exakten Zeitstempel versehen werden.

Journal in Fedora 17

Dass die beiden Entwickler von ihrem Konzept sehr überzeugt sind, ist in der FAQ-Sektion der Vorstellung zu lesen. So verteidigen sie darin die zwingende Anbindung an Systemd und die Verwendung von UUIDs. Auch wollen sich die Entwickler vorbehalten, das Dateiformat für die Log-Einträge eventuell zu verändern und an ihre Bedürfnisse anzupassen. Deshalb weisen sie auch darauf hin, dass noch keine Dokumentation für das Dateiformat existiert und die beiden in naher Zukunft auch keine schreiben werden, schließlich sei der Quellcode einsehbar.

Noch fehlen dem Journal-Dämon einige Funktionen, die Poettering und Sievers integrieren wollen, aber die Kernfunktionen seien bereits umgesetzt. Weiterhin planen sie, Journal in Fedora 17 zur Verfügung zu stellen. Allerdings soll Rsyslog, die von Fedora genutzte Implementierung von Syslog, zunächst weiterhin als Standard genutzt werden und Journal nur zum Testen und Entwickeln bereitgestellt werden.