विशेषाधिकार घटाने के बाद: कौन-सी OpenVPN फ़ाइलें अब भी काम करती हैं?
घटाने से पहले खोले गए डिस्क्रिप्टर अब भी काम करते हैं; बाद में फिर से खुलने वाले पथ नहीं। तय करें कि आपके सेटअप को तीन रनटाइम फ़ाइलों में से कौन-सी फिर से खोलनी होगी।
लंबा अपटाइम केवल यह सिद्ध करता है कि उस क्षण डेमन के पास जो विशेषाधिकार थे, उन्हीं के साथ शुरुआत सफल हुई। यहाँ महत्वपूर्ण विफलताएँ बाद में आती हैं: नया क्लाइंट जुड़ता है, निरसन सूची बदली जाती है, सहायक स्क्रिप्ट को फ़ाइल लिखनी होती है। इनमें से हर एक बिना विशेषाधिकार वाले खाते द्वारा की गई नई खोल है, जिसका अपना अनुमति प्रश्न और अपना त्रुटि संदेश है। तीन निर्णय काम करती रहने वाली कॉन्फ़िगरेशन को अगली घटना में विफल होने वाली से अलग करते हैं।
पहले लोड हुए और बाद में खुलने वाले हिस्से को अलग करें
डिस्क्रिप्टर किसी खुली फ़ाइल-विवरण पर एक हैंडल है, और प्रवेश मोड उस विवरण के बनते समय तय हुआ था। बाद में प्रक्रिया का उपयोगकर्ता बदलने से हैंडल बंद नहीं होता, इसलिए root के रूप में पढ़ी गई कुंजी फ़ाइल घटाने के बाद भी काम करती है। मोड भी नहीं बदलता: पढ़ने के लिए खुला हैंडल लिखने योग्य नहीं होता, और लिखने योग्य हैंडल केवल इस कारण नहीं हटाया जाता कि खाते ने पथ पर अपने अधिकार खो दिए। ये दो तथ्य इन रिपोर्टों का अधिकांश आश्चर्यजनक व्यवहार समझाते हैं।
दूसरा आधा भाग स्मृति है। डेमन प्रमाणपत्र का विश्लेषण कर सकता है, विश्लेषित सामग्री रख सकता है और फ़ाइल बंद कर सकता है; उपयोग में जो रहता है वह डेटा है, खुली फ़ाइल नहीं। इसलिए चालू ट्रैफ़िक न तो यह सिद्ध करता है कि कोई डिस्क्रिप्टर खुला है और न ही यह कि पथ का नाम पहुँच योग्य है। यह केवल सिद्ध करता है कि वर्तमान सत्र के लिए आवश्यक सामग्री पहले प्राप्त की गई थी।
बाद में खोलना दूसरा लेनदेन है। यह वर्तमान क्रेडेंशियल, वर्तमान सुरक्षा संदर्भ और वर्तमान माउंट दृश्य के अंतर्गत चलता है, इसलिए शुरुआत में पठनीय पथ अगले कनेक्शन पर अस्वीकार हो सकता है। रोटेशन एक जाल जोड़ता है: उसी पथ नाम पर नई फ़ाइल लिखने से मौजूदा डिस्क्रिप्टर पुराने ऑब्जेक्ट से जुड़ा रह जाता है, इसलिए पुनः लोड सफल दिख सकता है जबकि डेमन अब भी पिछली सामग्री का उपयोग कर रहा हो। रोटेशन को प्रभावी मानने से पहले प्रक्रिया के पास के inode की तुलना डिस्क वाले से करें।
तीन रनटाइम पठनों और प्रत्येक के घटने का समय बताएँ
तीन संसाधन सामान्यतः आरंभ के बहुत बाद खुलते हैं, और अलग-अलग क्षणों में विफल होते हैं। किसी विशिष्ट क्लाइंट की कॉन्फ़िगरेशन फ़ाइल तब पढ़ी जाती है जब वह क्लाइंट जुड़ता है, इसलिए एक उपयोगकर्ता के लिए यह टूट सकती है जबकि बाकी चलते रहते हैं। निरसन डेटा सहकर्मी प्रमाणीकरण के दौरान और फ़ाइल के बदले जाने पर फिर देखा जाता है। अस्थायी निर्देशिका को तभी छुआ जाता है जब कोई स्क्रिप्ट या प्लगइन कुछ लिखता है।
तीनों में से कोई भी आरंभ पथ का नहीं है, इसलिए हफ़्तों तक स्वस्थ रहा सर्वर अगले कनेक्शन पर विफल हो सकता है। श्रेणी सुधार के स्वामी का भी नाम लेती है: पहले दो डेमन खाते के अंतर्गत कॉन्फ़िगरेशन पर पठन अनुमतियाँ हैं, और तीसरा संकीर्ण उद्देश्य का लिखने योग्य स्थान है।
| Path reopened later | What triggers the open | First sign when it fails |
|---|---|---|
| Client configuration file | A connection for that client identity | One client rejected while others connect |
| Revocation data | Peer authentication, including after replacement | Revoked and valid peers both refused |
| Script or plugin temporary directory | A helper needs to create a file | The helper exits with a path error |
persist-key अधिकांश लोगों की अपेक्षा से अधिक संकीर्ण प्रश्न का उत्तर देता है। यह दस्तावेज़ित SIGUSR1 और ping-restart रीसेट के दौरान कुंजी फ़ाइल को खुला रखता है, और CCD फ़ाइलों, निरसन डेटा, सहायक निष्पादन योग्य या पूर्ण प्रक्रिया पुनःआरंभ के लिए कुछ नहीं करता। वे अब भी अपने स्वयं के खोलने के पथ अपनाते हैं, उस समय चल रहे किसी भी खाते के अंतर्गत।
खाते और उसकी वास्तविक दृष्टि की पुष्टि करें
यूनिट फ़ाइल पर भरोसा करने के बजाय चल रहे डेमन से पूछें कि वह कौन-सा खाता उपयोग कर रहा है, फिर उत्तर की तुलना उससे करें जो यूनिट तय करती है। असंगति पहली हल करने योग्य बात है, क्योंकि हर बाद की अनुमति जाँच उसी के रूप में चलती है जो प्रक्रिया वास्तव में है। फिर पथ को एक-एक घटक के रूप में चलें; पारगमन का मूल्यांकन हर स्तर पर होता है, इसलिए ऐसी निर्देशिका के भीतर पठनीय फ़ाइल जिसमें से गुजरा नहीं जा सकता, अपठनीय ही रहती है। अंतिम फ़ाइल मोड पहला नहीं, अंतिम प्रश्न है।
नामस्थान और सेवा सैंडबॉक्स ऐसी सीमाएँ जोड़ते हैं जिनका वर्णन स्वामित्व और मोड बिट नहीं करते। आपके शेल में दिखने वाला पथ chroot, माउंट नामस्थान या होम निर्देशिकाएँ छिपाने वाली यूनिट के भीतर अनुपस्थित या केवल-पठन हो सकता है। सुरक्षा मॉड्यूल एक और परत जोड़ते हैं, इसलिए पठनीय दिखने वाली फ़ाइल खुलते समय फिर भी अस्वीकार हो सकती है।
ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/aliceव्यवस्थापक के शेल में सफल पठन उन संयुक्त शर्तों में से एक भी नहीं जाँचता। जाँच को डेमन खाते के रूप में, उसी नामस्थान और सैंडबॉक्स के साथ चलाएँ, या स्वीकारें कि परिणाम सर्वर नहीं बल्कि आपके शेल का वर्णन करता है। तीसरा आदेश उस परीक्षण का सस्ता संस्करण है: यह हर घटक का मोड छापता है और पहले उसी पर विफल होता है जिसे डेमन खाता पार नहीं कर सकता।
रनटाइम लेखन को अपनी अलग निर्देशिका दें
पठन सूची का केवल आधा है। सहायक स्क्रिप्ट को स्थिति फ़ाइल बनानी पड़ सकती है, प्लगइन को अपनी कॉन्फ़िगरेशन के पास स्थिति लिखनी पड़ सकती है, और वे लेखन कॉन्फ़िगरेशन वृक्ष को लिखने योग्य बनाने से आच्छादित नहीं होते। उस विशिष्ट निर्देशिका को वह लेखन अनुमति दें जो उसके कार्य को चाहिए, ऐसे स्वामी और मोड के साथ जिसे आप समझा सकें। जो केवल पढ़ा जाता है उसके लिए केवल-पठन पहुँच को प्राथमिकता दें।
निजी कुंजी की अनुमतियाँ नीति फ़ाइलों से अलग रखें। रीसेट के बाद फिर पढ़ी जाने वाली कुंजी की आवश्यकता हर कनेक्शन पर पढ़ी जाने वाली क्लाइंट फ़ाइल से भिन्न है, और दोनों के लिए एक उदार मोड समस्या के अनुरोध से अधिक पहुँच देता है। संकीर्ण स्वामित्व वाला समर्पित डेमन खाता विस्तृत समूह से जाँचना आसान है। जब कुंजी को रीसेट के बाद भी टिकना हो, persist-key निर्देशिका को चौड़ा करने के बजाय फिर से पढ़ना हटा देता है।
उस घटना से निर्णय लें जिसे आप दोहरा सकते हैं
जीवंत सुरंग कोड में केवल एक पथ सिद्ध करती है। जिस घटना को फ़ाइल चाहिए, वही उस खोल को आच्छादित करने वाला एकमात्र परीक्षण है जो आपके लिए मायने रखती है, चाहे वह नया क्लाइंट कनेक्शन हो, बदली गई निरसन फ़ाइल हो, अनुमत नरम रीसेट हो या नियोजित पुनःआरंभ हो। घटना चुनें, उसे चलाएँ, और अंतिम नहीं पहली त्रुटि रखें।
नरम रीसेट के लिए एक सिग्नल और यूनिट का लॉग दिखाते हैं कि कुंजी फिर पढ़ी गई या नहीं। सिग्नल भेजें, फिर यूनिट द्वारा लिखी अंतिम पंक्तियाँ पढ़ें:
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pagerयह निष्कर्ष न निकालें कि केवल विशेषाधिकार घटने से समझौता किया गया डेमन अब फ़ाइलें नहीं बदल सकता। वह अब भी क्या कर सकता है यह शेष क्रेडेंशियल, उसकी क्षमताओं, उन निर्देशिकाओं जिनमें वह लिख सकता है और उसके पास अब भी मौजूद किसी भी लिखने योग्य डिस्क्रिप्टर पर निर्भर है। विशेषाधिकार घटाना अधिकार को संकीर्ण करता है, और रनटाइम खोलों की सूची दिखाती है कि कितना। उस सीमा को कॉन्फ़िगरेशन के पास लिखें ताकि अगले व्यक्ति को उसे फिर से खोजना न पड़े।