- 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 »
Aucun commentaire pour le moment.