ปัญหาของ D-Bus บนเดสก์ท็อปลินุกซ์

 (blog.vaxry.net)
1 คะแนน โดย GN⁺ 2025-12-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • D-Bus คือบัสสำหรับการสื่อสารระหว่างแอปพลิเคชัน ซึ่งแนวคิดนั้นมีประโยชน์ แต่การติดตั้งใช้งานแย่มากและไม่เป็นมาตรฐาน
  • เอกสารมาตรฐานนั้นไม่สมบูรณ์และไม่สอดคล้องกัน และตัวติดตั้งใช้งานจริงก็ไม่ได้ปฏิบัติตาม จนเกิดการพังทลายของความเข้ากันได้
  • ช่องโหว่ด้านความปลอดภัยก็ร้ายแรงเช่นกัน โดยแอปสามารถอ่านข้อมูลลับของแอปอื่นได้เมื่ออยู่ในสถานะปลดล็อก
  • เพื่อตอบสนองต่อปัญหานี้ ผู้เขียนกำลังพัฒนาระบบบัสใหม่ hyprtavern และโปรโตคอล hyprwire
  • hyprtavern พยายามแก้ปัญหาเชิงโครงสร้างของ D-Bus ด้วยการตรวจสอบชนิดข้อมูลอย่างเข้มงวด การจัดการสิทธิ์ที่มีมาในตัว และคลังเก็บความลับแบบปลอดภัย (kv) เป็นต้น

แนวคิดและข้อจำกัดของ D-Bus

  • D-Bus เป็นระบบที่ทำให้แอปพลิเคชันและบริการสามารถเปิดเผยเมธอดและพร็อพเพอร์ตี รวมถึงเรียกใช้งานกันผ่านบัส (bus) ที่ใช้ร่วมกันได้
    • ตัวอย่างเช่น หากแอปที่ให้บริการข้อมูลสภาพอากาศลงทะเบียน API ไว้บนบัส แอปอื่นก็สามารถค้นหาและใช้งานได้
  • แต่ D-Bus มีการออกแบบที่ผ่อนปรนเกินไปและขาดโครงสร้าง ทำให้สามารถลงทะเบียนหรือเรียกใช้ออบเจ็กต์ใด ๆ พร้อมเมธอดตามอำเภอใจได้
    • จึงเกิดปรากฏการณ์ “Garbage in, garbage out”

ความสับสนของเอกสารมาตรฐานและการติดตั้งใช้งาน

  • เอกสารมาตรฐานของ D-Bus กระจัดกระจายอยู่หลายแห่ง และอยู่ในสภาพที่ยังไม่สมบูรณ์และเข้าใจยาก
    • ตัวติดตั้งใช้งานจริงจำนวนมากไม่ปฏิบัติตาม หรือเลือกใช้ข้อกำหนดที่แตกต่างกันไปตามอำเภอใจ
  • ผู้เขียนอธิบายว่า ระหว่างพัฒนา xdg-desktop-portal-hyprland เขาได้ติดตั้งใช้งานสเปก restore_token แต่
    ทุกแอปกลับใช้ฟิลด์ restore_data ที่ไม่เป็นทางการ จึงทำให้ใช้งานร่วมกันไม่ได้
  • ชนิด variant (a{sv}) ของ D-Bus อนุญาตให้ส่งข้อมูลแบบใดก็ได้ จึงถูกชี้ว่าเป็นสาเหตุหลักที่ทำลายความสม่ำเสมอของโปรโตคอล

ข้อบกพร่องของโครงสร้างด้านความปลอดภัย

  • D-Bus ไม่มีการจัดการสิทธิ์แบบรวมศูนย์หรือกลไกการปฏิเสธ
    • ทุกแอปสามารถเห็นการเรียกใช้งานของแอปอื่นได้ และหากไม่มีมาตรการความปลอดภัยที่ชัดเจน ก็สามารถเข้าถึงได้อย่างไม่จำกัด
  • คลังเก็บความลับอย่าง gnome-keyring, kwallet ก็เปราะบางในเชิงโครงสร้างเช่นกัน
    • เมื่อคลังถูกปลดล็อก ทุกแอปจะเข้าถึงข้อมูลลับทั้งหมดได้
    • ผู้เขียนเรียกสิ่งนี้ว่า “อยู่ในระดับมุกตลกด้านความปลอดภัย”

ทางเลือกใหม่: hyprwire และ hyprtavern

  • ผู้เขียนกำลังพัฒนาระบบบัสใหม่ hyprtavern เพื่อแก้ปัญหาของ D-Bus
    • hyprwire คือโปรโตคอล wire ที่กระชับและสม่ำเสมอ ซึ่งได้แรงบันดาลใจจากการออกแบบของ Wayland
      • มีจุดเด่นคือการบังคับชนิดข้อมูล การเชื่อมต่อที่รวดเร็ว และโครงสร้างที่เรียบง่าย
    • hyprtavern ใช้โครงสร้างที่ให้แอปลงทะเบียนออบเจ็กต์ตามโปรโตคอลและค้นหากันและกันได้
      • มีทั้งระบบสิทธิ์ในตัว การปฏิบัติตามโปรโตคอลอย่างเข้มงวด API ที่เรียบง่ายขึ้น และค่าปริยายที่ปลอดภัย

hyprtavern-kv (คลังเก็บคีย์-ค่าแบบปลอดภัย)

  • เป็นโปรโตคอลหลัก (core) ที่ใช้แทน Secrets API ของ D-Bus
    • ความลับที่แอปลงทะเบียนไว้จะอ่านได้เฉพาะโดยแอปนั้นเท่านั้น และไม่สามารถไล่ดูรายการทั้งหมด (enumeration) ได้
    • ยังมีแผนเพิ่มการควบคุมการเข้าถึงตาม ID สำหรับแอป Flatpak, Snap และ AppImage
    • ข้อมูลจะถูกเก็บแบบเข้ารหัสเสมอ และหากตั้งรหัสผ่านไว้ก็สามารถรับประกันความปลอดภัยที่ใช้งานได้จริง
    • ทุกแอปจะสามารถใช้ความสามารถของคลังเก็บความลับที่ปลอดภัยได้เป็นค่าปริยาย

สถานะการพัฒนาและแผนในอนาคต

  • hyprtavern ยังอยู่ในระยะเริ่มต้นของการพัฒนา และมีแผนจะถูกนำไปใช้ภายในใน Hyprland เวอร์ชัน 0.54
  • คาดว่าการนำไปใช้ในช่วงแรกจะยังจำกัด แต่สามารถเปลี่ยนผ่านแบบค่อยเป็นค่อยไปได้
    • ต่างจาก D-Bus ตรงที่สามารถรันเซสชันบัสหลายตัวคู่ขนานกันได้ จึงสามารถเขียนพร็อกซีเพื่อความเข้ากันได้เช่นกัน
  • เขียนด้วย C++ และยังสามารถทำ binding สำหรับ Rust, Go และ Python ได้ไม่ยาก
  • ผู้เขียนย้ำว่า “D-Bus นั้นแก้ไขจากรากฐานไม่ได้ และต้องออกแบบใหม่ทั้งหมด”

สรุป FAQ

  • ต่อคำวิจารณ์ว่าเป็นการ “ประดิษฐ์ล้อขึ้นมาใหม่” ผู้เขียนระบุว่า การออกแบบพื้นฐานของ D-Bus พังตั้งแต่ต้น จึงเลี่ยงการออกแบบใหม่ไม่ได้
  • เอกสารในตอนนี้ยังอยู่ในสถานะ WIP (อยู่ระหว่างดำเนินการ) และจะเปิดเผยเมื่อเสร็จสมบูรณ์
  • เหตุผลที่ไม่ใช้ Wayland คือไม่เหมาะกับการใช้เป็น IPC ทั่วไป
  • สามารถเขียน D-Bus compatibility proxy (hyprtavern-dbus-notification-proxy) ได้
  • เหตุผลที่ใช้ C++ แทน Rust คือภาษา主ที่ผู้พัฒนาใช้คือ C++
  • ในแง่ความปลอดภัย การโจมตีแบบ LD_PRELOAD อาจกันได้ไม่สมบูรณ์ แต่เป็นโครงสร้างที่เพิ่มความยากในการโจมตีและโอกาสในการตรวจจับ

บทสรุป

  • D-Bus ถูกชี้ว่าเป็นคอขวดของระบบนิเวศเดสก์ท็อปลินุกซ์ เนื่องจากมีลักษณะไม่เป็นมาตรฐาน ไม่ปลอดภัย และไม่สม่ำเสมอ
  • hyprtavern กำลังถูกพัฒนาให้เป็นบัส IPC ที่ทันสมัยและปลอดภัยเพื่อมาแทนที่สิ่งนี้ และ
    คาดว่าจะมีการนำไปใช้แบบค่อยเป็นค่อยไปโดยมีระบบนิเวศของ Hyprland เป็นศูนย์กลาง
  • เป้าหมายคือ “ทำให้ userspace น่าใช้งานยิ่งขึ้น”

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-12-17
ความเห็นบน Hacker News

  • พอเห็นประเด็นถกเถียงเรื่อง ช่องโหว่การเข้าถึงที่เก็บข้อมูลลับ ของ GNOME ก็อดขำไม่ได้ที่ทีม GNOME ปฏิเสธปัญหาโดยอ้างโมเดลความปลอดภัยว่า “แอปที่ไม่เชื่อถือไม่สามารถสื่อสารกับบริการเก็บความลับได้”
    รู้สึกว่า GNOME เป็นโครงการที่บริหารโดยพวก ตัวตลก จริงๆ

    • น่าขันตรงที่ Wayland บล็อกการดักจับ input event ด้วยเหตุผลด้านความปลอดภัย แต่ปัญหาแบบนี้กลับปล่อยไว้เหมือนเดิม
    • ผมเคยมองที่เก็บข้อมูลลับว่าเป็นแค่ “ข้อมูลที่ไม่ควรเก็บเป็นข้อความล้วนบนดิสก์” ถ้าอยากได้การแยกแอประหว่างกันจริงๆ ก็ควรใช้ เครื่องเสมือน
    • โปรแกรมที่รันด้วยสิทธิ์ของผู้ใช้เดียวกันจะเข้าถึงข้อมูลของผู้ใช้คนนั้นได้ก็เป็นเรื่องปกติอยู่แล้ว ถ้านั่นนับเป็นช่องโหว่ ก็แปลว่าลินุกซ์ทั้งระบบพังหมดแล้ว xkcd 1200 ก็เปรียบได้ตรงมาก
    • สุดท้ายก็คงจบแบบ “เป็นพฤติกรรมที่ตั้งใจไว้, จะไม่แก้, ล็อกการสนทนา”
    • ทุกวันนี้ด้วยพลังของ AI เราสามารถโยนโค้ดทั้งหมดขึ้นคลาวด์แล้ว audit ได้เอง เพราะงั้นจากนี้ทุกคนก็จะใช้แต่ซอฟต์แวร์ที่เชื่อถือได้เท่านั้น /s

  • มีคนบอกว่าจะ “ทำ bus ตัวใหม่ขึ้นมาเอง” ผมเลยเสนอว่าเอา Binder ที่ถูกแจกจ่ายไปแล้วบนอุปกรณ์นับพันล้านเครื่องมาใช้ซ้ำดีไหม
    Binder คือ IPC แกนหลักของแอนดรอยด์ และมีทั้งนักพัฒนามากกว่าและโค้ดที่ผ่านการพิสูจน์มาแล้วมากกว่ามาก

    • ถ้าสร้างระบบใหม่บน Binder ก็น่าจะได้ ฐานรากที่แข็งแรงกว่า แถม Google เพิ่งทำ Binder สำหรับเคอร์เนลด้วย Rust แล้ว merge เข้าไปแล้วด้วย
      บทความที่เกี่ยวข้อง: LWN, Rust-for-Linux mailing list
    • แต่ implementation ของ Binder ใน user space นอกแอนดรอยด์แทบไม่มีเลย
    • ผมลองค้นหา “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 เคยใช้ IPC ของตัวเองชื่อ DCOP มาก่อน แต่ตอนนี้เปลี่ยนมาใช้ D-Bus แล้ว
    • D-Bus มีอายุมากกว่า 20 ปีแล้ว ถึงเวลา รีบูต ได้แล้ว แต่ถ้า IPC ตัวใหม่จะสำเร็จ ปัจจัยสำคัญกว่าเทคนิคก็คือ อิทธิพลทางสังคม
    • KDE ยังเคยมี KParts ที่คล้ายกับ COM ด้วย
    • สุดท้ายความแตกกระจายก็เป็นผลตามธรรมชาติจากการที่มีกรณีใช้งานหลากหลายอยู่แล้ว

  • เพิ่งรู้เป็นครั้งแรกว่าที่เก็บข้อมูลลับอย่าง KWallet หรือ GNOME Keyring นั้น ถ้าอยู่ในสถานะปลดล็อกแล้ว แอปไหนๆ ก็เข้าถึงได้แทบทั้งหมด
    พอลองดูผ่าน GUI ของ seahorse ก็เห็นว่าส่วนใหญ่เป็น คีย์ที่เกี่ยวกับ Chromium หรือโทเค็นบัญชี JetBrains
    ไม่มีรหัสผ่านแบบข้อความล้วน แต่ก็อดคิดไม่ได้ว่าถ้าเป็นแอปอันตรายไปคุ้ยข้อมูล Chromium ต่อ ก็คงเจออะไรเพิ่มได้อีก

    • ยังไงถ้าเราไม่ได้ป้อนรหัสผ่านทุกครั้ง มันก็ต้องมีอยู่ในหน่วยความจำแบบข้อความล้วนอยู่ดี
      ถ้าระบบไม่แจ้งเตือนเวลามีการเข้าถึง ต่อให้ซอฟต์แวร์ไหนเป็นคนจัดการก็แทบไม่ต่างกันมาก

  • มีคำถามว่า “ทำไมต้องมี โปรโตคอล bus แบบใช้งานทั่วไป ด้วย?”
    แค่ใช้ HTTP หรือโปรโตคอล JSON ง่ายๆ บน Unix domain socket ก็น่าจะพอแล้ว
    ทั้งการจัดการสิทธิ์, SSH forwarding, การ mount แบบคอนเทนเนอร์ ก็รองรับได้หมด
    D-Bus มีทั้ง service, interface, path, method และโครงสร้างที่ซับซ้อน แต่การระบุข้อความกลับยังไม่สมบูรณ์ และยังต้องรู้รายละเอียดโปรโตคอลของแต่ละแอปด้วย
    สุดท้ายเลย ทำ proxy ได้ยาก และเป็นระบบที่ซับซ้อนเกินจำเป็น

  • การออกแบบของ D-Bus ดูเหมือนเป็นตัวอย่างของ กฎแห่งความสุ่ม ที่ว่า “ทางออกที่ดีที่สุดไม่ได้ถูกเลือกเสมอไป”
    เหมือนกับที่มีเฟรมเวิร์กจำนวนมากดีกว่า React แต่ไม่เป็นที่รู้จักจนหายไป

    • ปรากฏการณ์แบบนี้มักเกิดจากคนประเมินโดยยังไม่เข้าใจปัญหาอย่างถ่องแท้
    • ที่ D-Bus ดังขึ้นมาได้ก็เพราะ ความเชื่อมโยงระหว่าง GNOME กับ Red Hat
    • ที่จริงแล้วไม่มีทางออกที่ “ดีที่สุด” แบบสากล มีแต่แต่ละทางที่อยู่คนละ พื้นที่ของ trade-off เท่านั้น จึงควรระวังท่าทีที่มองข้ามความพยายามของคนอื่น
    • โอเพนซอร์สส่วนใหญ่สร้างโดย อาสาสมัคร คนไม่กี่คนทุ่มเวลาหลายพันชั่วโมงพัฒนา ดังนั้นก็เป็นธรรมดาที่พวกเขาจะเป็นคนกำหนดทิศทาง และในโครงสร้างแบบนี้การตัดสินใจแปลกๆ ก็ย่อมเกิดขึ้นได้
    • อย่างที่ว่า “แย่กว่ากลับดีกว่า” ความจริงคือแม้แต่กระบวนการคัดเลือกเองก็มักดำเนินไปในวิธีที่ไร้ประสิทธิภาพที่สุด

  • การที่ GNOME โต้แย้งรายงานช่องโหว่พร้อมยกข้อจำกัดการเข้าถึง sandbox ของ Flatpak ขึ้นมา ทำให้นึกถึง บล็อกโพสต์เก่าของ Microsoft
    แถมยังเอาคำพูดที่อ้างอิงมาแปะเป็น ภาพหน้าจอ อย่างเดียวจนคัดลอกไม่ได้อีก เข้าใจไม่ได้จริงๆ

    • Wayland บล็อกภาพหน้าจอหากไม่มีสิทธิ์ root แต่ D-Bus กลับเปิดกว้างแบบ YOLO