Linux kernel सुरक्षा कार्य

• 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 ([e-mail]) को औपचारिक रूप दिया गया

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 वास्तव में उपयोग में ही नहीं होगा”

---

[GN⁺]

Hacker News की राय

• हाल के समय में Linux desktop पर virtualization experience को सहज बनाने वाली तकनीकें तेज़ी से आगे बढ़ रही हैं
  GPU drivers अब Mesa के ज़रिए native context को support कर रहे हैं, और Wayland में guest–host के बीच sharing features भी बेहतर हो रही हैं
  पहले sommelier या wayland-proxy-virtwl जैसे जटिल protocol parsing की ज़रूरत पड़ती थी, लेकिन अब wl-cross-domain-proxy प्रोजेक्ट इसे सही तरीके से implement कर रहा है
  इन features का उपयोग करने वाले VMM में muvm है, और इन्हें integrate करने वाले solution के तौर पर munix मौजूद है

  • यह सच में दिलचस्प है। सोच रहा हूँ कि क्या munix इस्तेमाल करने वाली machines के बीच apps को live migration किया जा सकता है
    अगर pause करके transfer किया जा सके और फिर resume करके virtual machine को आगे चलाया जा सके, तो वह काफ़ी शानदार होगा

• इसी वजह से Red Hat 2025 में भी अब भी महत्वपूर्ण है
  इस तरह का infrastructure work हमेशा ज़रूरी रहता है

  • उलटा तर्क भी दिया जा सकता है
    जब Red Hat security-related commits को cherry-pick करता है, तो अगर upstream यह न बताए कि कौन-सा commit security से जुड़ा है, तो उसे पता कैसे चलेगा?

• कभी-कभी मैं 100% पूरी तरह secure OS का सपना देखता हूँ
  शायद formal verification या Rust इसकी कुंजी हो सकते हैं
  बस यह भरोसा चाहिए कि सिस्टम hack नहीं होगा

  • “ऐसा OS जिसे hack न किया जा सके” सुनने में बढ़िया लगता है। लेकिन आखिर में social engineering attacks तो रहेंगे ही
    अंत में इंसान ही सबसे बड़ी vulnerability है
  • ऐसी कोशिशें पहले भी कई बार हुई हैं। Microsoft का Verve OS इसका एक प्रमुख उदाहरण है
    यहाँ तक कि assembly भी verify की गई थी, और Dafny भी यहीं से निकला
    लेकिन बाज़ार में ‘अच्छी quality’ से ज़्यादा ‘तेज़ delivery’ को प्राथमिकता मिलती है, इसलिए ऐसे ideas को mainstream बनने में दशकों लग जाते हैं
  • ज़्यादातर मामलों में security bugs से टूटने वाली isolation features असल में सिर्फ management convenience के लिए इस्तेमाल होती हैं
    वास्तविक isolation के लिए virtualization या physical separation चाहिए
    इसलिए “100% सुरक्षित OS” के लिए बहुत सारे contributors जुटाना मुश्किल है
    फिर भी अगर इस विषय में दिलचस्पी है, तो ऐसे कई OS development projects मौजूद हैं
  • तो फिर Qubes OS इस्तेमाल करो
  • इंसान ने जो बनाया है, इंसान उसे तोड़ भी सकता है
    security एक अंतहीन दौड़ है

• दूसरी ओर, 2026 आ जाने के बाद भी Greg की personal website अभी तक TLS support नहीं करती

  • सच कहूँ तो Encrypted Client Hello के व्यापक support से पहले इसकी खास ज़रूरत नहीं लगती
    Caddy में इसे configure करना आसान है, लेकिन personal blog जैसी static site के लिए encryption का वास्तविक लाभ बहुत कम है
    वैसे भी domain और IP plain text में दिखते ही हैं, इसलिए इससे बहुत बड़ा फ़र्क नहीं पड़ता

• अगर वे सच में ऐसा सोचते हैं, तो क्या उन्हें CNA हटाना नहीं चाहिए था?

  • उसका मतलब यह होगा कि “हर security researcher kernel vulnerabilities को मनमाने ढंग से define कर सकता है”
    लेकिन कुछ researchers में CVE की संख्या बढ़ाने की प्रवृत्ति होती है, इसलिए वे वास्तव में harmless bugs को भी high priority देने की कोशिश करते हैं

• “अगर security issue report करने के लिए encryption को अनिवार्य किया जाए, तो इस policy पर फिर से विचार करना चाहिए (यह UK government की बात है)”
  यह हिस्सा बस मज़ेदार है

• “bug तो बस bug है” कहना बहुत ज़्यादा सरलीकरण है
  root privileges की ज़रूरत वाला DoS और unprivileged user से system takeover पूरी तरह अलग चीज़ें हैं
  कुछ bugs साफ़ तौर पर security boundary violation पैदा करते हैं, और उन्हें security bugs के रूप में classify किया जाना चाहिए
  Greg को यह बात दशकों से समझाई जा रही है
  नतीजा यह है कि अगर आप latest version नहीं चला रहे, तो kernel पूरी तरह patched नहीं माना जा सकता
  CVE से बचा जाता है, और vulnerability fixes को commit log में छिपा दिया जाता है, जबकि attackers उसे देखकर समझ जाते हैं

  • “क्या सिर्फ latest version पर patch मिलना ज़्यादातर software के लिए भी सही नहीं है?”
    समझ नहीं आता कि इसे इतना अलग से क्यों highlight करना चाहिए

• ग्राहक Docker images में kernel-related patches की मांग करते हैं
  जबकि Docker में kernel शामिल ही नहीं होता
  kernel के बिना image deploy करने का कोई तरीका होना चाहिए

  • क्या Linux kernel किसी container image में गलती से शामिल हो सकता है?
    आम base images में kernel शामिल नहीं होता
  • संबंधित project के तौर पर wolfi-dev देखना उपयोगी हो सकता है