Google च्या Kees Cook ने लिनक्स कर्नलमधील बग्सवर काम करण्याच्या प्रक्रियेचे आधुनिकीकरण करण्याचे आवाहन केले

Kees Cook, kernel.org चे माजी मुख्य प्रणाली प्रशासक आणि Ubuntu सुरक्षा कार्यसंघाचे नेते जे आता Android आणि ChromeOS सुरक्षित करण्यासाठी Google वर काम करतात, यांनी कर्नलच्या स्थिर शाखांमधील बग निराकरण करण्याच्या सध्याच्या प्रक्रियेबद्दल चिंता व्यक्त केली. दर आठवड्याला, स्थिर शाखांमध्ये सुमारे शंभर निराकरणे समाविष्ट केली जातात आणि पुढील प्रकाशनातील बदल स्वीकारण्याची विंडो बंद केल्यानंतर, ती एक हजारापर्यंत पोहोचते (विंडो बंद होईपर्यंत देखभाल करणारे निराकरणे ठेवतात आणि "" -rc1” ते एकाच वेळी जमा केलेले प्रकाशित करतात), जे खूप जास्त आहे आणि Linux कर्नलवर आधारित देखभाल उत्पादनांसाठी खूप श्रम लागतात.

कीजच्या मते, कर्नलमधील त्रुटींसह कार्य करण्याच्या प्रक्रियेकडे योग्य लक्ष दिले जात नाही आणि या क्षेत्रातील समन्वित कार्यासाठी कर्नलमध्ये किमान 100 अतिरिक्त विकासकांची कमतरता आहे. मुख्य कर्नल डेव्हलपर नियमितपणे बगचे निराकरण करतात, परंतु हे निराकरण तृतीय पक्षांद्वारे वापरल्या जाणार्‍या कर्नल प्रकारांमध्ये केले जाईल याची कोणतीही हमी नाही. लिनक्स कर्नलवर आधारित विविध उत्पादनांच्या वापरकर्त्यांना त्यांच्या उपकरणांमध्ये कोणते दोष निश्चित केले जातात आणि कोणते कर्नल वापरले जातात हे नियंत्रित करण्याचा कोणताही मार्ग नाही. शेवटी, उत्पादक त्यांच्या उत्पादनांच्या सुरक्षेसाठी जबाबदार असतात, परंतु स्थिर कर्नल शाखांमध्ये प्रकाशनाच्या अत्यंत तीव्रतेमुळे, त्यांना निवडीचा सामना करावा लागला - सर्व निराकरणे पोर्ट करा, निवडकपणे सर्वात महत्वाचे पोर्ट करा किंवा सर्व निराकरणे दुर्लक्षित करा. .

इष्टतम उपाय म्हणजे केवळ सर्वात महत्वाचे निराकरणे आणि भेद्यता स्थलांतरित करणे, परंतु अशा त्रुटींना सामान्य प्रवाहापासून वेगळे करणे ही मुख्य समस्या आहे. पॉप अप होणार्‍या समस्यांची सर्वात मोठी संख्या सी भाषा वापरण्याचा परिणाम आहे, ज्यासाठी मेमरी आणि पॉइंटर्ससह कार्य करताना खूप काळजी घेणे आवश्यक आहे. प्रकरण आणखी वाईट करण्यासाठी, अनेक संभाव्य असुरक्षितता पॅच CVE आयडेंटिफायरसह प्रदान केले जात नाहीत किंवा पॅच प्रकाशित झाल्यानंतर काही वेळाने त्यांना CVE ओळखकर्ता नियुक्त केले जातात. अशा वातावरणात, निर्मात्यांसाठी महत्त्वपूर्ण सुरक्षा समस्यांपासून किरकोळ निराकरणे वेगळे करणे खूप कठीण आहे. आकडेवारीनुसार, CVE नियुक्त करण्यापूर्वी 40% पेक्षा जास्त भेद्यता निश्चित केल्या जातात आणि एक निराकरण सोडणे आणि CVE नियुक्त करण्यात सरासरी विलंब तीन महिन्यांचा असतो (म्हणजे, प्रथम निराकरण असे समजले जाते एक नियमित बग, परंतु काही महिन्यांनंतरच हे स्पष्ट होते की असुरक्षा निश्चित केली गेली आहे).

परिणामी, असुरक्षिततेच्या निराकरणासह वेगळ्या शाखेशिवाय आणि विशिष्ट समस्येच्या सुरक्षा कनेक्शनबद्दल माहिती प्राप्त केल्याशिवाय, Linux कर्नलवर आधारित उत्पादनांचे निर्माते नवीनतम स्थिर शाखांमधून सर्व निराकरणे सतत हस्तांतरित करण्यासाठी सोडले जातात. परंतु या कामासाठी खूप श्रम करावे लागतात आणि उत्पादनाच्या सामान्य ऑपरेशनमध्ये व्यत्यय आणू शकतील अशा प्रतिगामी बदलांच्या उदयाच्या भीतीमुळे कंपन्यांमध्ये प्रतिकाराचा सामना करावा लागतो.

आपण हे लक्षात ठेवूया की लिनस टॉरवाल्ड्सच्या मते, सर्व त्रुटी महत्त्वाच्या आहेत आणि असुरक्षा इतर प्रकारच्या त्रुटींपासून वेगळ्या केल्या जाऊ नयेत आणि वेगळ्या उच्च प्राधान्य श्रेणीमध्ये वाटप केल्या जाऊ नये. हे मत या वस्तुस्थितीद्वारे स्पष्ट केले गेले आहे की सामान्य विकासकासाठी जो सुरक्षा समस्यांमध्ये तज्ञ नाही, निराकरण आणि संभाव्य असुरक्षा यांच्यातील संबंध स्पष्ट नाही (अनेक निराकरणांसाठी, फक्त एक स्वतंत्र ऑडिट हे समजणे शक्य करते की ते सुरक्षिततेशी संबंधित आहेत. ). लिनसच्या मते, Linux वितरणामध्ये कर्नल पॅकेजेस राखण्यासाठी जबाबदार असलेल्या संघातील सुरक्षा तज्ञांना पॅचच्या सामान्य प्रवाहातील संभाव्य भेद्यता ओळखण्यात गुंतले पाहिजे.

कीज कुकचा असा विश्वास आहे की वाजवी दीर्घकालीन खर्चात कर्नल सुरक्षा राखण्याचा एकमेव उपाय म्हणजे कंपन्यांनी स्थानिक कर्नल बिल्डमध्ये पोर्टिंग फिक्सेसमध्ये गुंतलेल्या अभियंत्यांना मुख्य कर्नल (अपस्ट्रीम) मध्ये निराकरणे आणि असुरक्षा राखण्यासाठी संयुक्त, समन्वयित प्रयत्नांमध्ये हलवणे. ). सध्याच्या स्वरूपात, बरेच उत्पादक त्यांच्या उत्पादनांमध्ये नवीनतम कर्नल आवृत्त्या वापरत नाहीत आणि घरातील निराकरणे बॅकपोर्ट करतात, उदा. असे दिसून आले की वेगवेगळ्या कंपन्यांमधील अभियंते समान समस्या सोडवून एकमेकांच्या कामाची डुप्लिकेट करतात.

उदाहरणार्थ, जर 10 कंपन्यांनी, प्रत्येक अभियंता समान निराकरणे बॅकपोर्ट करत असतील, तर त्या अभियंत्यांना अपस्ट्रीममध्ये बगचे निराकरण करण्यासाठी पुन्हा नियुक्त केले, तर एक निराकरण बॅकपोर्ट करण्याऐवजी, ते सामान्य फायद्यासाठी 10 भिन्न दोषांचे निराकरण करू शकतात किंवा प्रस्तावितच्या पुनरावलोकनात सामील होऊ शकतात. बदल करा आणि बग्गी कोड कर्नलमध्ये समाविष्ट करण्यापासून प्रतिबंधित करा. कोडची चाचणी आणि विश्लेषण करण्यासाठी नवीन साधने तयार करण्यासाठी संसाधने देखील समर्पित केली जाऊ शकतात ज्यामुळे सामान्य वर्गाच्या त्रुटी लवकर शोधू शकतात जे पुन्हा पुन्हा तयार होतात.

Kees Cook देखील अधिक सक्रियपणे कर्नल डेव्हलपमेंट प्रक्रियेमध्ये स्वयंचलित आणि अस्पष्ट चाचणी वापरून, सतत एकीकरण प्रणाली वापरून आणि ईमेलद्वारे पुरातन विकास व्यवस्थापन सोडून देण्याचे सुचवते. सध्या, मुख्य चाचणी प्रक्रिया विकासापासून विभक्त झाल्या आहेत आणि प्रकाशन तयार झाल्यानंतर होतात या वस्तुस्थितीमुळे प्रभावी चाचणीला बाधा येते. कीजने त्रुटींची संख्या कमी करण्यासाठी विकसित करताना रस्ट सारख्या उच्च पातळीची सुरक्षा प्रदान करणाऱ्या भाषा वापरण्याची शिफारस केली.

स्त्रोत: opennet.ru