Linux-Umbau

Systemd-Entwickler wollen nun auch System Log ersetzen

Andreas Proschofsky, 22. November 2011, 14:55

Neues "Jounal" als Zusatzfunktion des Boot-Services - Soll Sicherheit verbessern und mehr Metadaten bieten

Mit Systemd etabliert sich derzeit ein neues Boot-System im Linux-Umfeld, sowohl Red Hat als auch openSUSE setzen in aktuellen Versionen auf die neue Lösung. Doch damit nicht genug, widmen sich deren Entwickler nun der Erneuerung des nächsten zentralen Systemservices: Geht es nach den aktuellen Plänen der Red-Hat-Entwickler Lennart Poettering und Kay Sievers, soll das bisherige Syslog durch ein in Systemd integriertes "Journal" ersetzt werden.

Defizite

Die eigene Motivation hinter diesem Vorhaben erklärt man zunächst einmal mit den Defiziten aktueller Lösung: System Logs seien leicht manipulierbar, um etwa die Spuren eines Angriffs zu verschleiern. Genau dies habe auch dazu geführt, dass der Einbruch auf den Servern von kernel.org überhaupt nur durch Zufall erkannt wurde. Zudem hätten oftmals eine Fülle von lokalen NutzerInnen vollen (Lese-)Zugriff auf die Logs, auch würde gerade der Anfang des Boots nicht wirklih zuverlässig protokolliert. Darüber hinaus bemängelt man, dass keine Zeitzoneninformationen in den Timestamps mitgespeichert werden, und die Komplexität noch dadurch erhöht werden, dass es neben dem Syslog noch einige andere Services gebe, die ähnliche Informationen - etwa für den Kernel oder für Firmware - aufzeichnen.

Alternative

All diese Probleme will man mit dem "Journal" beseitigen: Dabei sollen sämtliche Einträge mit einem Hash versehen werden, dieser setzt sich jeweils aus dem betreffenden Eintrag und dem vorherigen Hashwert zusammen. Auf diese Weise würden nicht nur Veränderungen sondern auch Löschungen nachvollziehbar. Zudem soll der Zugriff auf die geloggten Informationen per Access Control Lists (ACL) verwaltet werden können, optional soll es eine Universally Unique Identifier (UUID) geben, mit der zusammengehörige Einträge schneller auffindbar werden sollen.

Ausblick

Die Entwicklung des Journals findet derzeit in einem separaten Zweig der Systemd-Entwicklung statt, die Entwickler verweisen darauf, dass es sich noch um eine frühe Version handle, bei der auch noch zentrale Änderungen zu erwarten sind. Mit Fedora 17 soll dieser Ansatz dann erstmals ausgeliefert werden, dort allerdings noch optional, aber natürlich mit der Hoffnung später zur Default-Lösung zu avancieren. (apo, derStandard.at, 22.11.11)

Kommentar posten
Posting 1 bis 25 von 41
1 2
aufgeklärtbisheiter
10
23.11.2011, 00:53

cool. Jetzt noch eine gscheide Registry ... ;-)

rks
 
00
23.11.2011, 22:06

Dilbert, bist Du es?

entity13
00
23.11.2011, 08:24

*kotz

Kringskrongs
00
23.11.2011, 07:55

*würg

F. Ritzl
00
22.11.2011, 18:16
mir ist schon die Umstellung auf pulseaudio furchtbar auf die Nerven gegangen

tvtime etc. laufen nur noch mit workarounds ...

Das scheue Reh
20
22.11.2011, 20:46

Audio hat ja nie richtig funktioniert und der Umbau war natürlich notwendig.

F. Ritzl
03
23.11.2011, 05:39

inwiefern hat Audio "nie richtig funktioniert"?

Banal gesagt: Was auch immer ich _heute_ zum Laufen bringen will, ist ein Krampf (oder anders gesagt: viele Dinge sind nicht auf pulse umgestellt worden und werden das auch nicht mehr) - früher auf /dev/dsp umgeleitet und gut war's.

aceFruchtsaft
23
22.11.2011, 17:39

Poettering arbeitet wohl daran, aus Linux Windows zu machen. Weg mit dem einfachen Zeug, egal ob es funktioniert, hin zu möglichst komplex, mühsam zu konfigurieren, für Nicht-Entwickler undurchschaubar, etc.

Ich kann gerne auf XML-Konfigurationsdateien und binäre Logs mit UUID und sonstigen Späßen verzichten.

werwolfi
13
22.11.2011, 20:30

Wo steht was von “binären logs“?
Es wird bei jeder Zeile ein Hash mitgespeichert, der auch von der Zeile davor abhängt. Geniale Idee, um unerlaubte Änderungen schnell entdecken zu können, obwohl das log immer noch als Textdatei vorliegt.

NONE
01
23.11.2011, 05:30

aceFruchtsaft hat völlig Recht.

Linux wird verblödet - von den Distributionen.

werwolfi
00
23.11.2011, 11:13

Er mag vielleicht in einigen Belangen recht haben, aber für das Konzept gibts gute Argumente - lies den verlinkten Artikel.
Und wie auch schon gesagt: du kannst immer einen syslogd parallel betreiben wenn du glaubst.

rks
 
00
22.11.2011, 22:29

Das Konzept sieht tatsächlich ein binäres Format vor, und zwar ein "undokumentiertes", d.h. Zugriff nur über eine library. Nein danke.

Das hash-chaining wird übrigens auch nichts helfen, solange kein MAC verwendet wird, also kein geheimer key eingebracht wird, sonst kann man ja jederzeit alle hashes neu rechnen. Und mit MAC stellt sich immer noch die Frage, wo und wie denn dieser key gespeichert werden soll, etc.

Eine viel bessere Lösung gibt es auch schon lange: remote syslog.

werwolfi
02
23.11.2011, 01:51
Sti mt, steht allerdings so nicht im Artikel. Ich habe mir jetzt das verlinkte Designdokument angesehen:

Sie haben wirklich nachgedacht, u*nd für einen Großteil der neuen Features (v.a. Security/Access Control) ist ein binäres Format notwendig.
Das stellt aus mehreren gründen kein Problem dar:
* die APIs und Commandline Tools sind Teil des Logging-Systems - wenn dein System diese Logs produziert, kannst du sie auch lesen.
* der Footprint wird sehr klein und die Implementierung simpler als der syslogd (obwohl es mehr kann) und kann daher leicht nachinstalliert werden auf z.b. auf einer reinen Analysemaschine (es gibt nämlich auch remote logging)
* falls du wirklich unbedingt Klartextformat brauchst - ein klassischer syslogd kann jederzeit parallel betrieben werden, das neue System ist darauf ausgelegt, die Meldungen landen dann in beiden.

rks
 
00
23.11.2011, 19:46

Mich überzeugt das Design-Konzept nicht. Ich sehe da eher Lösungen auf der Suche nach einem Problem.

Abgesehen davon: das Unix-Konzept, alles in human-readable Files zu speichern, hat schon seinen Wert. Natürlich kann man auch journalcat, journalgrep, journaltail -f und so anbieten, aber schön ist das nicht.

Smoothies? Obst gehört gebrannt
13
22.11.2011, 16:34

Geh bäh, geht jetzt auch bei Logs (wie schon längere Zeit bei Konfigurationsdateien) der Trend von Plaintext-Files zu XML-Ungetümen? :-/

Das scheue Reh
00
22.11.2011, 20:50

Am nervigsten sind doch Tabulatoren als Trennzeichen und pseudo xml wie z.B. in der Apache conf.

xml kann man validieren, sehr einfach parsen...
json wäre eine Alternative aber halt nicht eXtensible.

aceFruchtsaft
01
22.11.2011, 23:54

XML ist super, wenn es automatisiert verarbeitet werden soll. Wenn Menschen config-Dateien direkt editieren sollen, ist XML aber ein Dreck.

/dev/stderr
01
23.11.2011, 23:26
Amen!

Stoppt den ZENSURWAHN der Politiker - JETZT
00
22.11.2011, 15:44
not sure if want

anstelle dass syslog-ng zum neuen Standard wird, wird wiedermal was neues entwickelt, was ziemlich sicher nicht besser sein wird, wie syslog-ng (oder ähnliches)

außerdem will ich nicht wissen, wie lange es braucht um täglich 1000000en Zeilen von hashes zu verifizieren und was im Fehlerfall zu machen ist...

nächstes problem: wenn in mehrere dateien verteilt wird und dennoch 1 nachricht in mehreren dateien landet, bekommt die selbe nachricht zur selben uhrzeit unterschiedliche hashes.

naja... wers braucht...
ich sorge lieber dafür, dass meine filepermissions korrekt gesetzt sind ;)

werwolfi
00
23.11.2011, 01:56

Die Hashes dienen ja auch nicht der Identifikation, sondern der Verifikation, also müssen sie unterschiedlich sein.
Zur Identifikation einzelner Nachrichten kann man (aber muss nicht) UUIDs verwenden.
Lies das verlinkte Designdokument, das zerstreut deine Zweifel, insbesondere kann man immer einen klassischen syslogd zusätzlich betreiben.

wilcox
01
22.11.2011, 15:12

bin mir nicht sicher ob mir das gefaellt.
das unkomplizierte handling von textfiles hat schon was sehr charmantes.

der Pinguin
 
00
22.11.2011, 15:21
seh ich auch so.

und die kann ich auch leicht grep'en... syslog können außerdem der großteil der netzwerkgeräte wie router, switches, etc. aber die zeit bleibt halt nicht stehen.

werwolfi
00
23.11.2011, 01:58

Lies das Dokument - die Suche wird leichter als mit grep... Und außerdem kann man jederzeit einen klassischen syslogd parallel betreiben falls man glaubt das zu brauchen.

Reini Urban
10
22.11.2011, 15:35
Ein Hash ist nix binäres

log bleibt text.
es kommt lediglich ein git ähnlicher tag dazu.

allerdings lassen sich löschungen auch wieder faken, nur muss man halt das ganze logfile neu generieren. ist etwas aufwendiger.

werwolfi
01
22.11.2011, 20:34

Wie willst du Löschungen “faken“ (außer du machst ein komplett neues Logfile) wenn der Hash auch immer die Zeile davor einschließt?

Kommentar posten
Posting 1 bis 25 von 41
1 2

Die Kommentare von Usern und Userinnen geben nicht notwendigerweise die Meinung der Redaktion wieder. Die Redaktion behält sich vor, Kommentare, welche straf- oder zivilrechtliche Normen verletzen, den guten Sitten widersprechen oder sonst dem Ansehen des Mediums zuwiderlaufen (siehe ausführliche Forenregeln), zu entfernen. Der/Die Benutzer/in kann diesfalls keine Ansprüche stellen. Weiters behält sich die derStandard.at GmbH vor, Schadenersatzansprüche geltend zu machen und strafrechtlich relevante Tatbestände zur Anzeige zu bringen.