systemd عبارة عن مجموعة من شياطين إدارة النظام
في الآونة الأخيرة، أجرى مطورو systemd مناقشة حيث تم وضعها على الطاولة مشكلة تقليل تبعيات مكتبة libsystemd (المكتبة المسؤولة عن تنفيذ الخدمات والتفاعل مع systemd). وذلك لأن هناك حاليا معينة القلق بشأن زيادة تبعيات الطرف الثالث في libsystemd والتي لا يتحكم فيها المشروع وهذا يزيد من سطح الهجوم. تشير بداية المناقشة إلى أن libsystemd يقوم بتحميل العديد من المكتبات المهمة، مثل libzstd وliblz4 وlibgcrypt، بالإضافة إلى liblzma وglibc. وهذا يثير مشكلات أمنية كبيرة، خاصة إذا تم اختراق مكتبات الطرف الثالث هذه.
في Fedora، على سبيل المثال، تعتمد أكثر من 150 حزمة على libsystemd، مما يزيد من التعقيد والمخاطر المرتبطة به. الإقتراح أو العرض لمعالجة هذا ينطوي قم بتقسيم libsystemd إلى عدة مكتبات منفصلة، كل منها مسؤولة عن واجهة برمجة تطبيقات محددة. وهذا من شأنه أن يسمح بتحميل تبعيات الطرف الثالث فقط عند الضرورة، وبالتالي تقليل التعرض لنقاط الضعف المحتملة في المكتبات التي لا يتحكم فيها مطورو systemd بشكل مباشر.
ومع ذلك، المطورين بواسطة systemd ويقولون إن هذا الانفصال سيكون مشكلة بسبب الترابط بين برامج التشغيل الموجودة في libsystemd. وهم يعتقدون أن التقسيم سيكون كثيف العمالة ويمكن أن يؤدي إلى فقدان الكفاءة أو الحاجة إلى تكرار التعليمات البرمجية، الأمر الذي من شأنه أن يتعارض مع الفوائد الأمنية المقصودة.
وبدلا من الانفصال التام. لقد اتبعت libsystemd أسلوبًا أكثر ديناميكية من خلال التحميل الديناميكي مكتبات liblzma وlibzstd وliblz4 عند الضرورة، باستخدام استدعاء dlopen(). من المقرر تنفيذ تغيير مماثل لـ libgcrypt في الإصدارات المستقبلية لمعالجة المخاوف الأمنية واحتياجات كفاءة التعليمات البرمجية وقابلية الصيانة.
أعتقد أن معظم هذه التبعيات ليست ضرورية لتنفيذ وظائف libsystemd الأساسية، مثل تلك المذكورة أعلاه.
قد تعني هذه المشكلة تقسيم libsystemd إلى مكتبات متعددة تنفذ واجهات برمجة تطبيقات مختلفة، واحدة منها، على سبيل المثال libsystemd-core، ستعتمد فقط على libc، بينما ستضيف المكتبات الأخرى الأكثر تخصصًا تبعيات أخرى. وأيضًا، إذا كانت بعض التبعيات مطلوبة فقط لخدمات معينة في النظام، فقم بنقل التبعيات إلى تلك الخدمات.
يجب أن يكون التأثير النهائي لذلك هو تقليل سطح الهجوم وتحسين أمان النظام.
خلال المناقشة كانت هناك نقطة واحدة انتقدها معظم المطورين، ويذكرون أن قرار تحميل مكتبات الطرف الثالث ضمنيًا باستخدام dlopen() في libsystemd من شأنه أن يولد عملا إضافيا نظرًا للتعقيد الإضافي في التشخيص ونقص رؤية الارتباط، فقد ذكروا أيضًا أن هذا يعقد تحديد استدعاءات واجهة برمجة تطبيقات libsystemd التي تتصل بوظائف المكتبة الخارجية، نظرًا لأن ذلك غير واضح في الكود. هذه الطريقة الجديدة للتحميل، على الرغم من أنها لا تغير البنية الأساسية، إلا أنها تخفي المكونات الخارجية عن المشرفين والمستخدمين.
أعرب لينارت بوترينج عن عدم موافقته مع فكرة تقسيم libsystemd إلى مكتبات متعددة بسبب التعقيدات التي قد تؤدي إلى مشاركة التعليمات البرمجية والحفاظ على استقرار واجهة برمجة التطبيقات ومساحة الاسم. يتطلب تقسيم libsystemd الكشف عن جميع برامج التشغيل الداخلية أو تجميعها بشكل ثابت بشكل منفصل في كل مكتبة، مما قد يزيد الحجم بسبب تكرار التعليمات البرمجية أو يجعل من الصعب إدارة استقرار النظام واتساقه.
بدلاً من التقسيم، تعتبر استراتيجية تحميل المكتبات الخارجية فقط عند الضرورة هي الأمثل، بالإضافة إلى ذلك، لمعالجة التعقيد الإضافي في التشخيص، يُقترح إضافة حقول إضافية إلى ملفات ELF تحتوي على معلومات حول التبعيات الديناميكية المحملة، مما يسمح لمصححي الأخطاء بمعالجة هذه المعلومات وعرضها في مخرجات أدوات مثل readelf. وهذا من شأنه أن يوفر قدرًا أكبر من الشفافية والرؤية للتبعيات الديناميكية التي يستخدمها libsystemd، مما يسهل تشخيص وتصحيح المشكلات المتعلقة بالمكتبات الخارجية المحملة ديناميكيًا.
أوصى Lenart للمطورين من التطبيقات التي، بدلاً من الارتباط مباشرة بـ libsystemd لوظيفة معينة، يتم تنفيذ معالج البروتوكول على مستوى التطبيق.
تتمثل هذه الإستراتيجية في تنفيذ برامج تشغيل البروتوكول على مستوى التطبيق يقدم العديد من المزاياs:
- يقلل الاعتماد على libsystemd ويتجنب تحميل المكتبات الخارجية عندما لا تكون هناك حاجة إليها.
- يوفر المزيد من المرونة والتحكم في الوظائف المحددة التي يتطلبها التطبيق.
- يبسط عملية التشخيص وتصحيح الأخطاء من خلال التحكم المباشر بشكل أكبر في تنفيذ وظائف محددة.
- بشكل عام، يعزز هذا النهج نمطية واستقلالية التطبيقات، مما يحسن المرونة والكفاءة في تطوير البرمجيات وصيانتها.
إذا كنت مهتم بمعرفة المزيد عنها، يمكنك التحقق من التفاصيل في الرابط التالي.