manaswijaiswal/reproducing-connman-1.34CVE-2017-12865 استغلال
مدير الاتصال
حقوق النشر (C) 2007-2012 شركة إنتل. جميع الحقوق محفوظة.
الميزات التالية مدمجة في Connection Manager: - بنية تحتية عامة للإضافات - تجريد للأجهزة والشبكات (مع دعم تخزين أساسي) - IPv4 و IPv4-LL (محلي الارتباط) و DHCP - كشف تعارض عناوين IPv4 (ACD) وفقًا لـ RFC 5227 - IPv6 و DHCPv6 وأنفاق 6to4 - توجيه متقدم وتكوين DNS - وكيل DNS مدمج وتخزين مؤقت ذكي - تسجيلات الدخول إلى نقاط الاتصال الساخنة WISPr واكتشاف البوابة المدمجين - تكوين الوقت والمنطقة الزمنية (يدويًا وتلقائيًا باستخدام NTP) - معالجة الوكيل (يدويًا وتلقائيًا باستخدام WPAD) - دعم التوصيل المشترك (وضع نقطة الوصول USB و Bluetooth و WiFi) - معالجة إحصاءات مفصلة (محلية وتجوال)
يمكن تمكين إضافات متنوعة لدعم الشبكات: - إضافة Ethernet - إضافة WiFi مع WEP40/WEP128 و WPA/WPA2 (شخصي ومؤسسي) - إضافة Bluetooth (باستخدام BlueZ) - إضافة 2G/3G/4G (باستخدام oFono)
كما تتوفر إضافات ذات ميزات إضافية: - إعداد واجهة Loopback - معالجة الوكيل عبر PACrunner - دعم التفويض عبر PolicyKit
لاحظ أنه عند بدء ConnMan، فإنه يمسح جميع واجهات الشبكة التي سيتم استخدامها. إذا لم يكن ذلك مرغوبًا، يمكن تجاهل واجهات الشبكة إما عن طريق تعيين NetworkInterfaceBlacklist في ملف التكوين main.conf أو باستخدام خيار سطر الأوامر -I.
لتجميع Connection Manager تحتاج إلى حزم البرامج التالية: - مترجم GCC - مكتبة GLib - مكتبة D-Bus - مكتبة IP-Tables (لدعم التوصيل المشترك) - مكتبة GnuTLS (اختياري) - PolicyKit (اختياري) - readline (عميل سطر الأوامر)
لتكوين تشغيل: ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
يبحث التكوين تلقائيًا عن جميع المكونات والحزم المطلوبة.
لتجميع وتثبيت تشغيل: make && make install
لكي يعمل النظام بشكل صحيح، يجب تمكين بعض خيارات التكوين:
--disable-ethernet
تعطيل دعم بطاقات الشبكة الإيثرنت
افتراضيًا، يكون دعم تقنية الإيثرنت مدمجًا ومفعلًا.
يمكن استخدام هذا الخيار لبناء خفيض (daemon) صغير
لنظام معين إذا لم يكن دعم الإيثرنت مطلوبًا.
--disable-gadget
تعطيل دعم أجهزة USB Ethernet Gadget
افتراضيًا، يكون دعم تقنية USB Ethernet Gadget مدمجًا ومفعلًا.
يمكن استخدام هذا الخيار لبناء خفيض صغير
لنظام معين إذا لم يكن دعم USB Ethernet Gadget مطلوبًا.
--disable-wifi
تعطيل دعم أجهزة WiFi
افتراضيًا، يكون دعم تقنية WiFi مدمجًا ومفعلًا.
يمكن استخدام هذا الخيار لبناء خفيض صغير
لنظام معين إذا لم يكن دعم WiFi مطلوبًا.
من الآمن بناء خفيض مع دعم WiFi دون تشغيل
wpa_supplicant. يتم اكتشاف بدء wpa_supplicant
تلقائيًا وهو مجرد تبعية وقت التشغيل. لا حاجة له
لبناء ConnMan.
--disable-bluetooth
تعطيل دعم أجهزة Bluetooth
افتراضيًا، يكون دعم تقنية Bluetooth مدمجًا ومفعلًا.
يمكن استخدام هذا الخيار لبناء خفيض صغير
لنظام معين إذا لم يكن دعم Bluetooth مطلوبًا.
من الآمن بناء خفيض مع دعم Bluetooth دون تشغيل
bluetoothd. يتم اكتشاف بدء bluetoothd تلقائيًا
وهو مجرد تبعية وقت التشغيل. لا حاجة له
لبناء ConnMan.
--disable-ofono
تعطيل دعم أجهزة الخلوي 2G/3G/4G
افتراضيًا، يكون دعم تقنية oFono مدمجًا ومفعلًا.
يمكن استخدام هذا الخيار لبناء خفيض صغير
لنظام معين حيث لا يتم استخدام oFono.
من الآمن بناء خفيض مع دعم oFono دون تشغيل
ofonod. يتم اكتشاف بدء ofonod تلقائيًا
وهو مجرد تبعية وقت التشغيل. لا حاجة له
لبناء ConnMan.
--disable-dundee
تعطيل دعم أجهزة Bluetooth DUN
افتراضيًا، يكون دعم تقنية Bluetooth DUN (dundee)
مدمجًا ومفعلًا. يمكن استخدام هذا الخيار لبناء
خفيض صغير لنظام معين حيث لا يتم استخدام dundee.
من الآمن بناء خفيض مع دعم dundee دون تشغيل
dundee. يتم اكتشاف بدء dundee تلقائيًا
وهو مجرد تبعية وقت التشغيل. لا حاجة له
لبناء ConnMan.
--enable-iwd
تمكين دعم الخفيض اللاسلكي لنظام Linux (IWD)
مشروع IWD لم يصدر إصدارًا أوليًا حتى الآن،
لذلك افتراضيًا لا يتم تمكين دعم IWD.
من الآمن تمكين هذا الخيار مع دعم WiFi.
--disable-pacrunner
تعطيل دعم معالجة الوكيل عبر PACrunner
افتراضيًا، يكون دعم PACrunner مدمجًا ومفعلًا. هذا
الخيار يمكن استخدامه لبناء خفيض صغير لنظام معين
حيث لا يتم استخدام PACrunner.
من الآمن بناء خفيض مع دعم PACrunner دون
خفيض pacrunner. سيكتشف ويبدأ عملية PACrunner
إذا لزم الأمر في وقت التشغيل. لا حاجة لوجوده
لبناء ConnMan.
--disable-loopback
تعطيل إعداد جهاز Loopback
لتوزيعات ذات نظام init صغير جدًا وبدون
سكربتات شبكات، يمكن لهذا الخيار العناية بإعداد
جهاز Loopback وتمكينه.
من الآمن ترك هذا الخيار محددًا حتى مع وجود
سكربتات شبكات. يكتشف جهاز Loopback الذي تم
تكوينه بالفعل ويتركه كما هو.
--disable-wispr
تعطيل دعم تسجيلات الدخول إلى نقاط الاتصال الساخنة WISPr
للأنظمة ذات متطلبات ذاكرة صغيرة جدًا، سيعطل هذا
دعم تسجيلات الدخول إلى نقاط الاتصال الساخنة WISPr.
سيظل كود WISPr مترجمًا داخل الخفيض، لكن
ستتم إزالة اعتماده على GnuTLS للاتصالات الآمنة.
يؤدي عدم وجود دعم GnuTLS إلى تقليص متطلبات الذاكرة
بحوالي 30%، وبالنسبة للأنظمة الأكثر ثباتًا التي لا
تسجل الدخول إلى نقاط الاتصال الساخنة قد تكون هذه مقايضة أفضل.
تعطيل دعم WISPr لا يعني تعطيل دعم اكتشاف البوابة.
ستظل البوابة تُكتشف، ولكن بدلاً من طلب
بيانات اعتماد تسجيل الدخول، سيتم إجراء طلب جلسة متصفح
عبر الوكيل.
--enable-polkit
تمكين دعم التفويض عبر PolicyKit
يسمح هذا بالتحقق من كل وصول D-Bus مقابل سياسة
أمان وبالتالي تقييد الوصول إلى وظائف معينة.
--enable-nmcompat
تمكين دعم واجهات التوافق مع NetworkManager
يسمح هذا بعرض مجموعة دنيا من واجهات
NetworkManager. مفيد للأنظمة ذات التطبيقات
المكتوبة لاستخدام NetworkManager للكشف عن حالة
الاتصال/الانقطاع والتي لم يتم تحويلها بعد لاستخدام ConnMan.
--disable-client
تعطيل دعم عميل سطر الأوامر
افتراضيًا، يتم تمكين عميل سطر الأوامر ويستخدم
مكتبة readline. للأنظمة المحددة التي يتم فيها
تكوين ConnMan بوسائل أخرى، يمكن تعطيل عميل سطر الأوامر
وإزالة الاعتماد على readline.
--enable-selinux
تمكين دعم تجميع قواعد فرض نوع SELinux
قواعد TE ضرورية إذا كانت البيئة المضيفة في وضع
الإجبار (enforcing). بدون هذا الخيار، لا يمكن لعملية
عميل VPN إرسال إشعار إلى connman-vpnd عبر واجهة
net.connman.Task. يجب أيضًا تثبيت الوحدة المترجمة
connman-task.pp باستخدام هذا الأمر
# semodule -i connman-task.pp
لتمكين الوصول إلى dbus.
--with-dns-backend=TYPE
تمكين دعم خلفية لحل DNS
اختر خلفية DNS لاستخدامها. القيم المدعومة هي "internal"
و "systemd-resolved". إذا تم تحديد "internal"، سيتم بناء
ConnMan مع وكيل DNS للتخزين المؤقت. إذا تم تحديد
"systemd-resolved"، يقوم ConnMan بتكوين systemd-resolved
لحل DNS. القيمة الافتراضية هي "internal".
يمكن تفعيل طباعة التصحيح في ConnMan باستخدام خيار سطر الأوامر -d. إذا لم يكن للخيار -d معاملات، يتم تنشيط التصحيح لجميع ملفات الكود المصدري. إذا كان للخيار -d معاملات، فإنها تحدد ملفات الكود المصدري التي يتم تفعيل التصحيح فيها. يمكن استخدام بطاقات البدل في أسماء الملفات. مثال: -d تفعيل جميع طباعات التصحيح العادية -d src/service.c يطبع معلومات التصحيح من ملف src/service.c فقط -d src/network.c:src/ipconfig.c يفعل طباعات التصحيح في ملفي src/network.c و src/ipconfig.c. -d 'src/n*.c' سيفعل طباعة التصحيح من جميع ملفات C التي تبدأ بالحرف 'n' في دليل src. لاحظ علامات الاقتباس حول الخيار، وذلك لمنع توسيع الصدفة. -d '/n.c:/i.c' يفعل طباعات التصحيح لجميع ملفات C التي تبدأ بالحرفين 'n' أو 'i' في أي دليل فرعي.
بعض مكونات ConnMan بها طباعات تصحيح مفعلة عبر متغيرات البيئة. إذا تم تعيين متغير البيئة، فستطبع المكونات المقابلة بعض معلومات التصحيح الإضافية. يمكن استخدام متغيرات البيئة التالية: CONNMAN_DHCP_DEBUG معلومات تصحيح متعلقة بـ DHCPv4 CONNMAN_DHCPV6_DEBUG معلومات تصحيح متعلقة بـ DHCPv6 CONNMAN_IPTABLES_DEBUG معلومات إضافية عند استخدام iptables CONNMAN_RESOLV_DEBUG طباعات تصحيح محلل الأسماء. تُستخدم هذه المطبوعات عندما يحل ConnMan أسماء المضيفين لاستخدامه الخاص. لاحظ أن طباعات تصحيح وكيل DNS لا تستخدم متغير البيئة هذا. لذلك يمكن استخدام خيار سطر الأوامر "-d src/dnsproxy.c". CONNMAN_SUPPLICANT_DEBUG طباعات تصحيح للاتصال بين عمليتي connmand و wpa_supplicant. CONNMAN_WEB_DEBUG معلومات تصحيح عندما يقوم ConnMan بفحص اتصال الإنترنت في مكونات Wispr و 6to4.
مثال: CONNMAN_WEB_DEBUG=1 src/connmand -n
إذا كانت ظروف التوقيت ذات صلة، فمن المستحسن الأمر للحصول على سجلات التتبع كما يلي: connmand -d 2>&1 | ts '[%H:%M:%.S]' | tee connman.log
برنامج 'ts' متاح عادةً في حزمة moreutils.
لدعم التوصيل المشترك، يجب تمكين خيارات تكوين النواة التالية إما كوحدات (m) أو مدمجة (y):
CONFIG_BRIDGE CONFIG_IP_NF_TARGET_MASQUERADE
لتمكين CONFIG_IP_NF_TARGET_MASQUERADE، يجب أيضًا تمكين الخيارات التالية ككوحدات (m) أو مدمجة (y):
CONFIG_NETFILTER CONFIG_NF_CONNTRACK_IPV4 CONFIG_NF_NAT_IPV4
لدعم التوجيه والإحصاءات في Sessions، يجب تمكين الخيارات التالية كوحدات (m) أو مدمجة (y):
CONFIG_IP_NF_IPTABLES CONFIG_IP_MULTIPLE_TABLES CONFIG_NETFILTER_NETLINK_ACCT CONFIG_NETFILTER_XT_MATCH_NFACCT CONFIG_NETFILTER_XT_CONNMARK CONFIG_NETFILTER_XT_TARGET_CONNMARK CONFIG_NETFILTER_XT_MATCH_CONNMARK
لدعم توصيل USB gadget، يجب تمكين خيارات تكوين النواة التالية:
CONFIG_USB_GADGET CONFIG_USB_ETH
لكي يعمل wpa_supplicant و Connection Manager بشكل صحيح معًا، يجب تعديل ملف .config الخاص بـ wpa_supplicant وضبط:
CONFIG_WPS=y CONFIG_AP=y CONFIG_CTRL_IFACE_DBUS_NEW=y
أضف:
CONFIG_BGSCAN_SIMPLE=y
سيمكن هذا الخيار الأخير دعم المسح الخلفي أثناء الاتصال، وهو ضروري عند التجوال على wifi.
يوصى باستخدام wpa_supplicant 2.x أو أحدث.
إذا تم تكوين wpa_supplicant للتشغيل التلقائي عبر D-Bus، فسيقوم ConnMan بتشغيل التشغيل التلقائي لـ wpa_supplicant. لكن ضع في اعتبارك أن هذا التشغيل يحدث مرة واحدة فقط. إذا توقف wpa_supplicant أو تعطل، لا يحاول ConnMan تشغيله تلقائيًا بشكل دوري. الأمر متروك لـ systemd أو أداة إدارة خدمات مشابهة لتشغيله تلقائيًا. في حال لم يتم تشغيل wpa_supplicant بواسطة ConnMan، فتأكد من استخدام الخيار "-u" لتمكين واجهة التحكم D-Bus الخاصة به وضمان قدرة ConnMan على التواصل معه.
لتجميع إضافات pptp و l2tp VPN، تحتاج إلى حزمة تطوير ppp.
لتشغيل l2tp ستحتاج إلى - xl2tpd, http://www.xelerance.com/services/software/xl2tpd
لتشغيل pptp ستحتاج إلى - عميل pptp, http://pptpclient.sourceforge.net
كلا من l2tp و pptp يحتاجان أيضًا إلى pppd.
حتى الإصدار 2.2 من OpenVPN، لن يعمل دفع مسارات إضافية من الخادم دائمًا. بعض الأعراض هي أن المسارات الإضافية لن يتم تعيينها بواسطة ConnMan إذا كان الارتباط الصاعد هو شبكة خلوية. بينما يعمل نفس الإعداد بشكل جيد مع رابط WiFi أو ethernet صاعد.
حتى الإصدار 2.4.5 (على الأقل) من OpenVPN، يفتقر الحصول على معلومات عن فشل فك تشفير المفتاح الخاص عبر قناة الإدارة. سيؤدي هذا إلى محاولة استخدام المفتاح غير الصالح مرارًا وتكرارًا حيث أن معلومات فشل فك التشفير لا يتم تسليمها إلى إضافة OpenVPN. التصحيح التالي لـ OpenVPN مطلوب لإرسال حالات فشل فك تشفير المفتاح الخاص: https://git.sailfishos.org/mer-core/openvpn/blob/ 4f4b4af116292a207416c8a990392e35a6fc41af/rpm/privatekey-passphrase- handling.diff
عند استخدام GnuTLS، كن على علم أنه اعتمادًا على تكوين GnuTLS، يتم إجراء تهيئة متأخرة (lazy) أو فورية (eager) لـ تجمع الانتروبيا الداخلي باستخدام /dev/urandom. في التهيئة الفورية، سيتأخر تحميل ConnMan بواسطة أداة تحميل الارتباط حتى يتم ملء تجمع الانتروبيا. على الأنظمة الأصغر، يمكن أن يؤخر هذا بسهولة بدء ConnMan بعدة ثوانٍ (تلقينا تقارير عن تأخير 25 ثانية أو أكثر).
يسمح GnuTLS بالعودة إلى التقييم المتأخر عند تعيين متغير البيئة GNUTLS_NO_EXPLICIT_INIT. لمزيد من التفاصيل، يرجى قراءة صفحة الدليل الخاصة بـ gnutls_global_init(3).
يحاول ConnMan اكتشاف ما إذا كان لديه اتصال بالإنترنت أم لا عندما يتم توصيل خدمة. إذا نجح التحقق من الاتصال، تدخل الخدمة حالة Online، وإلا تظل في حالة Ready. يُستخدم التحقق من الاتصال أيضًا لاكتشاف ما إذا كان ConnMan خلف بوابة مقيدة (captive portal) مثل عندما تكون في فندق وتحتاج إلى الدفع مقابل الاتصال.
يتم إجراء التحقق من الاتصال عن طريق محاولة جلب مستند status.html من ipv4.connman.net (لاتصال IPv4) و ipv6.connman.net (لاتصال IPv6). يبدو عنوان URL المستخدم هكذا http://ipv{4|6}.connman.net/online/status.html
يعمل التحقق من الاتصال في أحد الأوضاع الثلاثة:
حيث يكون "one-shot" هو الوضع الافتراضي ويتم التحكم فيه بواسطة إعداد "OnlineCheckMode".
في وضع "none"، لا توجد فحوصات "online" قائمة على HTTP لوصول الإنترنت. أي خدمة متصلة وحالة المدير ستنتهي عند حالة Ready ولن تتقدم إلى Online.
في وضع "one-shot" (الوضع الافتراضي)، يوجد فحص "online" واحد قائم على HTTP لوصول الإنترنت للخدمة الافتراضية (أي الخدمة ذات مسار البوابة الافتراضية ذي الأولوية العالية (metric 0)). عند نجاح الفحص، ستنتهي الخدمة المرتبطة وحالة المدير عند حالة "online". عند فشل الفحص، ستتم إعادة جدولة الفحوصات اللاحقة وفقًا لـ "OnlineCheckIntervalStyle" و "OnlineCheckInitialInterval" و "OnlineCheckMaxInterval" وستستمر إلى أجل غير مسمى حتى ينجح واحد أو يتم فصل الخدمة.
في وضع "continuous"، توجد فحوصات "online" مستمرة قائمة على HTTP لوصول الإنترنت للخدمة الافتراضية (أي الخدمة ذات مسار البوابة الافتراضية ذي الأولوية العالية (metric 0)). كما في وضع "one-shot"، عندما ينجح الفحص الأول، ستنتهي الخدمة المرتبطة وحالة المدير عند حالة Online. بعد ذلك، سيتم جدولة الفحوصات اللاحقة وفقًا لـ "OnlineCheckIntervalStyle" و "OnlineCheckMaxInterval". عندما يفشل الفحص، سيتم إعادة جدولة الفحوصات اللاحقة وفقًا لـ "OnlineCheckIntervalStyle" و "OnlineCheckInitialInterval" و "OnlineCheckMaxInterval". عند الوصول إلى "OnlineCheckFailuresThreshold"، سيتم تخفيض الخدمة وحالة المدير إلى Ready وستحصل الخدمة على خاصية "Error" مضبوطة على "online-check-failed" بينما تستمر الفحوصات اللاحقة. في هذه الأثناء، إذا كانت متوفرة، يمكن ترقية خدمة أخرى إلى الخدمة الافتراضية وسيتم بدء فحوصات عبر الإنترنت لها. عند الوصول إلى "OnlineCheckSuccessesThreshold" للخدمة المخفَّضة، سيتم مسح خاصية "Error" للخدمة وسيتم ترقية حالة الخدمة إلى Online، مما قد يتسبب في جعله الخدمة الافتراضية مرة أخرى.
انظر connman.conf(5) لخيار "OnlineCheckMode"، إذا كنت بحاجة إلى تعطيل الميزة. من الممكن أيضًا تحديد عناوين URL أخرى عبر خيارات "OnlineCheckIPv4URL" و "OnlineCheckIPv6URL". يمكن ضبط نطاق الفترات بين طلبي فحص عبر الإنترنت عبر خيارات "OnlineCheckInitialInterval" و "OnlineCheckMaxInterval" بالإضافة إلى خيار "OnlineCheckIntervalStyle".
كما هو موضح أعلاه، لوضعي "one-shot" و "continuous"، عندما يفشل طلب فحص عبر الإنترنت (أو في حالة وضع "continuous"، عندما ينجح أيضًا)، يتم تشغيل طلب آخر بعد فترة أطول. تتبع الفترات واحدة من تسلسلين رياضيين، اعتمادًا على إعداد "OnlineCheckIntervalStyle": "fibonacci" أو "geometric"، مع افتراضي "geometric". الإعداد الهندسي هو سلسلة الأرقام المربعة ضمن النطاق المحدد بواسطة "OnlineCheckInitialInterval" و "OnlineCheckMaxInterval". القيم الافتراضية لـ "OnlineCheckInitialInterval" و "OnlineCheckMaxInterval" هي النطاق [1, 12]، والذي يتوافق مع الفترات "geometric" التالية، بالثواني: 1, 4, 9, 16, 25, 36, 49, 64, 81, 100, 121 و 144 عبر هذا النطاق. بالمقابل، التسلسل "fibonacci" المقابل عبر هذا النطاق هو 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, و 144. سلسلة "fibonacci" وأسلوبها أكثر عدوانية في معدل الفحص حتى 12 خطوة (نقطة التكافؤ مع "geometric" عند 144 ثانية) من "geometric" لكنها تتراجع بشكل أكثر عدوانية بعد تلك النقطة لتصل إلى ساعة عند الفاصل 19 الذي لا تصل إليه "geometric" حتى الفاصل 60.
أثناء إجراء التحقق من الاتصال، سيقوم ConnMan مؤقتًا بتثبيت مسار مضيف إلى كل من ipv4.connman.net و ipv6.connman.net بحيث يمكن توجيه استعلام التحقق من الاتصال عبر واجهة الشبكة الصحيحة التي تستخدمها الخدمة المتصلة. تتم إزالة هذا المسار المضيف تلقائيًا عند الانتهاء من التحقق من الاتصال. لاحظ أن الخادم لا يسجل أي معلومات اتصال، بما في ذلك عناوين IPv4/6 للعملاء المتصلين. تتناوب سجلات وقت تشغيل الخادم في ذاكرة RAM اعتمادًا على عدد الاتصالات التي تمت معالجتها.
يرسل ConnMan هذه المعلومات المحدودة جدًا في رأس http عند القيام بطلب التحقق من الاتصال (مثال): Host: ipv4.connman.net User-Agent: ConnMan/1.23 wispr Connection: close
حاليًا يتم إرجاع المعلومات التالية من connman.net إذا كان الاتصال ناجحًا (يتم إرجاع رمز استجابة http 200 OK): Server: nginx Date: Mon, 09 Jun 2014 09:25:42 GMT Content-Type: text/html Connection: close X-ConnMan-Status: online
يُستخدم حقل X-ConnMan-Status في اكتشاف البوابة، إذا كان مفقودًا سيقوم ConnMan باستدعاء طريقة RequestBrowser في واجهة dbus net.connman.Agent للتعامل مع تسجيل الدخول إلى البوابة إذا كانت البوابة لا تدعم WISPr. راجع doc/agent-api.txt لمزيد من التفاصيل.
القائمة البريدية: [email protected]
إذا كنت ترغب في الاشتراك لتلقي البريد في صندوق الوارد الخاص بك، فقط أرسل رسالة (فارغة) من حساب بريدك الإلكتروني إلى
أرشيف القائمة البريدية: https://lore.kernel.org/connman
IRC: ircs://irc.oftc.net:6697/#connman (لـ SSL) irc://irc.oftc.net:6667/#connman (لغير SSL)