Os problemas do D-Bus no desktop Linux

• D-Bus é um barramento para comunicação entre aplicativos; a ideia é útil, mas a implementação é muito fraca e não padronizada
• A documentação do padrão é incompleta e inconsistente, e as implementações reais não a seguem, causando quebra de compatibilidade
• As falhas de segurança também são graves: um app pode ler dados secretos de outro app quando ele está desbloqueado
• Em resposta a isso, o autor está desenvolvendo um novo sistema de barramento, o hyprtavern, e o protocolo hyprwire
• O hyprtavern busca resolver os problemas estruturais do D-Bus com verificação estrita de tipos, gerenciamento de permissões embutido e armazenamento seguro de segredos (kv), entre outros recursos

---

Conceito e limites do D-Bus

• O D-Bus é um sistema que permite que aplicativos e serviços exponham métodos e propriedades por meio de um barramento compartilhado (bus) e os invoquem mutuamente
  • Por exemplo, se um app que oferece um serviço de clima registrar uma API no barramento, outros apps podem encontrá-la e usá-la
• Porém, o D-Bus tem um projeto permissivo demais e pouco estruturado, permitindo registrar e chamar métodos arbitrários em qualquer objeto
  • Isso leva ao efeito “Garbage in, garbage out”

A confusão entre documentação e implementações

• A documentação do padrão D-Bus está espalhada em vários lugares e existe de forma incompleta e difícil de entender
  • As implementações reais ou não a seguem, ou usam especificações diferentes de forma arbitrária
• O autor explica que, durante o desenvolvimento do xdg-desktop-portal-hyprland, implementou a especificação de restore_token, mas
  todos os apps usavam o campo não oficial restore_data, o que tornou tudo incompatível
• O tipo variant (a{sv}) do D-Bus permite transmitir dados arbitrários, sendo apontado como uma das principais causas da quebra de consistência dos protocolos

Falhas na estrutura de segurança

• No D-Bus, não existe gerenciamento centralizado de permissões nem mecanismo de negação
  • Todos os apps podem ver as chamadas de outros apps e, sem mecanismos de segurança explícitos, o acesso é ilimitado
• Armazenamentos de segredos como gnome-keyring e kwallet também são estruturalmente frágeis
  • Quando o armazenamento é desbloqueado, todos os apps podem acessar todos os dados secretos
  • O autor descreve isso como “uma piada de segurança”

A nova alternativa: hyprwire e hyprtavern

• Para resolver os problemas do D-Bus, o autor está desenvolvendo um novo sistema de barramento chamado hyprtavern
  • O hyprwire é um protocolo wire conciso e consistente inspirado no design do Wayland
    • Suas características incluem imposição de tipos, conexão rápida e estrutura simples
  • O hyprtavern usa uma estrutura em que os apps registram objetos baseados em protocolo e se descobrem mutuamente
    • Ele oferece sistema de permissões embutido, aderência estrita a protocolos, API simplificada e segurança por padrão

hyprtavern-kv (armazenamento seguro de chave-valor)

• Um protocolo central (core) que substitui a Secrets API do D-Bus
  • Os segredos registrados por um app só podem ser lidos por esse próprio app e não podem ser enumerados
  • Também há planos para controle de acesso baseado em ID para apps Flatpak, Snap e AppImage
  • Os dados são sempre armazenados criptografados e, com senha configurada, é possível garantir segurança real
  • Todos os apps poderão usar por padrão um armazenamento seguro de segredos

Estado do desenvolvimento e planos futuros

• O hyprtavern ainda está nos estágios iniciais de desenvolvimento e deverá ser usado internamente no futuro na versão 0.54 do Hyprland
• A adoção inicial deve ser limitada, mas uma transição gradual é possível
  • Ao contrário do D-Bus, é possível executar vários barramentos de sessão em paralelo, o que também permite escrever proxies de compatibilidade
• Foi escrito em C++, e bindings para Rust, Go e Python também podem ser implementados com facilidade
• O autor enfatiza que “o D-Bus não pode ser consertado na raiz; ele precisa ser completamente redesenhado”

Resumo do FAQ

• Sobre a crítica de “reinventar a roda”, ele diz que o projeto fundamental do D-Bus está quebrado, então o redesenho é inevitável
• A documentação está atualmente em estado WIP (em andamento) e será publicada quando estiver pronta
• O motivo para não usar Wayland é que ele não é adequado para IPC de propósito geral
• É possível escrever um proxy compatível com D-Bus (hyprtavern-dbus-notification-proxy)
• O motivo para usar C++ em vez de Rust é que a linguagem principal do desenvolvedor é C++
• Em termos de segurança, ataques com LD_PRELOAD não podem ser totalmente bloqueados, mas a estrutura aumenta a dificuldade do ataque e a chance de detecção

Conclusão

• O D-Bus é apontado como um gargalo no ecossistema de desktop Linux devido à sua falta de padronização, segurança e consistência
• O hyprtavern está sendo desenvolvido como um barramento IPC moderno e seguro para substituí-lo, com
  adoção gradual esperada, centrada no ecossistema Hyprland
• O objetivo é “tornar o userspace mais agradável”

[GN⁺]

Comentários do Hacker News

• Ao ver a polêmica sobre a vulnerabilidade de acesso ao armazenamento de segredos do GNOME, é engraçado que a equipe do GNOME tenha negado o problema com base no modelo de segurança de que “apps não confiáveis não podem se comunicar com o serviço de segredos”
  O GNOME realmente parece um projeto operado por um bando de palhaços

  • É irônico que o Wayland bloqueie a interceptação de eventos de entrada por motivos de segurança, mas deixe esse tipo de problema como está
  • Eu pensava no armazenamento de segredos como algo do tipo “dados que não deveriam ser salvos em texto puro no disco”. Se você quer isolamento entre apps, o certo é usar uma máquina virtual
  • É natural que programas executados com permissões do usuário possam acessar os dados do mesmo usuário. Se isso é uma vulnerabilidade, então o Linux inteiro já foi comprometido. Nesse ponto, xkcd 1200 é a analogia perfeita
  • No fim, isso parece o tipo de problema que termina em “comportamento intencional, não será corrigido, discussão trancada”
  • Hoje em dia, graças à IA, todo mundo pode jogar todo o código na nuvem e auditar por conta própria, então agora todos podem usar apenas software confiável /s

• Quando alguém disse que iria “criar um novo barramento do zero”, sugeri reutilizar o Binder, que já foi distribuído para dezenas de bilhões de dispositivos
  O Binder é o IPC central do Android e tem muito mais desenvolvedores e código já comprovado

  • Se você construir um novo sistema sobre o Binder, ganha uma base muito mais robusta. Além disso, o Google recentemente implementou o Binder do kernel em Rust e fez o merge
    Artigos relacionados: LWN, lista Rust-for-Linux
  • Porém, quase não existem implementações de Binder em espaço de usuário fora do Android
  • Procurei por “BSD Binder” e “Windows Binder”, mas não encontrei resultados. Provavelmente a expressão “serious OS” era uma piada
  • Fico curioso se o Binder é melhor que o D-Bus. Gostaria de saber em que pontos ele é superior
  • Talvez algum dia o Binder chegue também ao desktop Linux. Junto com o Android

• Eu estava na expectativa por Hyprwire e Hyprtavern, mas quase não há documentação nem testes
  É uma pena, porque projetos assim poderiam ter sido um bom ponto de partida

  • Parece que o desenvolvedor está em período de provas de conclusão da faculdade neste momento
  • O texto também menciona várias vezes que “ainda está em preparação”, então pretendo esperar para ver depois que estiver pronto

• Os desenvolvedores do OpenWrt já criaram há muito tempo uma alternativa chamada ubus
  Referências: documentação do ubus, comparação ubus vs dbus
  Só que ele quase não tem modelo de segurança, e há motivos compreensíveis para isso no contexto do OpenWrt

• Um dos problemas do D-Bus são as vulnerabilidades causadas por extensões de navegador ao se comunicarem com GNOME/KDE
  Só de visitar um site, já era possível inundar a API do D-Bus e travar o desktop
  Para pesquisadores de segurança, o D-Bus é realmente uma área que vale a pena explorar

  • Fico me perguntando o que significa exatamente “um site se integrar ao GNOME ou KDE”
  • Esse tipo de problema não acontece em um ambiente de VM independente

• O D-Bus é a coisa mais próxima de XPC, COM e Android IPC no desktop Linux
  Mas, por causa da fragmentação do desktop, é difícil criar uma pilha de desenvolvimento unificada
  Algo feito para GNOME não serve para KDE, e XFCE ou Sway seguem cada um por conta própria

  • O KDE usava no passado um IPC próprio chamado DCOP, mas hoje ele foi substituído pelo D-Bus
  • O D-Bus já tem mais de 20 anos, então talvez precise de um reboot. Mas, para um novo IPC dar certo, influência social importa mais do que a tecnologia
  • O KDE também tinha algo parecido com COM chamado KParts
  • No fim, a fragmentação é um resultado natural da existência de diferentes casos de uso

• Foi a primeira vez que descobri que cofres de segredos como KWallet ou GNOME Keyring ficam, na prática, acessíveis a todos os apps quando estão desbloqueados
  Conferindo pela interface gráfica do seahorse, a maior parte parecia ser só chaves relacionadas ao Chromium ou tokens de conta da JetBrains
  Não havia senhas em texto puro, mas fiquei pensando que um app malicioso talvez conseguisse extrair algo mais se fuçasse os dados do Chromium

  • De qualquer forma, se a senha não é digitada, ela inevitavelmente precisa existir em texto puro na memória
    Se o sistema não avisa quando há acesso, então faz pouca diferença qual software gerencia isso

• Existe a dúvida: “por que precisamos de um protocolo de barramento genérico?”
  Usar HTTP ou um protocolo JSON simples sobre Unix domain socket já seria suficiente
  Tudo isso já suporta gerenciamento de permissões, encaminhamento por SSH, mounts em contêineres etc.
  O D-Bus tem uma estrutura complexa com serviço, interface, caminho, método etc., mas mesmo assim a identificação de mensagens é incompleta e ainda exige conhecer os detalhes do protocolo de cada app
  No fim, até o processamento por proxy fica difícil; é um sistema excessivamente complexo

• O design do D-Bus parece um exemplo da lei da aleatoriedade: a melhor solução nem sempre é a escolhida
  Assim como existem inúmeros frameworks melhores que React, mas que acabam esquecidos por não serem conhecidos

  • Isso muitas vezes acontece porque as pessoas avaliam algo sem entender completamente o problema
  • O D-Bus decolou por causa da relação entre GNOME e Red Hat
  • Na verdade, não existe uma solução “melhor” de forma absoluta; cada uma ocupa um espaço diferente de trade-offs. É preciso tomar cuidado para não desmerecer o esforço dos outros
  • A maior parte do open source é feita por voluntários. Algumas pessoas investem milhares de horas no desenvolvimento, então é natural que elas acabem decidindo a direção. Numa estrutura dessas, decisões estranhas inevitavelmente aparecem
  • Como diz a frase “quanto pior, melhor”, a realidade é que o próprio processo de escolha costuma acontecer da forma mais ineficiente possível

• O fato de o GNOME ter contestado o relatório de vulnerabilidade mencionando as restrições de acesso da sandbox do Flatpak me lembrou este post antigo do blog da Microsoft
  Além disso, não consigo entender por que publicaram a citação apenas como captura de tela, impedindo até copiar o texto

  • O Wayland bloqueia screenshots sem privilégios de root, mas o D-Bus fica aberto no espírito YOLO