Die Probleme von D-Bus auf dem Linux-Desktop

• D-Bus ist ein Bus für die Kommunikation zwischen Anwendungen; das Konzept ist nützlich, aber die Implementierung ist äußerst mangelhaft und nicht standardkonform
• Die Standarddokumentation ist unvollständig und inkonsistent, und die tatsächlichen Implementierungen halten sich nicht daran, was zu einem Zusammenbruch der Kompatibilität führt
• Auch Sicherheitslücken sind gravierend: Apps können im entsperrten Zustand geheime Daten anderer Apps lesen
• Als Reaktion darauf entwickelt der Autor ein neues Bussystem namens hyprtavern und ein Protokoll namens hyprwire
• hyprtavern soll die strukturellen Probleme von D-Bus durch strikte Typprüfung, integrierte Rechteverwaltung, einen sicheren Secret-Store (kv) usw. lösen

---

Das Konzept von D-Bus und seine Grenzen

• D-Bus ist ein System, mit dem Anwendungen und Dienste über einen gemeinsamen Bus Methoden und Eigenschaften bereitstellen und gegenseitig aufrufen können
  • Wenn zum Beispiel eine App, die einen Wetterdienst anbietet, eine API am Bus registriert, können andere Apps sie finden und verwenden
• Wegen seines zu großzügigen und unstrukturierten Designs kann D-Bus jedoch beliebige Objekte mit beliebigen Methoden registrieren und aufrufen
  • Dadurch entsteht der Effekt „Garbage in, garbage out“

Verwirrung bei Standarddokumentation und Implementierungen

• Die Standarddokumentation von D-Bus ist über mehrere Stellen verstreut und in unvollständiger, schwer verständlicher Form vorhanden
  • Reale Implementierungen halten sich entweder nicht daran oder verwenden willkürlich voneinander abweichende Spezifikationen
• Der Autor erklärt, dass er bei der Entwicklung von xdg-desktop-portal-hyprland die Spezifikation für restore_token implementiert habe,
  alle Apps jedoch das inoffizielle Feld restore_data verwendeten und es deshalb zu Inkompatibilitäten kam
• Der Variant-Typ (a{sv}) von D-Bus erlaubt die Übertragung beliebiger Daten und wird als Hauptursache für die Auflösung der Protokollkonsistenz genannt

Mängel in der Sicherheitsarchitektur

• In D-Bus fehlt eine zentralisierte Rechteverwaltung oder ein Mechanismus zum Verweigern von Zugriffen
  • Alle Apps können die Aufrufe anderer Apps sehen und haben ohne explizite Sicherheitsmaßnahmen unbegrenzten Zugriff
• Auch Secret-Stores wie gnome-keyring, kwallet sind strukturell schwach
  • Sobald der Store entsperrt ist, können alle Apps auf alle geheimen Daten zugreifen
  • Der Autor bezeichnet das als „ein sicherheitstechnischer Witz“

Die neue Alternative: hyprwire und hyprtavern

• Um die Probleme von D-Bus zu lösen, entwickelt der Autor ein neues Bussystem namens hyprtavern
  • hyprwire ist ein von Wayland inspiriertes knappes und konsistentes Wire-Protokoll
    • Es zeichnet sich durch erzwungene Typen, schnelle Verbindungen und eine einfache Struktur aus
  • hyprtavern basiert auf einer Struktur, in der Apps protokollbasierte Objekte registrieren und gegenseitig entdecken
    • Es bietet ein integriertes Berechtigungssystem, strikte Protokolltreue, eine vereinfachte API und sichere Voreinstellungen

hyprtavern-kv (sicherer Key-Value-Store)

• Ein Core-Protokoll, das die Secrets API von D-Bus ersetzen soll
  • Von einer App registrierte Secrets können nur von dieser App gelesen werden und sind nicht auflistbar
  • Auch eine ID-basierte Zugriffskontrolle für Flatpak-, Snap- und AppImage-Apps ist geplant
  • Daten werden immer verschlüsselt gespeichert; mit gesetztem Passwort ist echte Sicherheit möglich
  • Alle Apps können die Funktion eines sicheren Secret-Stores standardmäßig nutzen

Entwicklungsstand und weitere Pläne

• hyprtavern befindet sich noch in einer frühen Entwicklungsphase und soll künftig intern in Hyprland Version 0.54 genutzt werden
• Die anfängliche Verbreitung dürfte begrenzt sein, doch ein schrittweiser Übergang ist möglich
  • Anders als bei D-Bus können mehrere Session-Busse parallel betrieben werden, wodurch sich auch Kompatibilitäts-Proxys schreiben lassen
• Das Projekt ist in C++ geschrieben, Bindings für Rust, Go und Python lassen sich jedoch leicht umsetzen
• Der Autor betont: „D-Bus lässt sich grundlegend nicht reparieren und muss komplett neu entworfen werden.“

FAQ-Zusammenfassung

• Zur Kritik, man „erfinde das Rad neu“, sagt der Autor, dass das Grunddesign von D-Bus kaputt ist und ein Redesign unvermeidlich sei
• Die Dokumentation ist derzeit WIP (in Arbeit) und soll nach Fertigstellung veröffentlicht werden
• Wayland wurde nicht verwendet, weil es für allgemeine IPC-Zwecke ungeeignet sei
• Ein D-Bus-Kompatibilitäts-Proxy (hyprtavern-dbus-notification-proxy) ist möglich
• Warum C++ statt Rust verwendet wurde: weil C++ die Hauptsprache des Entwicklers ist
• In Bezug auf Sicherheit lassen sich LD_PRELOAD-Angriffe nicht vollständig verhindern, aber die Struktur erhöht die Angriffshürde und verbessert die Erkennbarkeit

Fazit

• D-Bus gilt wegen fehlender Standardisierung, mangelnder Sicherheit und Inkonsistenz als Engpass im Linux-Desktop-Ökosystem
• hyprtavern wird als moderner und sicherer IPC-Bus entwickelt, der D-Bus ersetzen soll,
  voraussichtlich mit schrittweiser Einführung rund um das Hyprland-Ökosystem
• Das Ziel ist, „den Userspace angenehmer zu machen“

[GN⁺]

Hacker-News-Kommentare

• Wenn man die Kontroverse um die Schwachstelle beim Zugriff auf den Secret Store von GNOME sieht, ist es schon lächerlich, dass das GNOME-Team das Problem mit Verweis auf sein Sicherheitsmodell abgestritten hat: „Nicht vertrauenswürdige Apps können nicht mit dem Secret Service kommunizieren“
  GNOME wirkt wirklich wie ein Projekt, das von Clowns betrieben wird

  • Ironisch ist, dass Wayland aus Sicherheitsgründen das Abfangen von Eingabe-Events verhindert, so ein Problem aber einfach bestehen lässt
  • Ich habe den Secret Store eher als „Daten, die nicht im Klartext auf der Festplatte liegen sollten“ verstanden. Wenn man Isolation zwischen Apps will, sollte man virtuelle Maschinen verwenden
  • Dass Programme, die mit Benutzerrechten laufen, auf Daten desselben Benutzers zugreifen können, ist selbstverständlich. Wenn das eine Schwachstelle wäre, wäre ganz Linux kompromittiert. Dazu passt xkcd 1200 perfekt als Analogie
  • Am Ende wird das wohl wieder bei „funktioniert wie beabsichtigt, wird nicht behoben, Diskussion geschlossen“ landen
  • Heute kann man dank AI ja den gesamten Code in die Cloud werfen und selbst auditieren, also können jetzt alle nur noch Software verwenden, der sie vertrauen können /s

• Jemand meinte, er wolle „einen neuen Bus selbst bauen“, und ich habe vorgeschlagen, stattdessen Binder wiederzuverwenden, das bereits auf Milliarden Geräten ausgeliefert wird
  Binder ist die zentrale IPC von Android und hat deutlich mehr Entwickler sowie erprobten Code hinter sich

  • Wenn man ein neues System auf Binder aufbaut, bekommt man eine wesentlich robustere Basis. Außerdem hat Google kürzlich eine Binder-Implementierung für den Kernel in Rust umgesetzt und gemergt
    Verwandte Artikel: LWN, Rust-for-Linux-Mailingliste
  • Außerhalb von Android gibt es allerdings kaum Binder-Userspace-Implementierungen
  • Ich habe nach „BSD Binder“ oder „Windows Binder“ gesucht, aber nichts gefunden. Vermutlich war die Formulierung „serious OS“ als Witz gemeint
  • Ich frage mich, ob Binder wirklich besser ist als D-Bus. Mich würde interessieren, worin genau die Vorteile liegen
  • Vielleicht kommt Binder eines Tages auch auf den Linux-Desktop. Zusammen mit Android

• Ich hatte auf Hyprwire und Hyprtavern gehofft, aber es gibt fast keine Dokumentation oder Tests
  Schade, denn solche Projekte hätten ein guter Ausgangspunkt sein können

  • Der Entwickler scheint gerade in der Prüfungsphase zum Studienabschluss zu sein
  • Im Artikel wird auch mehrfach erwähnt, dass es „noch in Arbeit“ ist, also warte ich erst einmal ab, bis es fertig ist

• Die OpenWrt-Entwickler haben schon vor langer Zeit mit ubus eine Alternative gebaut
  Siehe: ubus-Dokumentation, Vergleich ubus vs dbus
  Ein Sicherheitsmodell gibt es allerdings kaum, was bei OpenWrt auch nachvollziehbare Gründe hat

• Eines der Probleme von D-Bus sind Schwachstellen, die dadurch entstehen, dass Browser-Erweiterungen mit GNOME/KDE kommunizieren
  Schon allein der Besuch einer Website konnte dazu führen, dass D-Bus-APIs geflutet wurden und der Desktop hängen blieb
  Für Sicherheitsforscher ist D-Bus wirklich ein Bereich, den es sich zu untersuchen lohnt

  • Ich frage mich, was es überhaupt bedeutet, dass „eine Website sich in GNOME oder KDE integriert“
  • Solche Probleme treten in einer eigenständigen VM-Umgebung nicht auf

• D-Bus ist auf dem Linux-Desktop das, was XPC, COM und Android IPC am nächsten kommt
  Wegen der Fragmentierung des Desktops ist es aber schwer, einen einheitlichen Entwicklungs-Stack zu schaffen
  Was für GNOME gebaut wurde, ist unter KDE nutzlos, und XFCE oder Sway machen wieder ihr eigenes Ding

  • KDE hatte früher eine eigene IPC namens DCOP, diese wurde inzwischen aber durch D-Bus ersetzt
  • D-Bus ist über 20 Jahre alt und braucht jetzt einen Neustart. Damit sich eine neue IPC durchsetzt, ist aber sozialer Einfluss wichtiger als Technik
  • KDE hatte auch KParts, das COM ähnelt
  • Fragmentierung ist letztlich ein natürliches Ergebnis daraus, dass es verschiedene Anwendungsfälle gibt

• Mir war zum ersten Mal klar, dass Secret Stores wie KWallet oder GNOME Keyring im entsperrten Zustand faktisch für alle Apps zugänglich sind
  Als ich das in der seahorse-GUI nachgesehen habe, waren dort überwiegend Chromium-bezogene Schlüssel oder JetBrains-Account-Tokens
  Keine Passwörter im Klartext, aber wenn eine bösartige App tiefer in die Chromium-Daten eintaucht, könnte sie vielleicht noch mehr finden

  • Wenn man das Passwort ohnehin nicht eingibt, muss es zwangsläufig im Klartext im Speicher existieren
    Wenn das System beim Zugriff keine Benachrichtigung anzeigt, macht es keinen großen Unterschied, welche Software das verwaltet

• Ich frage mich: „Warum braucht man überhaupt ein allgemeines Bus-Protokoll?“
  HTTP oder ein einfaches JSON-Protokoll über Unix Domain Sockets würde völlig reichen
  Rechtemanagement, SSH-Forwarding, Container-Mounts usw. werden ebenfalls unterstützt
  D-Bus hat mit Services, Interfaces, Pfaden und Methoden eine komplexe Struktur, identifiziert Nachrichten aber trotzdem nur unvollständig, und man muss die Protokolldetails jeder App kennen
  Letztlich ist auch Proxying schwierig, und das ganze System ist unnötig komplex

• Das Design von D-Bus wirkt wie ein Beispiel für das Gesetz der Willkür, wonach nicht unbedingt die beste Lösung ausgewählt wird
  So wie es unzählige Frameworks gibt, die besser sind als React, aber unbekannt bleiben und untergehen

  • So etwas passiert oft, weil Menschen Dinge bewerten, ohne das Problem vollständig zu verstehen
  • Dass D-Bus groß geworden ist, liegt an der Verbindung zu GNOME und Red Hat
  • Eigentlich gibt es keine „beste“ Lösung, sondern nur unterschiedliche Trade-off-Räume. Man sollte aufpassen, die Arbeit anderer nicht geringschätzig abzutun
  • Open Source wird größtenteils von Freiwilligen entwickelt. Einige wenige investieren Tausende Stunden, daher ist es nur natürlich, dass sie die Richtung bestimmen. In so einer Struktur entstehen zwangsläufig auch merkwürdige Entscheidungen
  • Wie bei „worse is better“ läuft auch der Auswahlprozess selbst in der Realität oft auf die ineffizienteste Weise ab

• Dass GNOME bei der Erwiderung auf die Schwachstellenmeldung auf die Zugriffsbeschränkungen der Flatpak-Sandbox verwiesen hat, erinnerte mich an diesen früheren Microsoft-Blogbeitrag
  Außerdem kann ich wirklich nicht verstehen, warum das Zitat nur als Screenshot gepostet wurde, sodass man es nicht einmal kopieren kann

  • Wayland verhindert Screenshots ohne Root-Rechte, aber D-Bus ist mit YOLO-Mentalität offen