Les problèmes de D-Bus sur le bureau Linux

 (blog.vaxry.net)
1 points par GN⁺ 2025-12-17 | 1 commentaires | Partager sur WhatsApp
  • D-Bus est un bus de communication inter-applications dont le concept est utile, mais dont l’implémentation est très médiocre et non standardisée
  • La documentation standard est incomplète et incohérente, et les implémentations réelles ne la respectent pas, ce qui provoque un effondrement de la compatibilité
  • Les failles de sécurité sont aussi graves : une application peut lire les données secrètes d’une autre lorsque le coffre est déverrouillé
  • En réponse, l’auteur développe un nouveau système de bus, hyprtavern, et un protocole, hyprwire
  • hyprtavern cherche à corriger les problèmes structurels de D-Bus grâce à une vérification stricte des types, une gestion intégrée des permissions, un coffre de secrets sécurisé (kv), etc.

Le concept de D-Bus et ses limites

  • D-Bus est un système qui permet aux applications et services d’exposer des méthodes et propriétés sur un bus partagé et de s’appeler mutuellement
    • Par exemple, si une application qui fournit un service météo enregistre une API sur le bus, d’autres applications peuvent la découvrir et l’utiliser
  • Mais D-Bus souffre d’une conception trop permissive et peu structurée, qui permet d’enregistrer ou d’appeler n’importe quel objet avec des méthodes arbitraires
    • D’où un effet « Garbage in, garbage out »

La confusion entre documentation standard et implémentations

  • La documentation standard de D-Bus est éparpillée en plusieurs endroits, inachevée et difficile à interpréter
    • En pratique, les implémentations ne la suivent pas, ou utilisent arbitrairement des spécifications différentes
  • L’auteur explique qu’en développant xdg-desktop-portal-hyprland, il a implémenté la spécification restore_token,
    mais que toutes les applications utilisaient à la place le champ non officiel restore_data, rendant l’ensemble incompatible
  • Le type variant (a{sv}) de D-Bus, qui autorise le transport de données arbitraires, est désigné comme une cause majeure de rupture de cohérence des protocoles

Les défauts de l’architecture de sécurité

  • D-Bus ne dispose ni de gestion centralisée des permissions ni de mécanisme de refus
    • Toutes les applications peuvent voir les appels des autres et, sans protection explicite, l’accès est illimité
  • Des coffres de secrets comme gnome-keyring ou kwallet sont eux aussi structurellement fragiles
    • Une fois le coffre déverrouillé, toutes les applications peuvent accéder à toutes les données secrètes
    • L’auteur qualifie cela de « plaisanterie en matière de sécurité »

Une nouvelle alternative : hyprwire et hyprtavern

  • Pour résoudre les problèmes de D-Bus, l’auteur développe un nouveau système de bus appelé hyprtavern
    • hyprwire est un protocole wire simple et cohérent inspiré de la conception de Wayland
      • Il se caractérise par l’imposition des types, des connexions rapides et une structure simple
    • hyprtavern repose sur une architecture où les applications enregistrent des objets basés sur des protocoles et se découvrent mutuellement
      • Il fournit un système de permissions intégré, un respect strict des protocoles, une API simplifiée et des paramètres de sécurité par défaut

hyprtavern-kv (coffre clé-valeur sécurisé)

  • Un protocole core destiné à remplacer la Secrets API de D-Bus
    • Les secrets enregistrés par une application ne peuvent être lus que par cette application et ne peuvent pas être énumérés
    • Un contrôle d’accès fondé sur l’ID pour les applications Flatpak, Snap et AppImage est également prévu
    • Les données sont toujours stockées chiffrées et, avec un mot de passe défini, il est possible d’obtenir de véritables garanties de sécurité
    • Toutes les applications peuvent bénéficier par défaut d’un coffre de secrets sécurisé

État du développement et suite prévue

  • hyprtavern en est encore aux premiers stades du développement, avec une utilisation interne prévue plus tard dans Hyprland 0.54
  • L’adoption initiale devrait rester limitée, mais une transition progressive est possible
    • Contrairement à D-Bus, plusieurs bus de session peuvent fonctionner en parallèle, ce qui permet aussi d’écrire des proxys de compatibilité
  • Le projet est écrit en C++, et des bindings Rust, Go et Python peuvent aussi être mis en place facilement
  • L’auteur insiste sur le fait que « D-Bus ne peut pas être réparé à la racine et doit être entièrement repensé »

Résumé de la FAQ

  • Face à la critique du « réinvention de la roue », l’auteur répond que la conception fondamentale de D-Bus est cassée, rendant une refonte inévitable
  • La documentation est actuellement en WIP (travail en cours) et sera publiée une fois terminée
  • Wayland n’a pas été utilisé car il n’est pas adapté à un usage IPC généraliste
  • Il est possible d’écrire un proxy compatible D-Bus (hyprtavern-dbus-notification-proxy)
  • Le choix du C++ plutôt que Rust s’explique par le fait que le C++ est le langage principal du développeur
  • Sur le plan de la sécurité, les attaques LD_PRELOAD sont difficiles à bloquer complètement, mais l’architecture augmente le coût de l’attaque et les chances de détection

Conclusion

  • D-Bus est présenté comme un goulot d’étranglement de l’écosystème bureau Linux en raison de son caractère non standard, peu sûr et incohérent
  • hyprtavern est en cours de développement comme bus IPC moderne et sécurisé pour le remplacer,
    avec une adoption progressive attendue autour de l’écosystème Hyprland
  • L’objectif est de « rendre l’espace utilisateur (userspace) plus agréable »

À lire aussi

1 commentaires

 
GN⁺ 2025-12-17
Avis Hacker News

  • En voyant la controverse autour de la faille d’accès au stockage de secrets de GNOME, j’ai trouvé ridicule que l’équipe GNOME nie le problème en s’appuyant sur le modèle de sécurité selon lequel « les applis non fiables ne peuvent pas communiquer avec le service de secrets »
    On dirait vraiment que GNOME est un projet géré par des clowns

    • Il y a une vraie ironie à voir Wayland bloquer l’interception des événements d’entrée au nom de la sécurité, tout en laissant ce genre de problème intact
    • Je voyais le stockage de secrets comme des « données qu’il ne faut pas enregistrer en clair sur le disque ». Si on veut une isolation entre applis, il faut utiliser une machine virtuelle
    • Il est normal qu’un programme exécuté avec les droits d’un utilisateur puisse accéder aux données du même utilisateur. Si c’est une faille, alors Linux tout entier est compromis. À ce sujet, xkcd 1200 est une analogie parfaite
    • Au final, ça ressemble à un problème qui va se terminer en « comportement intentionnel, pas de correctif, discussion verrouillée »
    • De nos jours, grâce à l’IA, on peut balancer tout le code dans le cloud pour l’auditer soi-même, donc on peut désormais tous n’utiliser que des logiciels dignes de confiance /s

  • Quelqu’un disait vouloir « construire lui-même un nouveau bus », alors j’ai suggéré de réutiliser Binder, déjà déployé sur des milliards d’appareils
    Binder est l’IPC central d’Android, avec bien plus de développeurs et un code déjà éprouvé

    • Construire un nouveau système au-dessus de Binder permettrait de partir sur une base bien plus solide. En plus, Google a récemment implémenté Binder pour le noyau en Rust et l’a fait merger
      Article connexe : LWN, liste de diffusion Rust-for-Linux
    • En revanche, il n’existe pratiquement pas d’implémentations espace utilisateur de Binder hors Android
    • J’ai cherché « BSD Binder » et « Windows Binder », mais je n’ai rien trouvé. L’expression « serious OS » était sans doute une blague
    • Je me demande si Binder est vraiment meilleur que D-Bus. J’aimerais savoir sur quels points il est supérieur
    • Peut-être qu’un jour, Binder arrivera aussi sur le desktop Linux. Avec Android

  • J’attendais Hyprwire et Hyprtavern, mais il n’y a presque pas de documentation ni de tests
    C’est dommage, ces projets auraient pu constituer un bon point de départ

    • Le développeur est sans doute en pleine période d’examens de fin d’études à l’université
    • L’article précise plusieurs fois que « ce n’est pas encore prêt », donc je vais attendre de voir une fois le travail terminé

  • Les développeurs d’OpenWrt ont déjà créé il y a longtemps une alternative appelée ubus
    Référence : documentation ubus, comparaison ubus vs dbus
    En revanche, le modèle de sécurité est quasiment inexistant, ce qui se comprend vu la nature d’OpenWrt

  • L’un des problèmes de D-Bus, ce sont les failles provoquées par les extensions de navigateur qui communiquent avec GNOME/KDE
    Une simple visite de site web pouvait suffire à saturer des API D-Bus et à figer le desktop
    Pour un chercheur en sécurité, D-Bus est vraiment un domaine qui mérite d’être exploré

    • Je me demande ce que signifie exactement « un site web s’intègre à GNOME ou KDE »
    • Ce genre de problème ne se produit pas dans un environnement VM indépendant

  • D-Bus est ce qui se rapproche le plus de XPC, COM et de l’IPC d’Android sur le desktop Linux
    Mais la fragmentation du desktop rend difficile la création d’une pile de développement unifiée
    Ce qui est conçu pour GNOME ne sert à rien sur KDE, et XFCE ou Sway partent encore dans une autre direction

    • KDE utilisait autrefois son propre IPC, DCOP, mais l’a remplacé par D-Bus
    • D-Bus a plus de 20 ans, il a donc besoin d’un redémarrage. Mais pour qu’un nouvel IPC réussisse, l’influence sociale compte plus que la technique
    • KDE avait aussi KParts, assez proche de COM
    • La fragmentation est au fond un résultat naturel de la diversité des cas d’usage

  • Je découvre seulement maintenant que des coffres de secrets comme KWallet ou GNOME Keyring sont en pratique accessibles à toutes les applis tant qu’ils sont déverrouillés
    En vérifiant via l’interface graphique seahorse, je n’y ai trouvé pour l’essentiel que des clés liées à Chromium ou des jetons de compte JetBrains
    Il n’y a pas de mots de passe en clair, mais je me dis qu’une appli malveillante pourrait peut-être trouver davantage en fouillant dans les données de Chromium

    • De toute façon, si l’on ne ressaisit pas son mot de passe, il doit bien exister en clair quelque part en mémoire
      Si le système ne signale pas les accès, peu importe finalement quel logiciel gère cela

  • Je me demande : « pourquoi a-t-on besoin d’un protocole de bus générique ? »
    Utiliser HTTP ou un simple protocole JSON sur un socket de domaine Unix devrait suffire
    Gestion des permissions, redirection SSH, montages de conteneurs : tout cela est déjà pris en charge
    D-Bus a une structure compliquée avec ses services, interfaces, chemins et méthodes, mais l’identification des messages reste incomplète, et il faut connaître les détails du protocole propre à chaque appli
    Au final, même la mise en proxy devient difficile, et l’ensemble est inutilement complexe

  • La conception de D-Bus me semble illustrer la loi de l’arbitraire : la meilleure solution n’est pas forcément celle qui est choisie
    Comme il existe d’innombrables frameworks meilleurs que React, mais qui restent inconnus et sombrent dans l’oubli

    • Ce phénomène vient souvent du fait que les gens évaluent les choses sans comprendre complètement le problème
    • Si D-Bus a percé, c’est grâce au lien avec GNOME et Red Hat
    • En réalité, il n’existe pas de solution « meilleure » dans l’absolu ; il n’y a que des espaces de compromis différents. Il faut éviter de mépriser le travail des autres
    • L’open source est en grande partie fait par des bénévoles. Quand quelques personnes investissent des milliers d’heures dans un projet, il est naturel qu’elles en définissent l’orientation. Dans ce type de structure, des décisions étranges sont inévitables
    • Comme le dit l’expression « worse is better », le processus de sélection lui-même se déroule en pratique de la manière la plus inefficace possible

  • Le fait que GNOME ait répondu à un signalement de faille en invoquant les restrictions d’accès du sandbox Flatpak m’a rappelé cet ancien billet de blog Microsoft
    Et je ne comprends vraiment pas pourquoi ils ont publié la citation uniquement sous forme de capture d’écran, empêchant toute copie

    • Wayland bloque les captures d’écran sans privilèges root, mais D-Bus reste ouvert en mode YOLO