Masalah D-Bus di desktop Linux

• D-Bus adalah bus untuk komunikasi antar-aplikasi; konsepnya berguna, tetapi implementasinya sangat buruk dan tidak standar
• Dokumen standarnya tidak lengkap dan tidak konsisten, dan implementasi nyata tidak mengikutinya sehingga terjadi keruntuhan kompatibilitas
• Celah keamanan juga serius; aplikasi dapat membaca data rahasia aplikasi lain saat penyimpanan dalam keadaan tidak terkunci
• Sebagai tanggapan, penulis sedang mengembangkan sistem bus baru 'hyprtavern' dan protokol 'hyprwire'
• hyprtavern berupaya menyelesaikan masalah struktural D-Bus melalui pemeriksaan tipe yang ketat, manajemen izin bawaan, penyimpanan rahasia aman (kv), dan lainnya

---

Konsep dan batasan D-Bus

• D-Bus adalah sistem yang memungkinkan aplikasi dan layanan mengekspos metode serta properti melalui bus bersama (bus) dan saling memanggil
  • Misalnya, jika aplikasi yang menyediakan layanan cuaca mendaftarkan API ke bus, aplikasi lain dapat menemukannya dan menggunakannya
• Namun, karena D-Bus memiliki desain yang terlalu permisif dan tidak terstruktur, objek apa pun dapat mendaftarkan dan memanggil metode arbitrer
  • Akibatnya muncul fenomena "Garbage in, garbage out"

Kekacauan dokumen standar dan implementasi

• Dokumen standar D-Bus tersebar di berbagai tempat dan hadir dalam bentuk yang belum selesai serta sulit dipahami
  • Implementasi nyata tidak mengikutinya, atau secara sembarang memakai spesifikasi yang berbeda satu sama lain
• Penulis menjelaskan bahwa saat mengembangkan xdg-desktop-portal-hyprland ia mengimplementasikan spesifikasi "restore_token",
  tetapi semua aplikasi memakai field tidak resmi "restore_data" sehingga tidak kompatibel
• Tipe variant(a{sv}) pada D-Bus memungkinkan pengiriman data arbitrer, dan disebut sebagai penyebab utama rusaknya konsistensi protokol

Cacat pada struktur keamanan

• D-Bus tidak memiliki manajemen izin terpusat maupun mekanisme penolakan
  • Semua aplikasi dapat melihat panggilan aplikasi lain, dan tanpa mekanisme keamanan eksplisit, akses tak terbatas dimungkinkan
• Penyimpanan rahasia seperti gnome-keyring, kwallet juga rapuh secara struktural
  • Begitu penyimpanan dibuka, semua aplikasi dapat mengakses semua data rahasia
  • Penulis menyebut ini sebagai "lelucon keamanan"

Alternatif baru: hyprwire dan hyprtavern

• Untuk mengatasi masalah D-Bus, penulis sedang mengembangkan sistem bus baru 'hyprtavern'
  • hyprwire adalah protokol wire yang ringkas dan konsisten yang terinspirasi dari desain Wayland
    • Ciri utamanya adalah pemaksaan tipe, koneksi cepat, dan struktur sederhana
  • hyprtavern memiliki struktur tempat aplikasi mendaftarkan objek berbasis protokol dan saling menemukan
    • Menyediakan sistem izin bawaan, kepatuhan protokol yang ketat, API yang disederhanakan, dan default yang aman

hyprtavern-kv (penyimpanan key-value aman)

• Protokol inti (core) yang menggantikan Secrets API milik D-Bus
  • Rahasia yang didaftarkan aplikasi hanya dapat dibaca oleh aplikasi tersebut, dan tidak dapat dienumerasi (enumeration)
  • Kontrol akses berbasis ID untuk aplikasi Flatpak, Snap, AppImage juga direncanakan
  • Selalu disimpan dalam keadaan terenkripsi, dan saat kata sandi disetel, jaminan keamanan yang nyata dimungkinkan
  • Semua aplikasi dapat memakai fungsi penyimpanan rahasia aman secara default

Status pengembangan dan rencana ke depan

• hyprtavern masih berada pada tahap awal pengembangan, dan direncanakan akan dipakai secara internal pada Hyprland versi 0.54
• Adopsi awal diperkirakan terbatas, tetapi transisi bertahap dimungkinkan
  • Berbeda dengan D-Bus, beberapa session bus dapat dijalankan paralel sehingga proxy kompatibilitas juga bisa dibuat
• Ditulis dalam C++, dan binding Rust, Go, Python juga dapat diimplementasikan dengan mudah
• Penulis menegaskan bahwa "D-Bus pada dasarnya tidak bisa diperbaiki dan harus didesain ulang sepenuhnya"

Ringkasan FAQ

• Menanggapi kritik bahwa ini "menciptakan ulang roda", ia menyebut desain fundamental D-Bus sudah rusak sehingga redesain tak terelakkan
• Dokumentasi saat ini masih berstatus WIP (dalam proses pengerjaan) dan akan dipublikasikan setelah selesai
• Alasan tidak menggunakan Wayland adalah karena tidak cocok untuk IPC umum
• Proxy kompatibilitas D-Bus (hyprtavern-dbus-notification-proxy) dapat dibuat
• Alasan memakai C++ alih-alih Rust adalah karena bahasa utama pengembang adalah C++
• Dari sisi keamanan, serangan LD_PRELOAD sulit diblokir sepenuhnya, tetapi strukturnya dirancang untuk meningkatkan tingkat kesulitan serangan dan kemungkinan deteksi

Kesimpulan

• D-Bus disebut sebagai hambatan dalam ekosistem desktop Linux karena tidak standar, tidak aman, dan tidak konsisten
• hyprtavern sedang dikembangkan sebagai bus IPC modern dan aman untuk menggantikannya,
  dengan adopsi bertahap yang diperkirakan berpusat pada ekosistem Hyprland
• Tujuannya adalah "membuat userspace lebih nyaman"

[GN⁺]

Komentar Hacker News

• Melihat kontroversi kerentanan akses penyimpanan rahasia di GNOME, lucu rasanya GNOME menolak masalah ini dengan dasar model keamanan bahwa “aplikasi yang tidak tepercaya tidak bisa berkomunikasi dengan layanan rahasia”
  GNOME benar-benar terasa seperti proyek yang dijalankan oleh sekumpulan badut

  • Ironis bahwa Wayland memblokir penyadapan event input demi alasan keamanan, tapi justru membiarkan masalah seperti ini tetap ada
  • Saya menganggap penyimpanan rahasia sebagai “data yang tidak boleh disimpan dalam bentuk plaintext di disk”. Jika ingin isolasi antaraplikasi, yang tepat adalah memakai mesin virtual
  • Wajar saja kalau program yang berjalan dengan hak akses pengguna bisa mengakses data milik pengguna yang sama. Kalau itu dianggap kerentanan, berarti seluruh Linux sudah jebol. Untuk ini, xkcd 1200 adalah analogi yang pas
  • Pada akhirnya ini terasa seperti masalah yang akan ditutup dengan “perilaku yang dimaksud, tidak akan diperbaiki, diskusi dikunci”
  • Sekarang berkat AI kita bisa melempar semua kode ke cloud dan langsung audit sendiri, jadi kini semua orang bisa memakai perangkat lunak yang tepercaya saja /s

• Ada yang bilang ingin “membuat bus baru sendiri”, jadi saya mengusulkan bagaimana kalau memanfaatkan kembali Binder yang sudah didistribusikan ke miliaran perangkat
  Binder adalah IPC inti Android, dengan jauh lebih banyak pengembang dan kode yang sudah teruji

  • Jika membangun sistem baru di atas Binder, fondasinya bisa jadi jauh lebih kokoh. Apalagi Google baru-baru ini sudah mengimplementasikan Binder untuk kernel dalam Rust dan berhasil di-merge
    Artikel terkait: LWN, mailing list Rust-for-Linux
  • Hanya saja, hampir tidak ada implementasi ruang pengguna Binder di luar Android
  • Saya sempat mencari “BSD Binder” atau “Windows Binder”, tapi tidak menemukan hasil. Mungkin ungkapan “serious OS” itu cuma bercanda
  • Saya penasaran apakah Binder memang lebih baik daripada D-Bus. Ingin tahu di sisi mana ia lebih unggul
  • Mungkin suatu hari nanti Binder juga akan masuk ke desktop Linux. Bersama Android

• Saya sempat berharap pada Hyprwire dan Hyprtavern, tetapi hampir tidak ada dokumentasi maupun pengujian
  Sayang sekali, padahal proyek seperti ini bisa menjadi titik awal yang bagus

  • Sepertinya pengembangnya sedang dalam masa ujian kelulusan universitas sekarang
  • Di tulisannya juga berkali-kali disebutkan “masih dalam persiapan”, jadi saya akan menunggu sampai selesai

• Para pengembang OpenWrt sebenarnya sudah lama membuat alternatif bernama ubus
  Referensi: dokumentasi ubus, perbandingan ubus vs dbus
  Hanya saja, hampir tidak ada model keamanannya, dan mengingat sifat OpenWrt itu cukup bisa dimengerti

• Salah satu masalah D-Bus adalah kerentanan yang muncul ketika ekstensi browser berkomunikasi dengan GNOME/KDE
  Hanya dengan mengunjungi situs web saja, API D-Bus bisa dibanjiri sampai desktop berhenti merespons
  Kalau saya seorang peneliti keamanan, D-Bus jelas area yang sangat layak dieksplorasi

  • Saya penasaran apa maksudnya “situs web terintegrasi dengan GNOME atau KDE”
  • Masalah seperti ini tidak terjadi di lingkungan VM yang terisolasi

• D-Bus adalah hal yang paling mendekati XPC, COM, atau Android IPC di desktop Linux
  Tapi karena fragmentasi desktop, sulit membuat stack pengembangan yang terpadu
  Apa yang dibuat untuk GNOME tidak berguna di KDE, lalu XFCE atau Sway berjalan sendiri-sendiri lagi

  • KDE dulu memakai IPC buatannya sendiri bernama DCOP, tetapi sekarang sudah diganti dengan D-Bus
  • D-Bus sudah berusia lebih dari 20 tahun, jadi sekarang rasanya perlu reboot. Tapi kalau IPC baru ingin berhasil, yang lebih penting daripada teknologi adalah pengaruh sosial
  • KDE juga dulu punya KParts yang mirip COM
  • Fragmentasi pada akhirnya adalah hasil yang alami karena memang ada beragam use case

• Baru kali ini saya tahu bahwa penyimpanan rahasia seperti KWallet atau GNOME Keyring pada dasarnya bisa diakses semua aplikasi selama dalam keadaan tidak terkunci
  Setelah dicek lewat GUI seahorse, isinya kebanyakan hanya kunci terkait Chromium atau token akun JetBrains
  Tidak ada kata sandi plaintext, tetapi kalau aplikasi berbahaya menggali data Chromium, rasanya mungkin saja ada hal lain yang bisa didapat

  • Kalau toh kata sandi tidak perlu dimasukkan lagi, maka mau tidak mau ia harus ada di memori dalam bentuk plaintext
    Jika sistem tidak memberi notifikasi saat ada akses, siapa pun perangkat lunak yang mengelolanya pada dasarnya tidak membuat banyak perbedaan

• Ada pertanyaan, “kenapa harus ada protokol bus serbaguna segala?”
  Di atas Unix domain socket, HTTP atau protokol JSON sederhana sudah cukup
  Manajemen izin, SSH forwarding, mount container, dan sebagainya juga semuanya didukung
  D-Bus punya struktur yang rumit seperti service, interface, path, method, dan lain-lain, tetapi identifikasi pesannya tetap tidak lengkap, dan tetap perlu tahu detail protokol tiap aplikasi
  Pada akhirnya pemrosesan proxy pun jadi sulit, dan keseluruhan sistem terasa terlalu kompleks

• Desain D-Bus terasa seperti contoh hukum keacakan bahwa “solusi terbaik belum tentu yang terpilih”
  Sama seperti ada banyak framework yang lebih baik daripada React, tapi tenggelam karena tidak dikenal

  • Fenomena seperti ini sering terjadi karena orang menilai tanpa benar-benar memahami masalahnya sampai tuntas
  • D-Bus menjadi dominan berkat keterkaitannya dengan GNOME dan Red Hat
  • Sebenarnya tidak ada solusi yang “paling unggul”; semuanya hanya berada di ruang trade-off yang berbeda. Sikap yang meremehkan upaya orang lain perlu diwaspadai
  • Open source kebanyakan dibuat oleh sukarelawan. Segelintir orang menginvestasikan ribuan jam untuk mengembangkannya, jadi wajar kalau merekalah yang menentukan arahnya. Dalam struktur seperti ini, keputusan aneh memang tak terhindarkan
  • Seperti ungkapan “worse is better”, kenyataannya proses pemilihan itu sendiri sering berlangsung dengan cara yang paling tidak efisien

• Fakta bahwa GNOME membantah laporan kerentanan sambil menyinggung pembatasan akses sandbox Flatpak mengingatkan saya pada tulisan lama di blog Microsoft
  Ditambah lagi, saya benar-benar tidak mengerti kenapa kutipannya diunggah hanya sebagai screenshot, sampai-sampai tidak bisa disalin

  • Wayland memblokir screenshot tanpa hak root, tetapi D-Bus terbuka lebar dengan semangat YOLO