- D-Bus はアプリケーション間通信用のバスで、概念自体は有用だが、実装が非常に粗悪で非標準的である
- 標準文書が 不完全で一貫性がなく、実際の実装がそれに従わないため、互換性の崩壊が起きている
- セキュリティ上の欠陥も深刻で、アプリがロック解除された状態では、別のアプリの秘密データを読み取れる
- これに対応するため、筆者は 新しいバスシステム「hyprtavern」とプロトコル「hyprwire」 を開発中である
- hyprtavern は 厳格な型チェック、組み込みの権限管理、安全な秘密ストア(kv) などにより、D-Bus の構造的問題を解決しようとしている
D-Busの概念と限界
- D-Bus はアプリケーションとサービスが 共有バス(bus) を通じてメソッドやプロパティを公開し、相互に呼び出せるようにするシステム
- たとえば、天気サービスを提供するアプリがバス上に API を登録すれば、他のアプリがそれを見つけて利用できる
- しかし D-Bus は 過度に寛容で構造化されていない設計のため、どんなオブジェクトでも任意のメソッドを登録・呼び出しできる
- その結果、Garbage in, garbage out の現象が起きる
標準文書と実装の混乱
- D-Bus の標準文書は 複数の場所に散在し、未完成で難解な形で存在している
- 実際の実装はこれに従わなかったり、互いに異なる仕様を恣意的に使ったりしている
- 筆者は xdg-desktop-portal-hyprland の開発中に “restore_token” 仕様を実装したが、
すべてのアプリが非公式の “restore_data” フィールド を使っていたため、互換性が取れなかったと説明している
- D-Bus の variant 型(a{sv}) は任意データの転送を許しており、プロトコルの一貫性を壊す主要因だと指摘されている
セキュリティ構造の欠陥
- D-Bus には 中央集権的な権限管理や拒否メカニズムが存在しない
- すべてのアプリが他のアプリの呼び出しを見られ、明示的なセキュリティ対策がなければ無制限にアクセスできる
- gnome-keyring, kwallet のような秘密ストアも構造的に脆弱である
- ストアがロック解除されると、すべてのアプリがすべての秘密データにアクセス可能になる
- 筆者はこれを「セキュリティ上の冗談レベル」と表現している
新たな代替案: hyprwireとhyprtavern
- 筆者は D-Bus の問題を解決するため、新しいバスシステム「hyprtavern」 を開発中である
- hyprwire は Wayland の設計に着想を得た 簡潔で一貫した wire プロトコル
- hyprtavern はアプリが プロトコルベースのオブジェクトを登録し、相互に探索する構造
- 組み込みの権限システム、厳格なプロトコル準拠、簡素化された API、セキュアなデフォルトを提供する
hyprtavern-kv (安全なキー・バリューストア)
- D-Bus の Secrets API を置き換える 基本(core)プロトコル
- アプリが登録した秘密は そのアプリだけが読み取れ、列挙(enumeration) はできない
- Flatpak、Snap、AppImage アプリの ID ベースのアクセス制御も計画されている
- 常に暗号化されて保存され、パスワードを設定すれば 実質的なセキュリティ保証が可能
- すべてのアプリが 安全な秘密ストア機能を標準で利用できる
開発状況と今後の計画
- hyprtavern はまだ 開発初期段階にあり、今後 Hyprland 0.54 バージョンで内部的に利用される予定
- 初期採用は限定的と見込まれるが、段階的な移行が可能である
- D-Bus と異なり複数のセッションバスを並行実行できるため、互換プロキシの作成も可能である
- C++で書かれており、Rust・Go・Python バインディングも容易に実装できる
- 筆者は「D-Bus は根本的に修正できず、完全に新しく設計し直すべきだ」と強調している
FAQ要約
- 「車輪の再発明だ」という批判に対して、D-Bus の根本設計が壊れているため再設計は不可避だと言及している
- 文書は現在 WIP(作業中) 状態で、完成後に公開予定
- Wayland を使わなかった理由は 一般的な IPC 用途には不向きだからである
- D-Bus 互換プロキシ(hyprtavern-dbus-notification-proxy)の作成は可能
- Rust ではなく C++ を使った理由は 開発者の主言語が C++ だからである
- セキュリティ面では LD_PRELOAD 攻撃を完全には防げないが、攻撃の難易度と検出可能性を高める構造になっている
結論
- D-Bus は 非標準・非安全・非一貫であるため、Linux デスクトップ生態系のボトルネックだと指摘されている
- hyprtavern はこれを置き換える 現代的で安全な IPC バスとして開発中であり、
Hyprland エコシステムを中心に段階的な導入が予想される
- 目標は「userspace をより快適にすること」である
1件のコメント
Hacker Newsの意見
GNOMEの秘密ストレージへのアクセス脆弱性をめぐる騒動を見て、GNOMEチームが「信頼されていないアプリは秘密サービスと通信できない」というセキュリティモデルを根拠に問題を否定したのは笑ってしまう
GNOMEは本当に道化師集団が運営しているプロジェクトのように見える
誰かが「新しいバスを自分で作る」と言っていたので、すでに数十億台のデバイスに配布されているBinderを再利用したらどうかと提案した
BinderはAndroidの中核IPCであり、はるかに多くの開発者と実績あるコードがある
関連記事: LWN, Rust-for-Linuxメーリングリスト
Hyprwire と Hyprtavern に期待していたが、ドキュメントもテストもほとんどない
こうしたプロジェクトは良い出発点になれたはずなのに残念だ
OpenWrt開発者は、かなり前にすでにubusという代替を作っていた
参考: ubusドキュメント, ubus vs dbus 比較
ただしセキュリティモデルはほとんどなく、OpenWrtの性質上それなりの理由がある
D-Busの問題のひとつは、ブラウザー拡張機能がGNOME/KDEと通信することで生じる脆弱性だ
Webサイトを訪問しただけでもD-Bus APIが殺到し、デスクトップがフリーズすることがあった
セキュリティ研究者なら、D-Busは本当に掘り下げる価値のある領域だ
D-BusはLinuxデスクトップにおいて、XPC、COM、Android IPCに最も近い存在だ
しかしデスクトップの断片化のせいで、統合された開発スタックを作るのが難しい
GNOME向けに作ったものはKDEでは役に立たず、XFCEやSwayもまた別々に動いている
KWalletやGNOME Keyringのような秘密ストレージが、実質的にロック解除状態ではすべてのアプリからアクセス可能だと初めて知った
seahorseGUIで確認してみると、ほとんどがChromium関連のキーやJetBrainsアカウントのトークン程度だった平文のパスワードはなかったが、悪意あるアプリがChromiumデータを掘れば何かもっと出てくるかもしれないと思った
システムがアクセス時に通知しないのであれば、どのソフトウェアが管理していても大差はない
「なぜわざわざ汎用バスプロトコルが必要なのか？」という疑問がある
Unix domain socketの上でHTTPや簡単なJSONプロトコルを使えば十分だ
権限管理、SSHフォワーディング、コンテナマウントなども全部サポートできる
D-Busはサービス、インターフェース、パス、メソッドなど構造が複雑なのに、メッセージ識別は不完全で、アプリごとのプロトコル詳細を知っていなければならない
結局プロキシ処理も難しく、過度に複雑なシステムだ
D-Busの設計は、「最も優れたソリューションが必ずしも選ばれるわけではない」というランダム性の法則を示す例のように思える
Reactより優れたフレームワークがいくらでもあるのに、知られていないせいで埋もれてしまうようなものだ
GNOMEが脆弱性報告に反論しつつFlatpakサンドボックスのアクセス制限に言及したのは、昔の Microsoftのブログ記事 を思い出させる
しかも引用文をスクリーンショットでしか載せず、コピーもできないようにしたのは本当に理解できない