गुगलको किज कुकले लिनक्स कर्नेलमा भएका त्रुटिहरूमा काम गर्ने प्रक्रियालाई आधुनिकीकरण गर्न आग्रह गरे

Kees Cook, kernel.org का पूर्व प्रमुख प्रणाली प्रशासक र Ubuntu सुरक्षा टोलीका नेता जसले अब एन्ड्रोइड र ChromeOS सुरक्षित गर्न Google मा काम गर्दछ, कर्नेलको स्थिर शाखाहरूमा बगहरू समाधान गर्ने वर्तमान प्रक्रियाको बारेमा चिन्ता व्यक्त गर्नुभयो। प्रत्येक हप्ता, लगभग सय फिक्सहरू स्थिर शाखाहरूमा समावेश हुन्छन्, र अर्को रिलीजमा परिवर्तनहरू स्वीकार गर्नको लागि सञ्झ्याल बन्द भएपछि, यो एक हजारमा पुग्छ (सञ्झ्याल बन्द नभएसम्म मर्मतकर्ताहरूले फिक्सहरू समात्छन्, र "को गठन पछि। -rc1" तिनीहरूले एकैचोटि संचितलाई प्रकाशित गर्छन्), जुन धेरै धेरै छ र लिनक्स कर्नेलमा आधारित मर्मत उत्पादनहरूको लागि धेरै श्रम चाहिन्छ।

कुञ्जीहरूका अनुसार कर्नेलमा त्रुटिहरूसँग काम गर्ने प्रक्रियामा उचित ध्यान दिइँदैन र यस क्षेत्रमा समन्वयात्मक कार्यका लागि कर्नेलमा कम्तिमा १०० थप विकासकर्ताहरूको अभाव छ। मुख्य कर्नेल विकासकर्ताहरूले नियमित रूपमा बगहरू फिक्स गर्छन्, तर त्यहाँ कुनै ग्यारेन्टी छैन कि यी फिक्सहरू तेस्रो पक्षहरूले प्रयोग गर्ने कर्नेल भेरियन्टहरूमा लैजान्छन्। लिनक्स कर्नेलमा आधारित विभिन्न उत्पादनहरूका प्रयोगकर्ताहरूसँग कुन बगहरू फिक्स गरिएको छ र कुन कर्नेल तिनीहरूको उपकरणहरूमा प्रयोग गरिन्छ भनेर नियन्त्रण गर्ने कुनै तरिका छैन। अन्ततः, निर्माताहरू तिनीहरूका उत्पादनहरूको सुरक्षाको लागि जिम्मेवार छन्, तर स्थिर कर्नेल शाखाहरूमा प्रकाशन फिक्सहरूको धेरै उच्च तीव्रताको साथ, तिनीहरूले एक विकल्पको सामना गर्नुपरेको थियो - सबै फिक्सहरू पोर्ट गर्नुहोस्, सबैभन्दा महत्त्वपूर्णहरूलाई छनौट गरी पोर्ट गर्नुहोस्, वा सबै फिक्सहरूलाई बेवास्ता गर्नुहोस्। ।

इष्टतम समाधान भनेको सबैभन्दा महत्त्वपूर्ण समाधान र कमजोरीहरूलाई मात्र स्थानान्तरण गर्नु हो, तर त्यस्ता त्रुटिहरूलाई सामान्य प्रवाहबाट अलग गर्नु मुख्य समस्या हो। पप अप हुने समस्याहरूको सबैभन्दा ठूलो संख्या C भाषाको प्रयोगको परिणाम हो, जसलाई मेमोरी र पोइन्टरहरूसँग काम गर्दा ठूलो सावधानी चाहिन्छ। मामिलाहरूलाई अझ नराम्रो बनाउनको लागि, धेरै सम्भावित जोखिम प्याचहरूलाई CVE पहिचानकर्ता प्रदान गरिएको छैन, वा प्याच प्रकाशित भएको केही समय पछि CVE पहिचानकर्ता तोकिएको छ। यस्तो वातावरणमा, निर्माताहरूको लागि महत्त्वपूर्ण सुरक्षा मुद्दाहरूबाट सानो फिक्सहरू अलग गर्न धेरै गाह्रो छ। तथ्याङ्कका अनुसार, CVE तोक्नु अघि 40% भन्दा बढी कमजोरीहरू फिक्स हुन्छन्, र औसतमा एक फिक्स रिलीज र CVE को असाइनमेन्ट बीचको ढिलाइ तीन महिना हुन्छ (अर्थात, सुरुमा फिक्सको रूपमा बुझिन्छ। एक नियमित बग, तर केहि महिना पछि मात्र यो स्पष्ट हुन्छ कि जोखिम फिक्स गरिएको छ)।

नतिजाको रूपमा, कमजोरीहरूका लागि फिक्सहरू सहितको छुट्टै शाखा बिना र कुनै विशेष समस्याको सुरक्षा जडानको बारेमा जानकारी प्राप्त नगरी, लिनक्स कर्नेलमा आधारित उत्पादनहरूका निर्माताहरूलाई नवीनतम स्थिर शाखाहरूबाट सबै फिक्सहरू निरन्तर स्थानान्तरण गर्न छोडिन्छ। तर यो कामको लागि धेरै श्रम चाहिन्छ र उत्पादनको सामान्य सञ्चालनमा बाधा पुर्‍याउने प्रतिगामी परिवर्तनहरूको उदयको डरले कम्पनीहरूमा प्रतिरोधको सामना गर्दछ।

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

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

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

Kees Cook ले कर्नेल विकास प्रक्रियामा सिधै स्वचालित र फजिङ परीक्षण प्रयोग गरेर, निरन्तर एकीकरण प्रणालीहरू प्रयोग गरेर र इमेल मार्फत पुरातन विकास व्यवस्थापन त्याग्न थप सक्रिय रूपमा सुझाव दिन्छ। हाल, प्रभावकारी परीक्षण यस तथ्यले बाधित भएको छ कि मुख्य परीक्षण प्रक्रियाहरू विकासबाट अलग छन् र रिलीजहरू गठन भएपछि देखा पर्दछ। कुञ्जीहरूले त्रुटिहरूको संख्या कम गर्न विकास गर्दा रस्ट जस्ता उच्च स्तरको सुरक्षा प्रदान गर्ने भाषाहरू प्रयोग गर्न सिफारिस गर्दछ।

स्रोत: opennet.ru