डी-बस प्रमाणीकरण और प्राधिकरण

Question

मैं डी-बस तक रिमोट एक्सेस स्थापित करने की कोशिश कर रहा हूं, और मुझे समझ नहीं आ रहा है कि प्रमाणीकरण और प्राधिकरण कैसे काम कर रहे हैं (नहीं)।

मेरे पास डी-बस सर्वर एक अमूर्त सॉकेट पर सुन रहा है।

$ echo $DBUS_SESSION_BUS_ADDRESS 
unix:abstract=/tmp/dbus-g5sxxvDlmz,guid=49bd93b893fe40d83604952155190c31

मैं dbus-monitorदेखता हूं कि क्या चल रहा है। मेरा परीक्षण मामला है notify-send hello, जो स्थानीय मशीन से निष्पादित होने पर काम करता है।

उसी मशीन पर दूसरे खाते से, मैं उस बस से कनेक्ट नहीं कर सकता।

otheraccount$ DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-g5sxxvDlmz,guid=49bd93b893fe40d83604952155190c31 dbus-monitor
Failed to open connection to session bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
otheraccount$ DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-g5sxxvDlmz,guid=49bd93b893fe40d83604952155190c31 notify-send hello

डी-बस विनिर्देशन ब्राउज़ करने के बाद , मैंने ~/.dbus-keyrings/org_freedesktop_generalदूसरे खाते में प्रतिलिपि बनाई , लेकिन यह मदद नहीं करता है।

मैंने टीसीपी पर डी-बस सॉकेट को अग्रेषित करने की कोशिश की, जो कि सोटर का उपयोग करते हुए दूर से बस के एक्सेस डी-बस से प्रेरित है ।

socat TCP-LISTEN:8004,reuseaddr,fork,range=127.0.0.1/32 ABSTRACT-CONNECT:/tmp/dbus-g5sxxvDlmz

मैं अपने खाते से टीसीपी सॉकेट से कनेक्ट कर सकता हूं।

DBUS_SESSION_BUS_ADDRESS=tcp:host=127.0.0.1,port=8004 notify-send hello

लेकिन दूसरे खाते से, न तो साथ dbus-monitorऔर न ही साथ notify-send। dbus-monitorसार सॉकेट के साथ ऊपर के लिए एक ही त्रुटि संदेश ; notify-sendअब एक निशान का उत्सर्जन करता है:

otheraccount$ DBUS_SESSION_BUS_ADDRESS=tcp:host=127.0.0.1,port=8004 notify-send hello

** (notify-send:2952): WARNING **: The connection is closed

स्ट्रिंग्स से पता चलता है कि यह संस्करण notify-sendकुकी फ़ाइल को पढ़ने की कोशिश नहीं करता है, इसलिए मैं समझता हूं कि यह कनेक्ट करने में सक्षम क्यों नहीं होगा।

मैंने दूसरी मशीन में SSHing और TCP कनेक्शन को अग्रेषित करने का भी प्रयास किया।

ssh -R 8004:localhost:8004 remotehost

हैरानी की बात है, dbus-monitorएक कुकी फ़ाइल के बिना काम करता है! मैं दूरस्थ मेजबान से डी-बस यातायात देख सकता हूं। मैं अपने स्थानीय dbus-monitorउदाहरण में ईव्सड्रॉपिंग के बारे में एक नोटिस देखता हूं ।

remotehost$ DBUS_SESSION_BUS_ADDRESS=tcp:host=127.0.0.1,port=8004 dbus-monitor
signal sender=org.freedesktop.DBus -> dest=:1.58 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.58"
method call sender=:1.58 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "eavesdrop=true"

अगर मैं notify-sendस्थानीय मशीन पर चलता हूं , dbus-monitorतो रिमोट होस्ट पर अधिसूचना देखता है। यह निश्चित रूप से पहुंच के स्तर तक पहुंच गया है जिसे प्रमाणीकरण की आवश्यकता होनी चाहिए।

notify-sendकुकी नहीं मिलने की शिकायत की। कुकी फ़ाइल की प्रतिलिपि बनाने के बाद, notify-sendरिमोट मशीन से काम करता है।

स्थानीय मशीन डेबियन wheezy चलाता है। रिमोट मशीन फ्रीबीएसडी 10.1 चलाता है।

मुझे समझ में नहीं आता कि डी-बस प्रमाणीकरण और प्राधिकरण कैसे काम करते हैं।

1. मैं दूरस्थ रूप से मशीन से कोई प्रमाणिकता के साथ, जहां तक ​​मैं बता सकता हूं, क्यों छिप सकते हैं? जब मैं डी-बस को टीसीपी कनेक्शन के लिए आगे बढ़ाता हूं तो मैं क्या उजागर कर रहा हूं? के लिए प्राधिकरण dbus-monitorऔर notify-sendअलग - अलग क्यों हैं ?
2. मैं एक ही मशीन पर किसी अन्य खाते से क्यों नहीं देख सकता, चाहे सार सॉकेट पर या टीसीपी कनेक्शन पर?
3. मैंने देखा कि कुकी फ़ाइल हर कुछ मिनटों में बदलती है (मुझे पता नहीं है कि यह नियमित अंतराल पर है या नहीं)। क्यों?

(मुझे पता है कि मैं एक डी-बस डेमॉन लॉन्च कर सकता हूं जो टीसीपी पर सुनता है। यह मेरे सवाल का उद्देश्य नहीं है, मैं समझना चाहता हूं कि मैंने क्या किया और काम नहीं किया।)

Answer 1

D- बस यहां मैजिक कुकी फ़ाइल का उपयोग नहीं कर रहा है; यह UNIX डोमेन सॉकेट ( SCM_CREDENTIALS) पर क्रेडेंशियल पास कर रहा है ।

मैजिक कुकी फ़ाइल कई डी-बस प्रमाणीकरण तंत्रों में से एक है। डी-बस एक को लागू करता है SASL -compliant इंटरफेस (देखें RFC4422 ) प्रमाणीकरण तंत्र की एक विस्तृत श्रृंखला का समर्थन करने के। इन तंत्रों में से एक को "बाहरी" प्राधिकरण कहा जाता है, और इसका मतलब है कि प्रमाणीकरण की गारंटी के लिए परिवहन चैनल का ही उपयोग किया जाना चाहिए। कम से कम यूनिक्स सॉकेट्स पर डी-बस के मामले में, यह पहला प्रमाणीकरण तंत्र प्रतीत होता है जिसे आजमाया जाता है।

डी-बस कल्पना से:

विशेष क्रेडेंशियल्स-पासिंग न्यूल बाइट

सर्वर से कनेक्ट करने के तुरंत बाद, क्लाइंट को एक सिंगल बाइट भेजना होगा। यह बाइट UNIX डोमेन सॉकेट पर क्रेडेंशियल्स पास करने के लिए SCM_CREDS या SCM_CREDENTIALS के साथ sendmsg () का उपयोग करने वाले कुछ ऑपरेटिंग सिस्टम पर क्रेडेंशियल जानकारी के साथ हो सकता है। हालाँकि, अन्य प्रकार के सॉकेट पर भी न्यूल बाइट भेजा जाना चाहिए, और यहां तक ​​कि ऑपरेटिंग सिस्टम पर भी, जिसे क्रेडेंशियल्स संचारित करने के लिए बाइट भेजने की आवश्यकता नहीं है। इस दस्तावेज़ में वर्णित पाठ प्रोटोकॉल एकल नल बाइट के बाद शुरू होता है। यदि क्लाइंट से प्राप्त पहली बाइट एक शून्य बाइट नहीं है, तो सर्वर उस क्लाइंट को डिस्कनेक्ट कर सकता है।

प्रारंभिक बाइट के अलावा किसी भी संदर्भ में एक शून्य बाइट एक त्रुटि है; प्रोटोकॉल केवल ASCII है।

Nul बाइट के साथ भेजे गए क्रेडेंशियल्स का उपयोग SASL तंत्र EXTERNAL के साथ किया जा सकता है।

यदि आप इसका उदाहरण देते हैं dbus-daemon, तो आप देख सकते हैं कि जब आप इसे कनेक्ट करते हैं, तो यह कनेक्ट करने वाले उपयोगकर्ता की साख की जाँच करता है:

$ strace dbus-daemon --session --nofork
...
accept4(4, {sa_family=AF_LOCAL, NULL}, [2], SOCK_CLOEXEC) = 8
...
recvmsg(8, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}], msg_controllen=0, msg_flags=0}, 0) = 1
getsockopt(8, SOL_SOCKET, SO_PEERCRED, {pid=6694, uid=1000, gid=1000}, [12]) = 0

तो आपके सवालों का जवाब देने के लिए:

1. डी-बस डेमॉन आपकी पहचान को सत्यापित करने के लिए आपकी कर्नेल-सत्यापित उपयोगकर्ता आईडी का उपयोग कर रहा है। socatप्रॉक्सी कनेक्शन का उपयोग करके , आप अपने यूआईडी का उपयोग करके किसी को भी डी-बस डेमॉन से कनेक्ट करने दे रहे हैं।

2. यदि आप किसी अन्य UID से सॉकेट से सीधे कनेक्ट करने का प्रयास करते हैं, तो डेमन यह स्वीकार करता है कि कनेक्टिंग UID एक UID नहीं है जिसे कनेक्ट करने की अनुमति दी जानी चाहिए। मेरा मानना ​​है कि डिफ़ॉल्ट यह है कि केवल डेमन के स्वयं के यूआईडी की अनुमति है, लेकिन औपचारिक रूप से सत्यापित नहीं किया गया है। आप अन्य उपयोगकर्ताओं को अनुमति दे सकते हैं, हालांकि: कॉन्फ़िगरेशन फ़ाइलों को अंदर /etc/dbus-1/और भी देखें man dbus-daemon।

3. यह डी-बस सर्वर पुराने / समाप्त कुकीज़ को नए के साथ बदल रहा है। डी-बस कल्पना के DBUS_COOKIE_SHA1 अनुभाग के अनुसार , एक कुकी अपने निर्माण समय के साथ संग्रहीत की जाती है, और सर्वर कुकीज़ को हटाने के लिए माना जाता है कि यह बहुत पुराना है। जाहिरा तौर पर जीवनकाल "काफी कम हो सकता है"।

Comments

डी-बस का संदर्भ कार्यान्वयन SCM_CREDENTIALSविशेष रूप से उपयोग नहीं करता है। लिनक्स पर, यह SO_PEERCREDइसके बजाय सॉकेट विकल्प का उपयोग करता है ।

— वासिलि फरोनोव

@VasiliyFaronov आप सही हैं - कितना दिलचस्प! इसके अलावा, ऐसा लगता है कि उपयोग SCM_CREDENTIALSकरने से इस तरह के एक सरल प्रॉक्सी को रोका जा सकता है, क्योंकि इसमें प्रेषक को सक्रिय रूप से अपनी साख प्रस्तुत करने की आवश्यकता होती है, जबकि SO_PEERCREDकेवल यह जांचता है कि कनेक्शन किसने बनाया था। मुझे आश्चर्य है कि उन्होंने यह चुनाव क्यों किया।

— 14

जाहिरा तौर पर क्योंकि यह "सहकर्मी के सहयोग की आवश्यकता नहीं है," इसलिए "यह बहुत कम नाजुक है" (टिप्पणियों से dbus-sysdeps-unix.c)।

— वासिली फरोनोव