Linux: लॉक पूल /dev/random हटा रहा है

/dev/random, एक क्रिप्टोग्राफ़िक रूप से सुरक्षित छद्म-यादृच्छिक संख्या जनरेटर (CSPRNG), एक कष्टप्रद समस्या के लिए जाना जाता है: अवरुद्ध करना। यह आलेख बताता है कि आप इसे कैसे हल कर सकते हैं।

पिछले कुछ महीनों में, कर्नेल में यादृच्छिक संख्या निर्माण सुविधाओं को थोड़ा फिर से काम में लाया गया है, लेकिन इस उपप्रणाली में समस्याओं को व्यापक स्तर पर हल किया गया है। निर्धारित समय - सीमा. सबसे अंतिम परिवर्तन सिस्टम बूट होने पर getrandom() सिस्टम कॉल को लंबे समय तक ब्लॉक होने से रोकने के लिए बनाए गए थे, लेकिन इसका अंतर्निहित कारण रैंडम पूल का ब्लॉकिंग व्यवहार था। एक हालिया पैच ने इस पूल को हटा दिया होगा और इसके मुख्य कोर की ओर बढ़ने की उम्मीद होगी।

एंडी लुटोमिरस्की ने दिसंबर के अंत में पैच का तीसरा संस्करण प्रकाशित किया। वह योगदान देता है "यादृच्छिक लिनक्स एपीआई में दो प्रमुख अर्थ संबंधी परिवर्तन". पैच getrandom() सिस्टम कॉल में एक नया GRND_INSECURE फ़्लैग जोड़ता है (हालाँकि Lutomirsky इसे getentropy() के रूप में संदर्भित करता है, जिसे निश्चित फ़्लैग के साथ getrandom() का उपयोग करके glibc में कार्यान्वित किया जाता है); यह फ़्लैग कॉल को हमेशा अनुरोधित डेटा की मात्रा लौटाने का कारण बनता है, लेकिन यह गारंटी दिए बिना कि डेटा यादृच्छिक है। कर्नेल किसी दिए गए समय पर सर्वोत्तम यादृच्छिक डेटा का उत्पादन करने की पूरी कोशिश करेगा। "शायद सबसे अच्छी बात इसे 'असुरक्षित' कहना है (असुरक्षित) इस एपीआई को उन चीज़ों के लिए उपयोग करने से रोकने के लिए जिन्हें सुरक्षा की आवश्यकता है।"

पैच अवरुद्ध पूल को भी हटा देते हैं। कर्नेल वर्तमान में दो यादृच्छिक डेटा पूल बनाए रखता है, एक /dev/random के अनुरूप और दूसरा /dev/urandom के अनुरूप, जैसा कि इसमें वर्णित है लेख 2015. अवरोधक पूल /dev/random के लिए पूल है; उस डिवाइस के लिए रीड्स ब्लॉक हो जाएगा (मतलब उसका नाम) जब तक कि अनुरोध को पूरा करने के लिए सिस्टम से "पर्याप्त" एन्ट्रापी एकत्र नहीं कर ली जाती। यदि पूल में पर्याप्त एन्ट्रापी नहीं है तो इस फ़ाइल से आगे की पठन सामग्री भी अवरुद्ध हो जाती है।

लॉक पूल को हटाने का मतलब है कि /dev/random से पढ़ना getrandom() की तरह व्यवहार करता है, जिसमें झंडे शून्य पर सेट होते हैं (और GRND_RANDOM ध्वज को एक noop में बदल देता है)। एक बार क्रिप्टोग्राफ़िक रैंडम नंबर जेनरेटर (सीआरएनजी) शुरू हो जाने के बाद, /dev/random से रीडिंग और getrandom(...,0) पर कॉल ब्लॉक नहीं होगी और रैंडम डेटा की अनुरोधित मात्रा वापस कर दी जाएगी।

लुटोमिरस्की कहते हैं: “मेरा मानना ​​है कि लिनक्स ब्लॉकिंग पूल अप्रचलित हो गया है। सीआरएनजी लिनक्स ऐसा आउटपुट उत्पन्न करता है जो कुंजी पीढ़ी के लिए भी उपयोग करने के लिए पर्याप्त है। अवरोधक पूल किसी भी भौतिक अर्थ में मजबूत नहीं है और इसे समर्थन देने के लिए संदिग्ध मूल्य के बहुत सारे बुनियादी ढांचे की आवश्यकता होती है।

परिवर्तन यह सुनिश्चित करने के लक्ष्य के साथ किए गए थे कि मौजूदा कार्यक्रम वास्तव में प्रभावित नहीं होंगे, और वास्तव में, जीएनयूपीजी कुंजी पीढ़ी जैसी चीजों के लिए लंबे इंतजार के साथ कम समस्याएं होंगी।

“ये एपिसोड किसी भी मौजूदा कार्यक्रम को बाधित नहीं करने चाहिए। /dev/urandom अपरिवर्तित रहता है। /dev/random अभी भी बूट पर तुरंत ब्लॉक करता है, लेकिन यह पहले की तुलना में कम ब्लॉक करता है। getentropy() मौजूदा झंडों के साथ ऐसा परिणाम देगा जो व्यावहारिक उद्देश्यों के लिए पहले की तरह ही उपयुक्त है।"

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

स्टीफ़न मुलर ने सुझाव दिया कि उनका सेट पैच लिनक्स के लिए रैंडम नंबर जेनरेटर (एलआरएनजी) (वर्तमान में संस्करण 26 जारी) उन अनुप्रयोगों के लिए सही रैंडम नंबर प्रदान करने का एक तरीका हो सकता है जिन्हें इसकी आवश्यकता है। LRNG "रैंडम बिट्स उत्पन्न करने के लिए उपयोग किए जाने वाले एन्ट्रॉपी स्रोतों पर SP800-90B दिशानिर्देशों का पूरी तरह से अनुपालन करता है", जो इसे सरकारी मानकों की समस्या का समाधान बनाता है।
मैथ्यू गैरेट ने "सच्चे यादृच्छिक डेटा" शब्द पर आपत्ति जताई, यह देखते हुए कि नमूना किए गए उपकरणों को सिद्धांत रूप से सटीक रूप से मॉडल किया जा सकता है ताकि उन्हें पूर्वानुमानित बनाया जा सके: "हम यहां क्वांटम घटनाओं का नमूना नहीं ले रहे हैं।"

मुलर ने जवाब दिया कि यह शब्द एक यादृच्छिक संख्या जनरेटर का वर्णन करने के लिए जर्मन मानक एआईएस 31 से आया है जो केवल "उसी दर पर परिणाम उत्पन्न करता है जिस दर पर अंतर्निहित शोर स्रोत एन्ट्रापी पैदा करता है।"

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

जैसा कि लुटोमिरस्की ने कहा: “इससे समस्या का समाधान नहीं होता। यदि दो अलग-अलग उपयोगकर्ता gnupg जैसे बेवकूफी भरे प्रोग्राम चलाते हैं, तो वे एक-दूसरे को ख़त्म कर देंगे। मैं देख रहा हूं कि वर्तमान में /dev/random के साथ दो मुख्य समस्याएं हैं: यह DoS (यानी संसाधन की कमी, दुर्भावनापूर्ण प्रभाव या कुछ इसी तरह) से ग्रस्त है, और चूंकि इसका उपयोग करने के लिए किसी विशेषाधिकार की आवश्यकता नहीं है, इसलिए इसका दुरुपयोग भी हो सकता है। Gnupg गलत है, यह पूरी तरह से ध्वस्त हो गया है। यदि हम एक नया गैर-विशेषाधिकार प्राप्त इंटरफ़ेस जोड़ते हैं जिसका उपयोग gnupg और इसी तरह के प्रोग्राम करेंगे, तो हम फिर से हार जाएंगे।"

म्यूएलर ने नोट किया कि getrandom() को जोड़ने से अब GnuPG को इस इंटरफ़ेस का उपयोग करने की अनुमति मिल जाएगी, क्योंकि यह आवश्यक गारंटी प्रदान करेगा कि पूल प्रारंभ हो गया है। जीएनयूपीजी डेवलपर वर्नर कोच के साथ चर्चा के आधार पर, म्यूएलर का मानना ​​है कि गारंटी ही एकमात्र कारण है जिससे जीएनयूपीजी वर्तमान में सीधे /dev/random से पढ़ता है। लेकिन अगर कोई विशेषाधिकार रहित इंटरफ़ेस है जो सेवा से इनकार करने के लिए अतिसंवेदनशील है (जैसा कि /dev/random आज है), तो ल्यूटोमिरस्की का तर्क है कि कुछ अनुप्रयोगों द्वारा इसका दुरुपयोग किया जाएगा।

ऐसा प्रतीत होता है कि लिनक्स के रैंडम नंबर सबसिस्टम के डेवलपर थियोडोर यू टाक त्सो ने ब्लॉकिंग पूल की आवश्यकता के बारे में अपना विचार बदल दिया है। उन्होंने कहा कि इस पूल को हटाने से प्रभावी रूप से इस विचार से छुटकारा मिल जाएगा कि लिनक्स में एक वास्तविक यादृच्छिक संख्या जनरेटर (TRNG) है: "यह बकवास नहीं है, क्योंकि *बीएसडी ने हमेशा यही किया है।"

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

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

“कर्नेल इस बात की कोई गारंटी नहीं दे सकता है कि शोर स्रोत को ठीक से चिह्नित किया गया है या नहीं। जीपीजी या ओपनएसएसएल डेवलपर को जो एकमात्र चीज मिल सकती है, वह एक अस्पष्ट भावना है कि ट्रूरैंडम "बेहतर" है, और चूंकि वे अधिक सुरक्षा चाहते हैं, इसलिए वे निस्संदेह इसका उपयोग करने का प्रयास करेंगे। किसी बिंदु पर इसे अवरुद्ध कर दिया जाएगा, और जब कोई अन्य स्मार्ट उपयोगकर्ता (संभवतः एक वितरण विशेषज्ञ) इसे इनिट स्क्रिप्ट में डालता है और सिस्टम काम करना बंद कर देता है, तो उपयोगकर्ताओं को केवल लिनस टोरवाल्ड्स से ही शिकायत करनी होगी।

काओ क्रिप्टोग्राफरों और उन लोगों को, जिन्हें वास्तव में टीआरएनजी की आवश्यकता है, उपयोगकर्ता स्थान में अपनी स्वयं की एन्ट्रापी का उपयोग करने का एक तरीका देने की भी वकालत करते हैं, जिसे वे उचित समझें। उनका कहना है कि एन्ट्रापी एकत्र करना ऐसी प्रक्रिया नहीं है जिसे कर्नेल द्वारा समर्थित सभी विभिन्न हार्डवेयर पर किया जा सकता है, न ही कर्नेल स्वयं विभिन्न स्रोतों द्वारा प्रदान की गई एन्ट्रापी की मात्रा का अनुमान लगा सकता है।

"कर्नेल को अलग-अलग शोर स्रोतों को एक साथ नहीं मिलाना चाहिए, और इसे निश्चित रूप से यह जानने का दावा करने की कोशिश नहीं करनी चाहिए कि जब यह एक अत्यंत सरल सीपीयू पर किसी प्रकार का "ट्विची एन्ट्रॉपी गेम" खेलने की कोशिश कर रहा है तो इसे कितने बिट एन्ट्रॉपी मिल रही है। उपभोक्ता उपयोगकर्ताओं के लिए आर्किटेक्चर। आईओटी/एम्बेडेड मामले जहां सब कुछ एक मास्टर ऑसिलेटर के साथ सिंक से बाहर है, जहां रजिस्टर को फिर से व्यवस्थित करने या नाम बदलने आदि के लिए कोई सीपीयू निर्देश नहीं है।"

“आप ऐसे उपकरण उपलब्ध कराने के बारे में बात कर सकते हैं जो इन गणनाओं को करने का प्रयास करते हैं, लेकिन ऐसी चीजें प्रत्येक उपयोगकर्ता के हार्डवेयर पर की जानी चाहिए, जो कि अधिकांश वितरण उपयोगकर्ताओं के लिए व्यावहारिक नहीं है। यदि यह केवल क्रिप्टोग्राफरों के लिए है, तो इसे उनके उपयोगकर्ता स्थान में करने दें। और आइए GPG, OpenSSL इत्यादि को सरल न बनाएं ताकि हर कोई कहे "हम "सच्ची यादृच्छिकता" चाहते हैं और इससे कम पर सहमत नहीं होंगे।" हम इस बारे में बात कर सकते हैं कि हम क्रिप्टोग्राफरों को इंटरफ़ेस कैसे प्रदान करते हैं ताकि वे प्राथमिक शोर स्रोतों तक पहुंच कर उन्हें आवश्यक जानकारी प्राप्त कर सकें, अलग और नामित किया जा सके, और शायद किसी तरह शोर स्रोत खुद को लाइब्रेरी या उपयोगकर्ता स्पेस एप्लिकेशन में प्रमाणित कर सके।"

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

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

कुछ विज्ञापन 🙂

हमारे साथ रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक रोचक सामग्री देखना चाहते हैं? आदेश देकर या मित्रों को अनुशंसा करके हमारा समर्थन करें, डेवलपर्स के लिए क्लाउड VPS $4.99 से शुरू, प्रवेश स्तर के सर्वरों का एक अनूठा एनालॉग, जिसका आविष्कार हमने आपके लिए किया था: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई $19 से या सर्वर कैसे साझा करें? (RAID1 और RAID10 के साथ उपलब्ध, 24 कोर तक और 40GB DDR4 तक)।

एम्स्टर्डम में इक्विनिक्स टियर IV डेटा सेंटर में Dell R730xd 2x सस्ता है? केवल यहां 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीवी $199 से नीदरलैंड में! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 से! के बारे में पढ़ा इन्फ्रास्ट्रक्चर कॉर्प का निर्माण कैसे करें। एक पैसा के लिए 730 यूरो मूल्य के डेल R5xd E2650-4 v9000 सर्वर के उपयोग के साथ वर्ग?

स्रोत: www.habr.com