Linux masaüstünde D-Bus'un sorunları

• D-Bus, uygulamalar arası iletişim için kullanılan bir veri yoludur; fikir olarak faydalı olsa da uygulaması son derece zayıf ve standart dışı
• Standart dokümantasyonu eksik ve tutarsız, ayrıca gerçek uygulamalar buna uymadığı için uyumluluk çöküşü yaşanıyor
• Güvenlik açıkları da ciddi; bir uygulama, kilidi açılmış durumdayken başka bir uygulamanın gizli verilerini okuyabiliyor
• Buna karşılık yazar, yeni bir veri yolu sistemi olan hyprtavern ile hyprwire protokolünü geliştiriyor
• hyprtavern, katı tip denetimi, yerleşik yetki yönetimi, güvenli gizli depolama (kv) gibi özelliklerle D-Bus'un yapısal sorunlarını çözmeyi hedefliyor

---

D-Bus'un kavramı ve sınırları

• D-Bus, uygulama ve servislerin paylaşılan bir veri yolu (bus) üzerinden metotlarını ve özelliklerini sunmasına ve birbirini çağırmasına imkân veren bir sistem
  • Örneğin hava durumu servisi sunan bir uygulama veri yoluna API kaydederse, diğer uygulamalar bunu bulup kullanabilir
• Ancak D-Bus, aşırı derecede esnek ve yapısız tasarımı nedeniyle herhangi bir nesnenin rastgele metot kaydetmesine ve çağırmasına izin veriyor
  • Bu da "Garbage in, garbage out" durumuna yol açıyor

Standart dokümantasyon ve uygulama karmaşası

• D-Bus standart dokümantasyonu birden fazla yere dağılmış, tamamlanmamış ve anlaşılması zor durumda
  • Gerçek uygulamalar ya buna uymuyor ya da birbirinden farklı belirtimleri keyfî biçimde kullanıyor
• Yazar, xdg-desktop-portal-hyprland geliştirirken restore_token belirtimini uyguladığını,
  ancak tüm uygulamaların resmî olmayan restore_data alanını kullandığı için bunun uyumlu olmadığını açıklıyor
• D-Bus'un variant tipi (a{sv}) keyfî veri aktarımına izin verdiğinden, protokol tutarlılığını bozan başlıca nedenlerden biri olarak gösteriliyor

Güvenlik yapısındaki kusurlar

• D-Bus'ta merkezî yetki yönetimi veya reddetme mekanizması bulunmuyor
  • Tüm uygulamalar diğer uygulamaların çağrılarını görebiliyor ve açık bir güvenlik önlemi yoksa sınırsız erişim mümkün oluyor
• gnome-keyring, kwallet gibi gizli depo sistemleri de yapısal olarak zayıf
  • Depo kilidi açıldığında tüm uygulamalar tüm gizli verilere erişebiliyor
  • Yazar bunu "güvenlik açısından şaka düzeyinde" diye nitelendiriyor

Yeni alternatif: hyprwire ve hyprtavern

• Yazar, D-Bus'un sorunlarını çözmek için yeni bir veri yolu sistemi olan hyprtavern geliştiriyor
  • hyprwire, Wayland tasarımından ilham alan yalın ve tutarlı bir wire protokolü
    • Tip zorlaması, hızlı bağlantı ve basit yapı gibi özelliklere sahip
  • hyprtavern, uygulamaların protokol tabanlı nesneleri kaydedip birbirini keşfettiği bir yapı sunuyor
    • Yerleşik yetki sistemi, katı protokol uyumu, basitleştirilmiş API ve güvenli varsayılanlar sağlıyor

hyprtavern-kv (güvenli anahtar-değer deposu)

• D-Bus Secrets API'sinin yerine geçen temel (core) protokol
  • Bir uygulamanın kaydettiği sırlar yalnızca o uygulama tarafından okunabiliyor ve numaralandırma (enumeration) yapılamıyor
  • Flatpak, Snap, AppImage uygulamaları için kimlik tabanlı erişim denetimi de planlanıyor
  • Veriler her zaman şifreli olarak saklanıyor ve parola ayarlandığında gerçek güvenlik garantisi sağlanabiliyor
  • Tüm uygulamalar güvenli gizli depo işlevinden varsayılan olarak yararlanabiliyor

Geliştirme durumu ve gelecek planları

• hyprtavern hâlâ geliştirmenin erken aşamasında ve gelecekte Hyprland 0.54 sürümünde dahili olarak kullanılması planlanıyor
• İlk benimsenmenin sınırlı olacağı öngörülse de kademeli geçiş mümkün
  • D-Bus'tan farklı olarak birden fazla oturum veri yolu paralel çalıştırılabildiği için uyumluluk proxy'leri yazmak da mümkün
• C++ ile yazıldı ve Rust, Go, Python bağlayıcıları da kolayca geliştirilebilir
• Yazar, "D-Bus temelden düzeltilemez; tamamen yeniden tasarlanması gerekir" diye vurguluyor

SSS özeti

• "Tekerleği yeniden icat etmek" eleştirisine karşı, D-Bus'un temel tasarımının bozuk olduğu ve bu yüzden yeniden tasarımın kaçınılmaz olduğu söyleniyor
• Dokümantasyon şu anda WIP (çalışma aşamasında) durumunda ve tamamlandığında yayımlanacak
• Wayland'ın kullanılmama nedeni, genel amaçlı IPC için uygun olmaması
• D-Bus uyumluluk proxy'si (hyprtavern-dbus-notification-proxy) yazmak mümkün
• Rust yerine C++ kullanılmasının nedeni, geliştiricinin ana dilinin C++ olması
• Güvenlik açısından LD_PRELOAD saldırıları tamamen engellenemese de, saldırının zorluğunu ve tespit edilebilirliğini artıran bir yapı hedefleniyor

Sonuç

• D-Bus, standart dışılık, güvenlik eksikliği ve tutarsızlık nedeniyle Linux masaüstü ekosisteminde bir darboğaz olarak görülüyor
• hyprtavern, bunun yerine geçebilecek modern ve güvenli bir IPC veri yolu olarak geliştiriliyor ve
  Hyprland ekosistemi merkezli kademeli bir benimsenme bekleniyor
• Amaç, "userspace'i daha yaşanabilir hâle getirmek"

[GN⁺]

Hacker News yorumları

• GNOME’un gizli depoya erişim zafiyeti tartışmasını görünce, GNOME ekibinin sorunu “güvenilmeyen uygulamalar gizli servisle iletişim kuramaz” güvenlik modeline dayanarak reddetmesi komik geliyor
  GNOME gerçekten de palyaço ekibi tarafından yürütülen bir proje gibi duruyor

  • Wayland güvenlik gerekçesiyle giriş olaylarının yakalanmasını engellerken, böyle bir sorunu olduğu gibi bırakması ironik
  • Ben gizli depoyu, “diskte düz metin olarak saklanmaması gereken veriler” gibi düşünüyordum. Uygulamalar arası yalıtım istiyorsan sanal makine kullanmak gerekir
  • Kullanıcı yetkileriyle çalışan bir programın aynı kullanıcının verilerine erişebilmesi gayet normal. Eğer bu bir zafiyetse, o zaman Linux’un tamamı delik demektir. Bunun için xkcd 1200 tam yerinde bir benzetme
  • Sonuçta iş yine “tasarlanan davranış, düzeltilmeyecek, tartışma kilitlendi” noktasında bitecek gibi görünüyor
  • Artık yapay zeka sayesinde tüm kodu buluta atıp doğrudan denetleyebildiğimiz (audit) için, herkesin güvenilir yazılım kullanabildiği bir döneme ulaştık /s

• Biri “yeni bir bus’ı kendim yapacağım” deyince, zaten milyarlarca cihaza dağıtılmış olan Binder’ı yeniden kullanmayı önermiş
  Binder, Android’in temel IPC mekanizması ve arkasında çok daha fazla geliştirici ile sahada doğrulanmış kod var

  • Binder üzerine yeni bir sistem kurmak çok daha sağlam bir temel sağlayabilir. Üstelik Google kısa süre önce çekirdek için Rust ile yazılmış Binder uygulamasını merge etti
    İlgili yazılar: LWN, Rust-for-Linux mailing list
  • Ama Android dışındaki Binder kullanıcı alanı uygulamaları neredeyse yok
  • “BSD Binder” ya da “Windows Binder” diye aradım ama hiçbir sonuç bulamadım. Muhtemelen “serious OS” ifadesi bir şakaydı
  • Binder’ın D-Bus’tan daha iyi olup olmadığını merak ediyorum. Hangi açılardan daha iyi olduğunu bilmek isterim
  • Belki bir gün Linux masaüstüne de Binder gelir. Android’le birlikte

• Hyprwire ve Hyprtavern için umutlanmıştım ama neredeyse hiç belge ya da test yok
  Bu projeler iyi bir başlangıç noktası olabilirdi, o yüzden biraz hayal kırıklığı yarattı

  • Geliştirici şu anda muhtemelen üniversite mezuniyet sınavı döneminde
  • Yazıda da birkaç kez “henüz hazır değil” denmişti, ben de tamamlandıktan sonrasını bekleyeceğim

• OpenWrt geliştiricileri zaten uzun zaman önce ubus adlı bir alternatif yapmıştı
  Bakınız: ubus docs, ubus vs dbus karşılaştırması
  Ama güvenlik modeli neredeyse yok ve OpenWrt’nin yapısı düşünüldüğünde bunun makul nedenleri var

• D-Bus’un sorunlarından biri, tarayıcı eklentilerinin GNOME/KDE ile iletişim kurarken ortaya çıkan zafiyetler
  Sadece bir web sitesini ziyaret ederek bile D-Bus API’si flood edilip masaüstü kilitlenebiliyordu
  Eğer güvenlik araştırmacısıysan, D-Bus gerçekten incelenmeye değer bir alan

  • “Web sitesi GNOME ya da KDE ile entegre oluyor” derken tam olarak ne kastediliyor, merak ettim
  • Bu tür sorunlar bağımsız VM ortamlarında ortaya çıkmıyor

• D-Bus, Linux masaüstünde XPC, COM ve Android IPC’ye en yakın şey
  Ama masaüstü parçalanmışlığı yüzünden birleşik bir geliştirme yığını kurmak zor
  GNOME için yaptığın şey KDE’de işe yaramıyor, XFCE ve Sway ise bambaşka tarafta

  • KDE eskiden DCOP adlı kendi IPC sistemini kullanıyordu ama artık onun yerine D-Bus var
  • D-Bus 20 yılı geçti, artık bir yeniden başlatmaya ihtiyacı var. Ama yeni bir IPC’nin başarılı olması için teknik niteliklerden çok sosyal etki gücü daha önemli
  • KDE’de COM’a benzeyen KParts da vardı
  • Parçalanmışlık aslında farklı kullanım senaryolarının bulunmasının doğal bir sonucu

• KWallet ya da GNOME Keyring gibi gizli depoların, kilit açıldıktan sonra fiilen tüm uygulamalara açık olduğunu ilk kez öğreniyorum
  seahorse arayüzüyle baktığımda çoğunlukla Chromium ile ilgili anahtarlar ve JetBrains hesap token’ları gördüm
  Düz metin parolalar yoktu ama kötü niyetli bir uygulama Chromium verilerini kurcalarsa daha fazlasını bulabilir gibi geliyor

  • Sonuçta parola girmeyeceksen, onun bellekte düz metin olarak bulunması zaten kaçınılmaz
    Sistem erişim sırasında bildirim vermiyorsa, hangi yazılımın yönettiğinin çok büyük bir farkı yok

• “Neden ille de genel amaçlı bir bus protokolüne ihtiyaç var?” diye soruyorum
  Unix domain socket üzerinde HTTP ya da basit bir JSON protokolü kullanmak yeterli olur
  Yetki yönetimi, SSH forwarding, container mount gibi şeyler de zaten destekleniyor
  D-Bus; servis, arayüz, yol, metot gibi yapılarla karmaşık bir düzen kuruyor ama buna rağmen mesaj tanımlama eksik kalıyor ve uygulamaya özgü protokol ayrıntılarını bilmek gerekiyor
  Sonuçta proxy işlemek de zorlaşıyor ve ortaya gereğinden fazla karmaşık bir sistem çıkıyor

• D-Bus’un tasarımı, “en iyi çözümün her zaman seçilmediği” rastlantısallık yasasına bir örnek gibi duruyor
  Tıpkı React’tan daha iyi sayısız framework olmasına rağmen yeterince bilinmedikleri için görünmez olmaları gibi

  • Bu durum çoğu zaman insanların problemi tam anlamadan değerlendirme yapmasından kaynaklanıyor
  • D-Bus’un öne çıkması biraz da GNOME ile Red Hat arasındaki ilişki sayesinde oldu
  • Aslında “en iyi” diye tek bir çözüm yok; herkes farklı bir trade-off alanında duruyor. Başkalarının emeğini küçümseyen tavırlardan kaçınmak gerek
  • Açık kaynak projelerin çoğu gönüllüler tarafından yapılıyor. Birkaç kişi binlerce saat harcayıp geliştirdiği için yönü onların belirlemesi doğal. Böyle bir yapıda garip kararların çıkması da kaçınılmaz
  • “Worse is better” sözünde olduğu gibi, seçim sürecinin kendisi çoğu zaman en verimsiz şekilde işliyor

• GNOME’un zafiyet bildirimine karşı çıkarken Flatpak sandbox erişim kısıtlarını öne sürmesi, bana eski bir Microsoft blog yazısını hatırlattı
  Üstelik alıntıyı ekran görüntüsü olarak paylaşıp kopyalanamaz hale getirmelerini gerçekten anlayamıyorum

  • Wayland root yetkisi olmadan ekran görüntüsünü engelliyor ama D-Bus tamamen YOLO ruhuyla açık bırakılmış durumda