# 리눅스 데스크톱의 D-Bus 문제점 > Clean Markdown view of GeekNews topic #25125. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25125](https://news.hada.io/topic?id=25125) - GeekNews Markdown: [https://news.hada.io/topic/25125.md](https://news.hada.io/topic/25125.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-17T04:33:22+09:00 - Updated: 2025-12-17T04:33:22+09:00 - Original source: [blog.vaxry.net](https://blog.vaxry.net/articles/2025-dbusSucks) - Points: 1 - Comments: 1 ## Topic Body - **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)을 더 쾌적하게 만드는 것**”임 ## Comments ### Comment 47862 - Author: neo - Created: 2025-12-17T04:33:22+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46278857) - GNOME의 **비밀 저장소 접근 취약점** 논란을 보며, GNOME 팀이 “신뢰되지 않은 앱은 비밀 서비스와 통신할 수 없다”는 보안 모델을 근거로 문제를 부정한 게 웃김 GNOME은 정말 **광대단**이 운영하는 프로젝트 같음 - Wayland는 보안을 이유로 입력 이벤트 가로채기를 막으면서, 정작 이런 문제는 그대로 두는 게 아이러니함 - 나는 비밀 저장소를 “디스크에 평문으로 저장하면 안 되는 데이터” 정도로 생각했음. 앱 간 격리를 원한다면 **가상머신**을 쓰는 게 맞음 - 사용자 권한으로 실행되는 프로그램이 같은 사용자 데이터에 접근할 수 있는 건 당연한 일임. 만약 그게 취약점이라면 리눅스 전체가 뚫린 셈임. 관련해서 [xkcd 1200](https://xkcd.com/1200/)이 딱 맞는 비유임 - 결국 “**의도된 동작, 수정 안 함, 토론 잠금**”으로 끝날 문제 같음 - 요즘은 AI 덕분에 모든 코드를 클라우드에 던져서 직접 **감사(audit)** 할 수 있으니, 이제 모두가 신뢰할 수 있는 소프트웨어만 쓸 수 있게 되었음 /s - 누군가 “새로운 버스를 직접 만들겠다”고 하길래, 이미 수십억 대 기기에 배포된 **Binder**를 재활용하면 어떨까 제안함 Binder는 안드로이드의 핵심 IPC로, 훨씬 많은 개발자와 검증된 코드가 있음 - Binder 위에 새 시스템을 만들면 훨씬 **견고한 기반**을 얻을 수 있음. 게다가 Google이 최근 Rust로 커널용 Binder를 구현해 머지시켰음 관련 기사: [LWN](https://lwn.net/Articles/953116/), [Rust-for-Linux 메일링](https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-0-08ba9197f637@google.com/) - 다만 안드로이드 외의 **Binder 사용자 공간 구현체**는 거의 없음 - “BSD Binder”나 “Windows Binder”를 검색해봤지만 결과가 없었음. 아마 “serious OS”라는 표현은 농담이었을 듯함 - Binder가 D-Bus보다 나은지 궁금함. 어떤 점에서 더 좋은지 알고 싶음 - 언젠가 **리눅스 데스크탑에도 Binder**가 들어올지도 모름. 안드로이드와 함께 - [Hyprwire](https://github.com/hyprwm/hyprwire)와 [Hyprtavern](https://github.com/hyprwm/hyprtavern)을 기대했는데, 문서나 테스트가 거의 없음 이런 프로젝트들이 좋은 출발점이 될 수 있었을 텐데 아쉬움 - 개발자가 지금 **대학교 졸업 시험 기간**이라 그런 듯함 - 글에서도 “아직 준비 중”이라고 여러 번 언급했으니, 완성 후를 기다려볼 생각임 - OpenWrt 개발자들은 이미 오래전에 **ubus**라는 대안을 만들었음 참고: [ubus 문서](https://openwrt.org/docs/techref/ubus), [ubus vs dbus 비교](https://openwrt.org/docs/techref/ubus#what_s_the_difference_between_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 블로그 글](https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283)을 떠올리게 함 게다가 인용문을 **스크린샷**으로만 올려 복사도 안 되게 한 건 정말 이해할 수 없음 - Wayland는 루트 권한 없이는 스크린샷을 막지만, D-Bus는 **YOLO 정신**으로 열려 있음