Los problemas de D-Bus en el escritorio Linux

• D-Bus es un bus para la comunicación entre aplicaciones; el concepto es útil, pero su implementación es muy deficiente y no estandarizada
• La documentación del estándar es incompleta e inconsistente, y las implementaciones reales no la siguen, lo que provoca una ruptura de compatibilidad
• Los fallos de seguridad también son graves: una app puede leer datos secretos de otra mientras el almacén está desbloqueado
• Como respuesta, el autor está desarrollando un nuevo sistema de bus llamado hyprtavern y un protocolo llamado hyprwire
• hyprtavern busca resolver los problemas estructurales de D-Bus mediante verificación estricta de tipos, gestión de permisos integrada y un almacén seguro de secretos (kv)

---

El concepto de D-Bus y sus límites

• D-Bus es un sistema que permite que aplicaciones y servicios expongan métodos y propiedades a través de un bus compartido y se llamen entre sí
  • Por ejemplo, si una app que ofrece un servicio meteorológico registra una API en el bus, otras apps pueden encontrarla y usarla
• Sin embargo, D-Bus tiene un diseño demasiado permisivo y poco estructurado, por lo que cualquier objeto puede registrar o invocar métodos arbitrarios
  • Esto provoca el efecto de “Garbage in, garbage out”

Confusión entre el estándar y las implementaciones

• La documentación del estándar de D-Bus está dispersa en varios lugares y existe en un estado incompleto y difícil de entender
  • Las implementaciones reales no la siguen o usan especificaciones distintas de forma arbitraria
• El autor explica que, mientras desarrollaba xdg-desktop-portal-hyprland, implementó la especificación de restore_token, pero
  todas las apps usaban el campo no oficial restore_data, por lo que no era compatible
• El tipo variant de D-Bus (a{sv}) permite transmitir datos arbitrarios y se señala como una causa principal de la ruptura de la consistencia del protocolo

Defectos en la estructura de seguridad

• En D-Bus no existe una gestión centralizada de permisos ni un mecanismo de denegación
  • Todas las apps pueden ver las llamadas de otras, y sin medidas de seguridad explícitas el acceso es ilimitado
• Los almacenes de secretos como gnome-keyring y kwallet también son estructuralmente débiles
  • Cuando el almacén está desbloqueado, cualquier app puede acceder a todos los datos secretos
  • El autor lo describe como “una broma de seguridad”

Nueva alternativa: hyprwire y hyprtavern

• Para resolver los problemas de D-Bus, el autor está desarrollando un nuevo sistema de bus llamado hyprtavern
  • hyprwire es un protocolo wire simple y consistente inspirado en el diseño de Wayland
    • Sus características son la imposición de tipos, conexiones rápidas y una estructura sencilla
  • hyprtavern tiene una estructura en la que las apps registran objetos basados en protocolos y pueden descubrirse entre sí
    • Ofrece sistema de permisos integrado, cumplimiento estricto de protocolos, API simplificada y seguridad por defecto

hyprtavern-kv (almacén seguro de clave-valor)

• Es un protocolo base (core) que reemplaza la Secrets API de D-Bus
  • Los secretos que registra una app solo pueden ser leídos por esa app, y no pueden enumerarse
  • También se planea control de acceso basado en ID para apps de Flatpak, Snap y AppImage
  • Siempre se almacenan cifrados y, si se configura una contraseña, se puede garantizar seguridad real
  • Todas las apps pueden usar de forma predeterminada una función segura de almacenamiento de secretos

Estado de desarrollo y planes a futuro

• hyprtavern aún está en una etapa temprana de desarrollo y se planea usar internamente más adelante en Hyprland 0.54
• Se espera que la adopción inicial sea limitada, pero es posible una transición gradual
  • A diferencia de D-Bus, se pueden ejecutar varios buses de sesión en paralelo, por lo que también es posible escribir un proxy de compatibilidad
• Está escrito en C++, y también pueden implementarse con facilidad bindings para Rust, Go y Python
• El autor enfatiza que “D-Bus no puede arreglarse en su base y debe rediseñarse por completo”

Resumen del FAQ

• Frente a la crítica de “reinventar la rueda”, menciona que el diseño fundamental de D-Bus está roto y hace inevitable un rediseño
• La documentación está actualmente en estado WIP (en progreso) y se publicará cuando esté terminada
• La razón para no usar Wayland es que no es adecuado para IPC de propósito general
• Es posible escribir un proxy compatible con D-Bus (hyprtavern-dbus-notification-proxy)
• La razón para usar C++ en lugar de Rust es que el lenguaje principal del desarrollador es C++
• En términos de seguridad, los ataques con LD_PRELOAD no pueden bloquearse por completo, pero la estructura eleva la dificultad del ataque y la posibilidad de detectarlo

Conclusión

• Se señala que D-Bus es un cuello de botella en el ecosistema de escritorio Linux debido a su falta de estandarización, seguridad y consistencia
• hyprtavern se está desarrollando como un bus IPC moderno y seguro para reemplazarlo, y
  se espera una adopción gradual centrada en el ecosistema de Hyprland
• El objetivo es “hacer más agradable el espacio de usuario (userspace)”

[GN⁺]

Opiniones de Hacker News

• Viendo la polémica por la vulnerabilidad de acceso al almacén de secretos de GNOME, da risa que el equipo de GNOME negara el problema basándose en el modelo de seguridad de que “las apps no confiables no pueden comunicarse con el servicio de secretos”
  GNOME de verdad parece un proyecto manejado por un circo de payasos

  • Es irónico que Wayland bloquee la intercepción de eventos de entrada por motivos de seguridad, pero deje intacto un problema así
  • Yo pensaba en el almacén de secretos como “datos que no deberían guardarse en texto plano en disco”. Si quieres aislamiento entre apps, lo correcto es usar una máquina virtual
  • Es normal que un programa ejecutándose con permisos de usuario pueda acceder a los datos del mismo usuario. Si eso fuera una vulnerabilidad, entonces Linux entero estaría roto. En ese sentido, xkcd 1200 es la analogía perfecta
  • Al final, parece uno de esos casos que terminan en “comportamiento intencional, no se arregla, discusión bloqueada”
  • Hoy en día, gracias a la IA, ya podemos lanzar todo el código a la nube y auditarlo nosotros mismos, así que ahora todos podremos usar solo software confiable /s

• Como alguien dijo que iba a “hacer un bus nuevo desde cero”, propuse reutilizar Binder, que ya está desplegado en miles de millones de dispositivos
  Binder es el IPC central de Android, con muchos más desarrolladores y código ya bastante probado

  • Si construyes un sistema nuevo sobre Binder, obtienes una base mucho más sólida. Además, Google recientemente implementó Binder para el kernel en Rust y lo fusionó
    Artículos relacionados: LWN, lista de correo de Rust-for-Linux
  • Aun así, fuera de Android casi no hay implementaciones de Binder en espacio de usuario
  • Busqué “BSD Binder” y “Windows Binder”, pero no salió nada. Supongo que eso de “serious OS” era una broma
  • Me pregunto si Binder realmente es mejor que D-Bus. Me gustaría saber en qué aspectos lo sería
  • Tal vez algún día Binder llegue también al escritorio Linux. Junto con Android

• Tenía expectativas por Hyprwire y Hyprtavern, pero casi no hay documentación ni pruebas
  Es una lástima, porque proyectos así podrían haber sido un buen punto de partida

  • Parece que el desarrollador está en época de exámenes finales de la universidad
  • El texto también menciona varias veces que “todavía se está preparando”, así que pienso esperar a ver cómo queda cuando esté terminado

• Los desarrolladores de OpenWrt ya habían creado hace mucho una alternativa llamada ubus
  Referencias: documentación de ubus, comparación ubus vs dbus
  Aun así, casi no tiene modelo de seguridad, y por las características de OpenWrt eso tiene sentido

• Uno de los problemas de D-Bus son las vulnerabilidades que surgen cuando las extensiones del navegador se comunican con GNOME/KDE
  Con solo visitar un sitio web era posible saturar una API de D-Bus y congelar el escritorio
  Si eres investigador de seguridad, D-Bus de verdad es un área que vale la pena explorar

  • Me pregunto qué significa exactamente que “un sitio web se integra con GNOME o KDE”
  • Este tipo de problema no ocurre en un entorno VM aislado

• D-Bus es lo más cercano que tiene el escritorio Linux a XPC, COM y Android IPC
  Pero por la fragmentación del escritorio es difícil construir una pila de desarrollo unificada
  Lo que haces para GNOME no sirve en KDE, y XFCE o Sway van por otro lado

  • KDE antes usaba su propio IPC llamado DCOP, pero ahora fue reemplazado por D-Bus
  • D-Bus ya tiene más de 20 años, así que necesita un reinicio. Pero para que un IPC nuevo tenga éxito, importa más la influencia social que la tecnología
  • KDE también tuvo KParts, parecido a COM
  • La fragmentación al final es una consecuencia natural de que existan distintos casos de uso

• Apenas me entero de que almacenes de secretos como KWallet o GNOME Keyring en la práctica quedan accesibles para cualquier app una vez desbloqueados
  Revisándolo con la GUI de seahorse, lo que vi eran sobre todo claves relacionadas con Chromium o tokens de cuenta de JetBrains
  No había contraseñas en texto plano, pero me deja pensando que una app maliciosa podría sacar algo más si escarba en los datos de Chromium

  • De todos modos, si no introduces la contraseña cada vez, inevitablemente tiene que existir en texto plano en memoria
    Si el sistema no te notifica cuando alguien accede, entonces da un poco igual qué software lo administre

• Está la duda de “¿por qué hace falta un protocolo de bus de propósito general?”
  Sobre un Unix domain socket bastaría con usar HTTP o un protocolo simple en JSON
  Ya tienes manejo de permisos, reenvío por SSH, montajes de contenedores y demás
  D-Bus tiene una estructura compleja con servicios, interfaces, rutas, métodos, etc., pero aun así la identificación de mensajes es incompleta y necesitas conocer los detalles del protocolo de cada app
  Al final, hasta el manejo de proxies se vuelve difícil; es un sistema excesivamente complejo

• El diseño de D-Bus parece un ejemplo de la ley de la aleatoriedad, donde “la mejor solución no necesariamente es la que se elige”
  Como pasa con React: hay incontables frameworks mejores, pero quedan enterrados por no ser conocidos

  • Este fenómeno muchas veces ocurre porque la gente evalúa las cosas sin entender del todo el problema
  • D-Bus despegó gracias a la relación entre GNOME y Red Hat
  • En realidad no existe una solución “superior”; cada una ocupa un espacio distinto de trade-offs. Hay que cuidarse de menospreciar el esfuerzo ajeno
  • La mayoría del open source la hacen voluntarios. Unas pocas personas invierten miles de horas en desarrollarlo, así que es natural que ellas decidan la dirección. En una estructura así, las decisiones raras son inevitables
  • Como dice aquello de “cuanto peor, mejor”, la realidad es que el proceso de selección en sí suele darse de la manera más ineficiente posible

• Que GNOME respondiera a un reporte de vulnerabilidad mencionando las restricciones de acceso del sandbox de Flatpak me hizo recordar este viejo post del blog de Microsoft
  Además, no entiendo por qué subieron la cita solo como captura de pantalla, impidiendo copiarla

  • Wayland bloquea las capturas de pantalla sin privilegios de root, pero D-Bus está abierto con mentalidad YOLO