▲

리눅스 데스크톱의 D-Bus 문제점

 (blog.vaxry.net)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 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는 비표준, 비보안, 비일관성으로 인해 리눅스 데스크톱 생태계의 병목으로 지적됨
  • hyprtavern은 이를 대체할 현대적·안전한 IPC 버스로 개발 중이며,
    Hyprland 생태계 중심으로 점진적 도입이 예상됨
  • 목표는 “사용자 공간(userspace)을 더 쾌적하게 만드는 것”임
▲
GN⁺ 1일전  [-]
Hacker News 의견들

  • GNOME의 비밀 저장소 접근 취약점 논란을 보며, GNOME 팀이 “신뢰되지 않은 앱은 비밀 서비스와 통신할 수 없다”는 보안 모델을 근거로 문제를 부정한 게 웃김
    GNOME은 정말 광대단이 운영하는 프로젝트 같음

    • Wayland는 보안을 이유로 입력 이벤트 가로채기를 막으면서, 정작 이런 문제는 그대로 두는 게 아이러니함
    • 나는 비밀 저장소를 “디스크에 평문으로 저장하면 안 되는 데이터” 정도로 생각했음. 앱 간 격리를 원한다면 가상머신을 쓰는 게 맞음
    • 사용자 권한으로 실행되는 프로그램이 같은 사용자 데이터에 접근할 수 있는 건 당연한 일임. 만약 그게 취약점이라면 리눅스 전체가 뚫린 셈임. 관련해서 xkcd 1200이 딱 맞는 비유임
    • 결국 “의도된 동작, 수정 안 함, 토론 잠금”으로 끝날 문제 같음
    • 요즘은 AI 덕분에 모든 코드를 클라우드에 던져서 직접 감사(audit) 할 수 있으니, 이제 모두가 신뢰할 수 있는 소프트웨어만 쓸 수 있게 되었음 /s

  • 누군가 “새로운 버스를 직접 만들겠다”고 하길래, 이미 수십억 대 기기에 배포된 Binder를 재활용하면 어떨까 제안함
    Binder는 안드로이드의 핵심 IPC로, 훨씬 많은 개발자와 검증된 코드가 있음

    • Binder 위에 새 시스템을 만들면 훨씬 견고한 기반을 얻을 수 있음. 게다가 Google이 최근 Rust로 커널용 Binder를 구현해 머지시켰음
      관련 기사: LWN, Rust-for-Linux 메일링
    • 다만 안드로이드 외의 Binder 사용자 공간 구현체는 거의 없음
    • “BSD Binder”나 “Windows Binder”를 검색해봤지만 결과가 없었음. 아마 “serious OS”라는 표현은 농담이었을 듯함
    • Binder가 D-Bus보다 나은지 궁금함. 어떤 점에서 더 좋은지 알고 싶음
    • 언젠가 리눅스 데스크탑에도 Binder가 들어올지도 모름. 안드로이드와 함께

  • Hyprwire와 Hyprtavern을 기대했는데, 문서나 테스트가 거의 없음
    이런 프로젝트들이 좋은 출발점이 될 수 있었을 텐데 아쉬움

    • 개발자가 지금 대학교 졸업 시험 기간이라 그런 듯함
    • 글에서도 “아직 준비 중”이라고 여러 번 언급했으니, 완성 후를 기다려볼 생각임

  • OpenWrt 개발자들은 이미 오래전에 ubus라는 대안을 만들었음
    참고: ubus 문서, ubus vs dbus 비교
    다만 보안 모델은 거의 없고, OpenWrt 특성상 그럴 만한 이유가 있음

  • D-Bus의 문제 중 하나는 브라우저 확장 기능들이 GNOME/KDE와 통신하면서 발생하는 취약점임
    웹사이트 방문만으로도 D-Bus API를 폭주시켜 데스크탑이 멈출 수 있었음
    보안 연구자라면 D-Bus는 정말 탐구할 가치가 있는 영역임

    • “웹사이트가 GNOME이나 KDE와 통합된다”는 게 무슨 의미인지 궁금함
    • 이런 문제는 독립 VM 환경에서는 발생하지 않음

  • D-Bus는 리눅스 데스크탑에서 XPC, COM, Android IPC에 가장 가까운 존재임
    하지만 데스크탑 단편화 때문에 통합된 개발 스택을 만들기 어려움
    GNOME용으로 만든 게 KDE에서는 쓸모없고, XFCE나 Sway는 또 따로 놀음

    • KDE는 예전에 DCOP이라는 자체 IPC를 썼지만 지금은 D-Bus로 교체됨
    • D-Bus는 20년이 넘었으니 이제 리부트가 필요함. 하지만 새로운 IPC가 성공하려면 기술보다 사회적 영향력이 더 중요함
    • KDE에는 COM과 비슷한 KParts도 있었음
    • 단편화는 결국 다양한 사용 사례가 존재하기 때문에 생기는 자연스러운 결과임

  • KWallet이나 GNOME Keyring 같은 비밀 저장소가 사실상 잠금 해제 상태에서는 모든 앱이 접근 가능하다는 걸 처음 알게 됨
    seahorse GUI로 확인해보니 대부분 Chromium 관련 키나 JetBrains 계정 토큰 정도였음
    평문 비밀번호는 없지만, 악성 앱이 Chromium 데이터를 파고들면 뭔가 더 나올 수도 있겠다는 생각이 듦

    • 어차피 비밀번호를 입력하지 않는다면 메모리에 평문으로 존재할 수밖에 없음
      시스템이 접근 시 알림을 주지 않는다면, 어떤 소프트웨어가 관리하든 큰 차이는 없음

  • “왜 굳이 범용 버스 프로토콜이 필요한가?”라는 의문이 있음
    Unix domain socket 위에서 HTTP나 간단한 JSON 프로토콜을 쓰면 충분함
    권한 관리, SSH 포워딩, 컨테이너 마운트 등도 다 지원됨
    D-Bus는 서비스, 인터페이스, 경로, 메서드 등 구조가 복잡한데도 메시지 식별이 불완전하고, 앱별 프로토콜 세부사항을 알아야 함
    결국 프록시 처리도 어렵고, 과도하게 복잡한 시스템임

  • D-Bus의 설계가 “가장 뛰어난 솔루션이 꼭 선택되지 않는다”는 무작위성의 법칙을 보여주는 예 같음
    React보다 나은 프레임워크가 수없이 존재하지만, 알려지지 않아 묻히는 것처럼

    • 이런 현상은 종종 사람들이 문제를 완전히 이해하지 못한 채 평가하기 때문임
    • D-Bus가 뜬 건 GNOME과 Red Hat의 연관성 덕분임
    • 사실 “가장 뛰어난” 해법은 존재하지 않고, 각자 다른 트레이드오프 공간에 있을 뿐임. 다른 사람의 노력을 무시하는 태도는 경계해야 함
    • 오픈소스는 대부분 자원봉사자가 만든다. 몇 명이 수천 시간을 투자해 개발하니, 그들이 방향을 결정하는 건 자연스러움. 이런 구조에서는 이상한 결정도 생길 수밖에 없음
    • “더 나쁠수록 낫다”는 말처럼, 선택 과정 자체가 가장 비효율적인 방식으로 이뤄지는 게 현실임

  • GNOME이 취약점 보고를 반박하며 Flatpak 샌드박스 접근 제한을 언급한 게, 예전 Microsoft 블로그 글을 떠올리게 함
    게다가 인용문을 스크린샷으로만 올려 복사도 안 되게 한 건 정말 이해할 수 없음

    • Wayland는 루트 권한 없이는 스크린샷을 막지만, D-Bus는 YOLO 정신으로 열려 있음
답변달기