Những vấn đề của D-Bus trên desktop Linux

• D-Bus là bus dùng cho giao tiếp giữa các ứng dụng; ý tưởng thì hữu ích nhưng cách triển khai rất kém và phi tiêu chuẩn
• Tài liệu tiêu chuẩn không đầy đủ và thiếu nhất quán, trong khi các bản triển khai thực tế lại không tuân theo, dẫn đến sụp đổ tính tương thích
• Lỗ hổng bảo mật cũng rất nghiêm trọng: khi ở trạng thái đã mở khóa, một ứng dụng có thể đọc dữ liệu bí mật của ứng dụng khác
• Để đáp lại, tác giả đang phát triển hệ thống bus mới hyprtavern và giao thức hyprwire
• hyprtavern nhằm giải quyết các vấn đề cấu trúc của D-Bus thông qua kiểm tra kiểu nghiêm ngặt, quản lý quyền tích hợp sẵn, kho lưu trữ bí mật an toàn (kv) v.v.

---

Khái niệm và giới hạn của D-Bus

• D-Bus là hệ thống cho phép các ứng dụng và dịch vụ công khai method và property qua một bus dùng chung, rồi gọi lẫn nhau
  • Ví dụ, nếu một ứng dụng cung cấp dịch vụ thời tiết đăng ký API lên bus, ứng dụng khác có thể tìm và sử dụng nó
• Tuy nhiên, do D-Bus có thiết kế quá dễ dãi và thiếu cấu trúc, bất kỳ object nào cũng có thể đăng ký hoặc gọi method tùy ý
  • Từ đó dẫn đến hiện tượng “Garbage in, garbage out”

Sự hỗn loạn của tài liệu tiêu chuẩn và triển khai

• Tài liệu tiêu chuẩn D-Bus nằm rải rác ở nhiều nơi và tồn tại dưới dạng dang dở, khó hiểu
  • Các bản triển khai thực tế либо không tuân theo, либо tự ý dùng các đặc tả khác nhau
• Tác giả cho biết trong lúc phát triển xdg-desktop-portal-hyprland, anh đã triển khai đặc tả “restore_token”, nhưng
  mọi ứng dụng đều dùng trường không chính thức “restore_data”, nên không tương thích
• Kiểu variant của D-Bus (a{sv}) cho phép truyền dữ liệu tùy ý, và bị chỉ ra là nguyên nhân chính phá vỡ tính nhất quán của giao thức

Khiếm khuyết trong cấu trúc bảo mật

• D-Bus không có cơ chế quản lý quyền hay từ chối tập trung
  • Mọi ứng dụng đều có thể nhìn thấy lời gọi của ứng dụng khác, và nếu không có biện pháp bảo mật rõ ràng thì có thể truy cập không giới hạn
• Các kho bí mật như gnome-keyring, kwallet cũng yếu ngay từ cấu trúc
  • Khi kho được mở khóa, mọi ứng dụng đều có thể truy cập toàn bộ dữ liệu bí mật
  • Tác giả gọi điều này là “một trò đùa về bảo mật”

Phương án thay thế mới: hyprwire và hyprtavern

• Để giải quyết các vấn đề của D-Bus, tác giả đang phát triển hệ thống bus mới hyprtavern
  • hyprwire là wire protocol ngắn gọn và nhất quán lấy cảm hứng từ thiết kế của Wayland
    • Đặc trưng là ép kiểu, kết nối nhanh và cấu trúc đơn giản
  • hyprtavern có cấu trúc cho phép các ứng dụng đăng ký object dựa trên giao thức và khám phá lẫn nhau
    • Cung cấp hệ thống quyền tích hợp, tuân thủ giao thức nghiêm ngặt, API được đơn giản hóa, mặc định an toàn

hyprtavern-kv (kho khóa-giá trị bảo mật)

• Là giao thức lõi thay thế Secrets API của D-Bus
  • Bí mật do ứng dụng đăng ký chỉ ứng dụng đó mới có thể đọc, và không thể liệt kê (enumeration)
  • Cũng có kế hoạch kiểm soát truy cập theo ID cho ứng dụng Flatpak, Snap, AppImage
  • Luôn được lưu trữ ở dạng mã hóa, và khi đặt mật khẩu thì có thể bảo đảm bảo mật thực chất
  • Mọi ứng dụng đều có thể mặc định sử dụng chức năng lưu trữ bí mật an toàn

Tình hình phát triển và kế hoạch sắp tới

• hyprtavern vẫn đang ở giai đoạn phát triển ban đầu, và dự kiến sẽ được dùng nội bộ trong Hyprland phiên bản 0.54
• Việc chấp nhận ban đầu có thể sẽ hạn chế, nhưng có thể chuyển đổi dần dần
  • Khác với D-Bus, có thể chạy song song nhiều session bus nên cũng có thể viết proxy tương thích
• Được viết bằng C++, và cũng có thể dễ dàng triển khai binding cho Rust, Go, Python
• Tác giả nhấn mạnh rằng: “D-Bus về căn bản là thứ không thể sửa được, mà phải thiết kế lại hoàn toàn”

Tóm tắt FAQ

• Trước chỉ trích rằng đây là “phát minh lại bánh xe”, tác giả nói thiết kế gốc của D-Bus đã hỏng ngay từ nền tảng nên việc thiết kế lại là điều không thể tránh khỏi
• Tài liệu hiện vẫn ở trạng thái WIP (đang làm dở) và sẽ được công bố sau khi hoàn thiện
• Lý do không dùng Wayland là vì nó không phù hợp cho IPC mục đích chung
• Có thể viết proxy tương thích D-Bus (hyprtavern-dbus-notification-proxy)
• Lý do dùng C++ thay vì Rust là vì ngôn ngữ chính của tác giả là C++
• Về bảo mật, tấn công LD_PRELOAD khó bị chặn hoàn toàn, nhưng đây là cấu trúc làm tăng độ khó tấn công và khả năng bị phát hiện

Kết luận

• D-Bus bị chỉ ra là nút thắt của hệ sinh thái desktop Linux do phi tiêu chuẩn, thiếu bảo mật và thiếu nhất quán
• hyprtavern đang được phát triển như một IPC bus hiện đại và an toàn để thay thế nó, và
  dự kiến sẽ được triển khai dần dần, xoay quanh hệ sinh thái Hyprland
• Mục tiêu là “làm cho userspace dễ chịu hơn”

[GN⁺]

Ý kiến trên Hacker News

• Nhìn tranh cãi về lỗ hổng truy cập kho bí mật của GNOME, thấy buồn cười khi nhóm GNOME phủ nhận vấn đề dựa trên mô hình bảo mật rằng “ứng dụng không đáng tin không thể giao tiếp với dịch vụ bí mật”
  GNOME đúng là trông như một dự án do mấy anh hề vận hành

  • Thật mỉa mai khi Wayland chặn việc chặn bắt sự kiện nhập liệu vì lý do bảo mật, trong khi lại để nguyên những vấn đề kiểu này
  • Tôi vốn nghĩ kho bí mật chỉ là nơi chứa “dữ liệu không nên lưu ở dạng văn bản thuần trên đĩa”. Nếu muốn cô lập giữa các ứng dụng thì dùng máy ảo mới đúng
  • Việc các chương trình chạy dưới quyền người dùng có thể truy cập dữ liệu của cùng người dùng đó là điều hiển nhiên. Nếu đó là lỗ hổng thì coi như toàn bộ Linux đều thủng rồi. xkcd 1200 là ví dụ rất chuẩn cho chuyện này
  • Cuối cùng chắc lại kết thúc bằng kiểu “hành vi dự kiến, không sửa, khóa thảo luận”
  • Giờ nhờ AI mà ta có thể ném toàn bộ mã lên đám mây để kiểm toán (audit) trực tiếp, nên từ nay ai cũng chỉ dùng phần mềm đáng tin được rồi /s

• Có người nói sẽ “tự làm một bus mới”, nên tôi đề xuất thử tái sử dụng Binder, thứ đã được triển khai trên hàng tỷ thiết bị
  Binder là IPC cốt lõi của Android, có nhiều lập trình viên hơn hẳn và lượng mã đã được kiểm chứng lớn hơn nhiều

  • Nếu xây hệ thống mới trên Binder thì sẽ có được một nền tảng vững chắc hơn nhiều. Hơn nữa Google gần đây đã hiện thực Binder cho kernel bằng Rust và đã được merge
    Bài liên quan: LWN, mailing list Rust-for-Linux
  • Tuy vậy, gần như không có bản triển khai không gian người dùng của Binder nào ngoài Android
  • Tôi đã thử tìm “BSD Binder” hay “Windows Binder” nhưng không thấy kết quả nào. Có lẽ cách nói “serious OS” chỉ là đùa thôi
  • Tôi tò mò liệu Binder có thực sự tốt hơn D-Bus không. Muốn biết nó tốt hơn ở điểm nào
  • Biết đâu một ngày nào đó Binder cũng vào desktop Linux. Cùng với Android

• Tôi đã kỳ vọng vào Hyprwire và Hyprtavern, nhưng gần như không có tài liệu hay kiểm thử nào
  Thật tiếc vì những dự án như vậy đáng lẽ có thể là điểm khởi đầu tốt

  • Có vẻ nhà phát triển đang trong giai đoạn thi tốt nghiệp đại học
  • Ngay trong bài cũng nhắc nhiều lần là “vẫn đang chuẩn bị”, nên tôi sẽ đợi xem sau khi hoàn thiện thế nào

• Các nhà phát triển OpenWrt từ lâu đã làm ra một phương án thay thế tên là ubus
  Tham khảo: tài liệu ubus, so sánh ubus vs dbus
  Tuy nhiên nó gần như không có mô hình bảo mật nào, và với đặc thù của OpenWrt thì cũng có lý do để như vậy

• Một trong các vấn đề của D-Bus là các tiện ích mở rộng trình duyệt tạo ra lỗ hổng khi giao tiếp với GNOME/KDE
  Chỉ cần truy cập website thôi cũng có thể làm quá tải API D-Bus đến mức desktop bị treo
  Nếu là nhà nghiên cứu bảo mật thì D-Bus thực sự là một lĩnh vực đáng đào sâu

  • Tôi tò mò “website tích hợp với GNOME hay KDE” thực sự nghĩa là gì
  • Những vấn đề như vậy sẽ không xảy ra trong môi trường VM độc lập

• D-Bus là thứ gần nhất với XPC, COM, Android IPC trên desktop Linux
  Nhưng vì sự phân mảnh desktop nên rất khó tạo ra một stack phát triển thống nhất
  Cái làm cho GNOME thì vô dụng trên KDE, còn XFCE hay Sway lại tách riêng một kiểu

  • KDE trước đây từng dùng IPC riêng là DCOP, nhưng giờ đã thay bằng D-Bus
  • D-Bus đã hơn 20 năm tuổi, giờ cần một cuộc khởi động lại. Nhưng để một IPC mới thành công thì ảnh hưởng xã hội còn quan trọng hơn kỹ thuật
  • KDE trước đây cũng có KParts hơi giống COM
  • Phân mảnh rốt cuộc là hệ quả tự nhiên của việc tồn tại nhiều trường hợp sử dụng khác nhau

• Tôi mới biết lần đầu rằng các kho bí mật như KWallet hay GNOME Keyring trên thực tế, khi đã mở khóa rồi thì mọi ứng dụng đều có thể truy cập
  Dùng GUI seahorse để kiểm tra thì thấy phần lớn chỉ là khóa liên quan đến Chromium hoặc token tài khoản JetBrains
  Không có mật khẩu dạng văn bản thuần, nhưng tôi vẫn nghĩ nếu ứng dụng độc hại đào sâu vào dữ liệu Chromium thì có thể moi ra thêm thứ gì đó

  • Dù sao nếu không phải nhập lại mật khẩu thì nó tất yếu phải tồn tại ở dạng văn bản thuần trong bộ nhớ
    Nếu hệ thống không thông báo khi có truy cập, thì phần mềm nào quản lý chuyện đó cũng chẳng khác nhau mấy

• Có thắc mắc là “tại sao nhất thiết phải cần một giao thức bus đa dụng?”
  Chỉ cần dùng HTTP hoặc giao thức JSON đơn giản trên Unix domain socket là đủ
  Quản lý quyền hạn, SSH forwarding, mount container v.v. đều hỗ trợ được cả
  D-Bus có cấu trúc phức tạp với service, interface, path, method các kiểu nhưng việc định danh message lại không đầy đủ, và vẫn phải biết chi tiết giao thức riêng của từng ứng dụng
  Thành ra xử lý proxy cũng khó, và đây là một hệ thống phức tạp quá mức

• Thiết kế của D-Bus có vẻ là ví dụ cho quy luật tính ngẫu nhiên rằng “giải pháp tốt nhất chưa chắc được chọn”
  Giống như có vô số framework tốt hơn React nhưng vì không nổi tiếng nên bị chìm nghỉm

  • Hiện tượng này thường xảy ra vì mọi người đánh giá khi chưa thực sự hiểu trọn vẹn vấn đề
  • D-Bus nổi lên là nhờ mối liên hệ giữa GNOME và Red Hat
  • Thực ra không tồn tại giải pháp “tốt nhất”; mỗi bên chỉ nằm ở một không gian đánh đổi khác nhau. Nên cẩn trọng với thái độ xem nhẹ công sức của người khác
  • Phần lớn mã nguồn mở đều do tình nguyện viên làm ra. Một vài người bỏ ra hàng nghìn giờ phát triển, nên việc họ quyết định hướng đi là điều tự nhiên. Với cấu trúc như vậy thì các quyết định kỳ quặc cũng là điều khó tránh
  • Giống câu “càng tệ càng tốt”, thực tế là ngay cả quá trình lựa chọn bản thân nó cũng thường diễn ra theo cách kém hiệu quả nhất

• Việc GNOME phản bác báo cáo lỗ hổng rồi nhắc đến giới hạn truy cập sandbox của Flatpak làm tôi nhớ tới bài blog cũ của Microsoft
  Thêm nữa, việc họ chỉ đăng trích dẫn dưới dạng ảnh chụp màn hình khiến người khác không thể sao chép được thì thật sự khó hiểu

  • Wayland chặn chụp màn hình nếu không có quyền root, còn D-Bus thì mở toang theo tinh thần YOLO