Systemd will unbemerkte Manipulation von Log-Dateien verhindern

  • Ein extern abgespeicherter Schlüssel soll Manipulationen verhindern.
    vergrößern 581x650
    screenshot: lennart poettering

    Ein extern abgespeicherter Schlüssel soll Manipulationen verhindern.

Dank "Forward Secure Sealing" lässt sich jede Veränderung erkennen - Bereits in der nächsten Release enthalten

Das Bootsystem Systemd will mit einer neuen Funktion die Sicherheit von Linux-Systemen grundlegend verbessern. Mithilfe eines Verfahrens namens "Forward Secure Sealing" (FSS) sollen künftig alle Log-Dateien digital signiert und so gegen jegliche Manipulationen geschützt werden.

Einbruch

Die Veränderung von Log-Dateien ist eine übliche Methode, um bei Einbrüchen auf einem System die Spuren zu verwischen. Dies soll dank FFS verhindert werden: Im Endeffekt bliebe einer Angreiferin nur mehr das vollständige Löschen der Log-Dateien, womit die Übernahme aber nicht länger unbemerkt bliebe.

Schlüssel

Um sicherzustellen, dass die Signatur nicht gefälscht werden kann, besteht FSS aus einem Zweischlüsselsystem, wobei einer davon extern gesichert werden soll. Um dies möglichst komfortabel zu gestalten, können künftige Versionen von Systemd einen QR-Code erstellen, der über das Smartphone eingelesen werden kann, wie Entwickler Lennart Poettering in einem Beitrag auf Google+ ausführt.

Schon da

Die FSS-Absicherung von Systemd ist bereits in den Hauptentwicklungszweig der Software eingeflossen, wird also Teil der nächsten Release sein, und unter anderem auch bereits in Fedora 18 einfließen. Allerdings bleibt es dort vorerst optional, da sich Fedora vorerst noch nicht dazu durchringen konnte, Systemd auch die Logging-Agenden zu übertragen. (apo, derStandard.at, 21.08.12)

Share if you care
7 Postings
"Angreiferin"

So so.

Systemd ist für das Linuxökosystem ungefähr das,

... was genmanipulierter Monsanto-Mais für die peruvianische Landwirtschaft ist. Zitat des Slackware-Entwicklers Eric Hameleers zum Thema Systemd: "[...] systemd is essentially evil. It is invasive, extremely hostile to other environments, threatening to kill non-Linux ecosystems which have hal, udev, dbus, consolekit, polkit, udisks, upower and friends as dependencies. And every iteration of the software written by the Redhat employees who are responsible for hal, udev, consiolekit, polkit and now systemd are incompatible with previous releases, re-implementing their bad ideas with new bad ideas... basically proving that these Redhat employees must be declared unfit to work on the core of a Linux distro. (...)"

mfg,

Ein Slackware-User

Unnötig!

Bei mir rennt syslog-ng als relay daemon zu jeweils 2 Anderen Servern.
Alles was lokal im syslog ankommt, wird lokal gespeichert UND auch zu den 2 Servern verschlüsselt weitergeleitet.

Somit ist es nötig ALLE 3 Maschinen zu manipulieren.
Was zumindest bei der dritten nicht so einfach zu machen sein sollte. (außer es gibt einen fatalen Bug in sshd oder syslog-ng)

Nicht unnötig aber

nette Spielerei. Best practice ist auf jeden Fall das loggen auf ein zentrales Log Fault. Wird übrigens auch von vielen Audit Standards so gefordert.

Ich bezweifle dass viele welche Logs lokal horten ins stutzen kommen, wenn auf einmal das ganze Log weg ist (weil ja löschen lt. Artikel doch geht). Wer so geschärft ist, macht es derzeit eben schon durch zentrales Logging.

Aber ein Plus an Sicherheit ist dennoch nicht verkehrt, wenn denn die neue Funktion generell Sinn macht!

ein log fault ist ein fehler.
aber vielleicht ist er dann zumindest im log vault protokolliert

airbags in autos sind auch unnötig, ich fahr mit dem zug.

Und weil das bei dir so ist, und du das Maß aller Dinge bist, ist das unnötig.

Tut mir leid, aber das einzig Unnötige an der Sache ist dein Posting.

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.