Google के कीज़ कुक ने लिनक्स कर्नेल में बग पर काम करने की प्रक्रिया को आधुनिक बनाने का आह्वान किया

कर्नेल.ओआरजी के पूर्व मुख्य सिस्टम प्रशासक और उबंटू सुरक्षा टीम के नेता कीस कुक, जो अब एंड्रॉइड और क्रोमओएस को सुरक्षित करने के लिए Google में काम करते हैं, ने कर्नेल की स्थिर शाखाओं में बग को ठीक करने की वर्तमान प्रक्रिया के बारे में चिंता व्यक्त की। हर हफ्ते, लगभग सौ फ़िक्सेस को स्थिर शाखाओं में शामिल किया जाता है, और अगली रिलीज़ में परिवर्तन स्वीकार करने की विंडो बंद होने के बाद, यह एक हज़ार तक पहुँच जाती है (रखरखाव विंडो बंद होने तक फ़िक्सेस को पकड़कर रखते हैं, और "के गठन के बाद" -rc1" वे संचित को एक ही बार में प्रकाशित करते हैं), जो बहुत अधिक है और लिनक्स कर्नेल पर आधारित रखरखाव उत्पादों के लिए बहुत अधिक श्रम की आवश्यकता होती है।

कीज़ के अनुसार, कर्नेल में त्रुटियों के साथ काम करने की प्रक्रिया पर उचित ध्यान नहीं दिया जाता है और इस क्षेत्र में समन्वित कार्य के लिए कर्नेल में कम से कम 100 अतिरिक्त डेवलपर्स का अभाव है। मुख्य कर्नेल डेवलपर नियमित रूप से बग्स को ठीक करते हैं, लेकिन इस बात की कोई गारंटी नहीं है कि ये सुधार तीसरे पक्षों द्वारा उपयोग किए जाने वाले कर्नेल वेरिएंट में किए जाएंगे। लिनक्स कर्नेल पर आधारित विभिन्न उत्पादों के उपयोगकर्ताओं के पास यह नियंत्रित करने का कोई तरीका नहीं है कि कौन से बग ठीक किए गए हैं और उनके उपकरणों में कौन से कर्नेल का उपयोग किया गया है। अंततः, निर्माता अपने उत्पादों की सुरक्षा के लिए जिम्मेदार हैं, लेकिन स्थिर कर्नेल शाखाओं में प्रकाशन फिक्स की बहुत अधिक तीव्रता के साथ, उन्हें एक विकल्प का सामना करना पड़ा - सभी फिक्स को पोर्ट करें, सबसे महत्वपूर्ण को चुनिंदा रूप से पोर्ट करें, या सभी फिक्स को अनदेखा करें .

इष्टतम समाधान केवल सबसे महत्वपूर्ण सुधारों और कमजोरियों को स्थानांतरित करना होगा, लेकिन ऐसी त्रुटियों को सामान्य प्रवाह से अलग करना मुख्य समस्या है। सामने आने वाली समस्याओं की सबसे बड़ी संख्या सी भाषा का उपयोग करने का परिणाम है, जिसमें मेमोरी और पॉइंटर्स के साथ काम करते समय बहुत सावधानी की आवश्यकता होती है। मामले को बदतर बनाने के लिए, कई संभावित भेद्यता पैच को सीवीई पहचानकर्ता प्रदान नहीं किया जाता है, या पैच प्रकाशित होने के कुछ समय बाद उन्हें सीवीई पहचानकर्ता सौंपा जाता है। ऐसे माहौल में, निर्माताओं के लिए छोटे सुधारों को महत्वपूर्ण सुरक्षा मुद्दों से अलग करना बहुत मुश्किल है। आंकड़ों के मुताबिक, सीवीई असाइन किए जाने से पहले 40% से अधिक कमजोरियां तय की जाती हैं, और औसतन एक फिक्स जारी होने और सीवीई के असाइनमेंट के बीच की देरी तीन महीने होती है (यानी, पहले फिक्स को ऐसा माना जाता है) एक नियमित बग, लेकिन कई महीनों के बाद ही यह स्पष्ट हो जाता है कि भेद्यता को ठीक कर दिया गया है)।

परिणामस्वरूप, कमजोरियों के समाधान वाली एक अलग शाखा के बिना और किसी विशेष समस्या के सुरक्षा कनेक्शन के बारे में जानकारी प्राप्त किए बिना, लिनक्स कर्नेल पर आधारित उत्पादों के निर्माताओं को नवीनतम स्थिर शाखाओं से सभी सुधारों को लगातार स्थानांतरित करने के लिए छोड़ दिया जाता है। लेकिन इस काम के लिए बहुत अधिक श्रम की आवश्यकता होती है और प्रतिगामी परिवर्तनों के उभरने के डर से कंपनियों में प्रतिरोध का सामना करना पड़ता है जो उत्पाद के सामान्य संचालन को बाधित कर सकता है।

आइए याद रखें कि लिनस टोरवाल्ड्स के अनुसार, सभी त्रुटियां महत्वपूर्ण हैं और कमजोरियों को अन्य प्रकार की त्रुटियों से अलग नहीं किया जाना चाहिए और एक अलग उच्च प्राथमिकता श्रेणी में आवंटित किया जाना चाहिए। इस राय को इस तथ्य से समझाया गया है कि एक सामान्य डेवलपर के लिए जो सुरक्षा मुद्दों में विशेषज्ञ नहीं है, एक फिक्स और संभावित भेद्यता के बीच संबंध स्पष्ट नहीं है (कई सुधारों के लिए, केवल एक अलग ऑडिट ही यह समझना संभव बनाता है कि वे सुरक्षा से संबंधित हैं ). लिनुस के अनुसार, लिनक्स वितरण में कर्नेल पैकेज को बनाए रखने के लिए जिम्मेदार टीमों के सुरक्षा विशेषज्ञों को पैच की सामान्य धारा से संभावित कमजोरियों की पहचान करने में शामिल किया जाना चाहिए।

कीज़ कुक का मानना ​​है कि उचित दीर्घकालिक लागत पर कर्नेल सुरक्षा बनाए रखने का एकमात्र समाधान कंपनियों के लिए स्थानीय कर्नेल बिल्ड में पोर्टिंग फिक्स में शामिल इंजीनियरों को मुख्य कर्नेल (अपस्ट्रीम) में फिक्स और कमजोरियों को बनाए रखने के लिए एक संयुक्त, समन्वित प्रयास में स्थानांतरित करना है। ). अपने वर्तमान स्वरूप में, कई निर्माता अपने उत्पादों में नवीनतम कर्नेल संस्करणों का उपयोग नहीं करते हैं और इन-हाउस सुधारों को बैकपोर्ट करते हैं, अर्थात। यह पता चला है कि विभिन्न कंपनियों के इंजीनियर एक ही समस्या को हल करते हुए एक-दूसरे के काम की नकल करते हैं।

उदाहरण के लिए, यदि 10 कंपनियां, जिनमें से प्रत्येक में एक इंजीनियर समान सुधारों को बैकपोर्ट कर रहा है, ने उन इंजीनियरों को अपस्ट्रीम में बग्स को ठीक करने के लिए पुन: नियुक्त किया है, तो एक फिक्स को बैकपोर्ट करने के बजाय, वे सामान्य लाभ के लिए 10 अलग-अलग बग्स को ठीक कर सकते हैं या प्रस्तावित की समीक्षा में शामिल हो सकते हैं। परिवर्तन करता है और बग्गी कोड को कर्नेल में शामिल होने से रोकता है। संसाधनों को कोड के परीक्षण और विश्लेषण के लिए नए उपकरण बनाने के लिए भी समर्पित किया जा सकता है जो बार-बार सामने आने वाली त्रुटियों के सामान्य वर्गों का शीघ्र पता लगाने की अनुमति देगा।

कीज़ कुक कर्नेल विकास प्रक्रिया में सीधे स्वचालित और फ़ज़िंग परीक्षण का अधिक सक्रिय रूप से उपयोग करने, निरंतर एकीकरण प्रणालियों का उपयोग करने और ईमेल के माध्यम से पुराने विकास प्रबंधन को छोड़ने का भी सुझाव देते हैं। वर्तमान में, प्रभावी परीक्षण इस तथ्य से बाधित है कि मुख्य परीक्षण प्रक्रियाएँ विकास से अलग हो जाती हैं और रिलीज़ बनने के बाद होती हैं। कीज़ ने त्रुटियों की संख्या को कम करने के लिए विकास करते समय उन भाषाओं का उपयोग करने की भी सिफारिश की जो उच्च स्तर की सुरक्षा प्रदान करती हैं, जैसे कि रस्ट।

स्रोत: opennet.ru