- Linux kernel security team रिपोर्ट की गई vulnerabilities को जितनी जल्दी हो सके ठीक करके public repository में merge करती है, और अलग से कोई notice या announcement जारी नहीं करती
- यह टीम CVE जारी करने वाली kernel CVE team से अलग है, और सभी सदस्य व्यक्तिगत हैसियत से काम करते हैं; इसका किसी कंपनी से संबंध नहीं होता
- security bugs को साधारण general bugs की तरह ही माना जाता है और fix के बाद उन्हें अलग से ‘security patch’ के रूप में चिह्नित नहीं किया जाता
- 7 दिनों से अधिक का embargo नहीं रखा जाता, और अधिकांश fixes तुरंत public कर दिए जाते हैं
- यह approach open source की प्रकृति और विविध उपयोग परिवेशों को ध्यान में रखकर अपनाई गई है, ताकि kernel security response की transparency और independence बनी रहे
Linux kernel security team की भूमिका
- kernel security team उन developers का समूह है जो रिपोर्ट किए गए संभावित security bugs को वर्गीकृत करके तेज़ी से ठीक करता है
- यह Kernel Self-Protection Project द्वारा किए जाने वाले दीर्घकालिक preventive measures से अलग reactive security response संभालती है
- reporting process साधारण text email के माध्यम से होती है; HTML, binary attachments और encryption की अनुमति नहीं है
- encrypted reports को multiple recipients वाली संरचना के कारण process नहीं किया जा सकता
- team members kernel के प्रमुख subsystems का प्रतिनिधित्व करने वाले core developers होते हैं, और वे चर्चा की सामग्री को अपने employer या बाहरी पक्षों के साथ साझा नहीं कर सकते
- इस independence की वजह से CRA जैसी विभिन्न देशों की कानूनी आवश्यकताओं से अलग रहते हुए भी एकसमान response संभव होता है
bug fix प्रक्रिया
- यदि रिपोर्ट किया गया bug किसी विशेष subsystem से जुड़ा हो, तो उसे सुलझाने के लिए संबंधित subsystem maintainer को email discussion में शामिल किया जाता है
- जिन subsystems में बार-बार समस्याएँ आती हैं, उनके maintainers कभी-कभी security team mailing list में सीधे भाग लेते हैं
- यदि reporter fix patch देता है, तो उसे उसका credit दिया जाता है; अन्यथा developers स्वयं समाधान करते हैं
- fix पूरा होने पर उसे main kernel branch और stable releases में merge किया जाता है
embargo नीति
- 7 दिनों से अधिक की non-public अवधि की अनुमति नहीं है, और अधिकांश fixes तुरंत public हो जाते हैं
- fix के बाद reporter यदि चाहे तभी बाहरी announcement कर सकता है; security team स्वयं कोई घोषणा नहीं करती
- CVE assignment बाद में kernel CVE team करती है, जो security team से अलग है
“bug तो बस bug है” सिद्धांत
- 2008 में Linus Torvalds ने स्पष्ट किया था कि security bugs को अलग से चिह्नित नहीं किया जाना चाहिए
- कारण यह था कि “security fix” जैसी श्रेणी अन्य bugs के महत्व को विकृत कर देती है
- सभी bug fixes समान रूप से महत्वपूर्ण हैं, और security, functionality, performance जैसे किसी भी भेद के बिना सबको तुरंत शामिल किया जाता है
security advisories न होने का कारण
- kernel स्तर के लगभग सभी bugs संभावित रूप से security issues बन सकते हैं
- जैसे memory leaks, denial of service, information disclosure आदि कई रूप हो सकते हैं
- open source की प्रकृति के कारण developers users के वास्तविक environment को नहीं जान सकते
- जो fix एक user के लिए मामूली हो, वही दूसरे user के लिए गंभीर vulnerability हो सकती है
- इसलिए नीति सरल है
- ज्ञात bug को तुरंत ठीक करो
- fixed releases को जितनी जल्दी हो सके वितरित करो
- यह दृष्टिकोण मानता है कि “fix से समस्या पैदा हो सकती है” की चिंता से अधिक, ज्ञात bug को छोड़ देना ज्यादा जोखिमपूर्ण है
hardware security issues
- Spectre, Meltdown जैसे मामलों में, जहाँ समस्या OS और hardware दोनों को शामिल करती है, एक अपवादात्मक प्रक्रिया की आवश्यकता होती है
- इसके लिए ‘Hardware Security Policy’ बनाई गई है, जिसके तहत सीमित encrypted mailing list के माध्यम से सहयोग किया जाता है
- यह प्रक्रिया धीमी और जटिल है, लेकिन हाल के वर्षों में कई hardware bugs इस प्रक्रिया के बिना भी हल किए गए हैं
- भविष्य में CRA कानूनों की response-time requirements के कारण लंबा embargo और भी कठिन हो सकता है
kernel security team की शुरुआत की पृष्ठभूमि
- 2005 से पहले कोई आधिकारिक security contact point मौजूद नहीं था
- reports केवल developers के बीच अनौपचारिक नेटवर्क से भेजी जाती थीं
- 2005 में Steve Bergman के email proposal से चर्चा शुरू हुई, और
Chris Wright ने security contact और documentation जोड़ने वाला patch लिखा
- इसके बाद central email alias (security@kernel.org) को औपचारिक रूप दिया गया
security advisories और advance notice की अनुपस्थिति
- kernel security team किसी भी प्रकार की security advisory या advance notice list नहीं चलाती
- CVE ID assignment kernel CVE team संभालती है; security team इसमें शामिल नहीं होती
- advance notice list की माँग अक्सर आती है, लेकिन leak risk और public-access principles के कारण ऐसी सूची मौजूद नहीं है
- उनका दृष्टिकोण है: “अगर कोई सरकार इसे अनुमति दे दे, तो संभवतः वह project वास्तव में उपयोग में ही नहीं होगा”
अभी कोई टिप्पणी नहीं है.