أعرب Kees Cook ، مسؤول مسئول تنفيذي سابق في kernel.org وقائد فريق أمان Ubuntu ، والذي يعمل الآن مع Google لتأمين Android و ChromeOS ، عن قلقه بشأن العملية الحالية لإصلاح الأخطاء في الفروع المستقرة للنواة. كل أسبوع ، يتم تضمين حوالي مائة إصلاح في الفروع المستقرة ، وبعد إغلاق النافذة لقبول التغييرات على الإصدار التالي ، يقترب من ألف (يحتفظ المشرفون بإصلاحات حتى يتم إغلاق النافذة ، وبعد تشكيل "-rc1" هم نشر تلك المتراكمة دفعة واحدة) ، وهو كثير جدًا ويتطلب الكثير من العمل لمنتجات الصيانة القائمة على نواة Linux.
وفقًا لـ Keys ، لا يتم إيلاء الاهتمام الواجب لعملية التعامل مع الأخطاء في النواة وتفتقر kernel إلى ما لا يقل عن 100 مطور إضافي للعمل المنسق في هذا المجال. يقوم مطورو النواة الأساسية بإصلاح الأخطاء بشكل منتظم ، ولكن لا يوجد ضمان بأن هذه الإصلاحات سيتم نقلها إلى متغيرات kernel المستخدمة من قبل أطراف ثالثة. لا يملك مستخدمو المنتجات المختلفة التي تعتمد على Linux kernel أي طريقة للتحكم في الأخطاء التي تم إصلاحها والنواة المستخدمة في أجهزتهم. يتحمل البائعون المسؤولية في النهاية عن أمان منتجاتهم ، ولكن مع وجود معدل ترقيع مرتفع جدًا في فروع النواة المستقرة ، فقد واجهوا خيارًا بين دعم جميع التصحيحات أو نقل أهمها بشكل انتقائي أو تجاهل جميع التصحيحات.
سيكون الحل الأمثل هو ترحيل أهم الإصلاحات ونقاط الضعف فقط ، ولكن عزل مثل هذه الأخطاء عن التدفق العام هو المشكلة الرئيسية. معظم المشاكل التي تظهر بسبب استخدام لغة سي ، والتي تتطلب عناية كبيرة عند التعامل مع الذاكرة والمؤشرات. ومما زاد الطين بلة ، أن العديد من إصلاحات الثغرات الأمنية المحتملة لا يتم تزويدها بمعرفات مكافحة التطرف العنيف ، أو تتلقى مثل هذا المعرف بعد مرور بعض الوقت على نشر التصحيح. في ظل هذه الظروف ، يصعب جدًا على الشركات المصنعة فصل الإصلاحات الطفيفة عن مشكلات الأمان الرئيسية. وفقًا للإحصاءات ، يتم إصلاح أكثر من 40٪ من نقاط الضعف قبل تعيين مكافحة التطرف العنيف ، ومتوسط التأخير بين إصدار التصحيح وتخصيص مكافحة التطرف العنيف هو ثلاثة أشهر (أي ، في البداية ، يُنظر إلى التصحيح على أنه أمر شائع الخلل ، ولكن بعد بضعة أشهر فقط يتضح أن الثغرة الأمنية قد تم إصلاحها).
نتيجة لذلك ، بدون وجود فرع منفصل مع إصلاحات للثغرات الأمنية وبدون تلقي معلومات حول اتصال الأمان لمشكلة معينة ، يُترك مصنعي المنتجات القائمة على نواة Linux لنقل جميع الإصلاحات باستمرار من الفروع المستقرة الجديدة. لكن هذا العمل يتطلب الكثير من العمالة ويواجه مقاومة في الشركات بسبب الخوف من التغييرات الارتدادية التي يمكن أن تعطل التشغيل الطبيعي للمنتج.
تذكر أنه وفقًا للينوس تورفالدس ، فإن جميع الأخطاء مهمة ولا ينبغي فصل نقاط الضعف عن الأنواع الأخرى من الأخطاء وتخصيصها لفئة منفصلة ذات أولوية أعلى. يفسر هذا الرأي من خلال حقيقة أنه بالنسبة للمطور العادي الذي لا يتخصص في مشكلات الأمان ، فإن الاتصال بين الإصلاح والثغرة الأمنية المحتملة ليس واضحًا (بالنسبة للعديد من الإصلاحات ، يسمح لك التدقيق المنفصل فقط بفهم أنها تتعلق بالأمان ). وفقًا لـ Linus ، فإن الأمر متروك لفرق الأمان في الفرق المسؤولة عن صيانة حزم kernel على توزيعات Linux لعزل الثغرات الأمنية المحتملة من تدفق التصحيح العام.
يعتقد Kees Cook أن الحل الوحيد للحفاظ على أمان النواة بتكلفة معقولة على المدى الطويل هو أن تنقل الشركات المهندسين المشاركين في نقل التصحيحات إلى بنيات النواة المحلية للعمل بشكل تعاوني وتنسيقي للحفاظ على التصحيحات ونقاط الضعف في نواة المنبع. في شكله الحالي ، لا يستخدم العديد من الشركات المصنعة أحدث إصدار من kernel في منتجاتهم وإصلاحات backport بمفردهم ، أي اتضح أن المهندسين في شركات مختلفة يكررون عمل بعضهم البعض ويحلون نفس المشكلة.
على سبيل المثال ، إذا قامت 10 شركات ، كل منها بمهندس واحد يدعم نفس الإصلاحات ، بإعادة توجيه هؤلاء المهندسين لإصلاح الأخطاء في المنبع ، بدلاً من نقل إصلاح واحد ، يمكنهم إصلاح 10 أخطاء مختلفة للصالح العام أو الانضمام إلى مراجعة التغييرات المقترحة. منع تضمين رمز عربات التي تجرها الدواب في النواة. يمكن أيضًا تخصيص الموارد لإنشاء أدوات جديدة للاختبار وتحليل التعليمات البرمجية ، والتي من شأنها أن تسمح في مرحلة مبكرة بالتعرف تلقائيًا على فئات نموذجية من الأخطاء التي تظهر مرارًا وتكرارًا.
يقترح Kees Cook أيضًا استخدامًا أكثر نشاطًا للاختبار الآلي والمربك مباشرةً في عملية التطوير الأساسية ، واستخدام أنظمة التكامل المستمر والتخلي عن إدارة التطوير القديمة عبر البريد الإلكتروني. في الوقت الحالي ، يعيق الاختبار الفعال حقيقة أن عمليات الاختبار الرئيسية منفصلة عن التطوير وتحدث بعد تكوين الإطلاقات. توصي المفاتيح أيضًا باستخدام لغات أكثر أمانًا ، مثل Rust لتقليل الأخطاء.
المصدر: opennet.ru