VPN प्रमाणपत्र को स्थानांतरित करने से उसका SELinux लेबल क्यों टूटता है

प्रमाणपत्र सही निर्देशिका में पठनीय मोड और root स्वामित्व के साथ हो सकते हैं, और सेवा फिर भी बता सकती है कि वह फ़ाइल नहीं खोल सकती। SELinux प्रणाली में यह संयोजन अनुमतियों की ओर नहीं, बल्कि एक विशिष्ट तंत्र की ओर संकेत करता है। लेबल फ़ाइल के साथ गया, क्योंकि नाम बदलने से नई वस्तु नहीं बनती। inode ने वह सुरक्षा संदर्भ बनाए रखा जो उसके पास पुराने पथ पर था, और नए पथ की नीति को कभी अपना संदर्भ निर्धारित करने का अवसर नहीं मिला।

नाम बदलना वास्तव में एक लेबल के साथ क्या करता है

एक फ़ाइल अपना SELinux संदर्भ inode से जुड़े विशेषता-डेटा के रूप में रखती है। एक ही फ़ाइलसिस्टम के भीतर नाम बदलना निर्देशिका प्रविष्टि बदलता है और कुछ नहीं, जो तेज़ और परमाणु है, और यही कारण है कि संदर्भ स्थानांतरण के बाद भी बना रहता है। कोई नीति नहीं पूछी जाती, कोई डिफ़ॉल्ट लागू नहीं होता, और कोई चेतावनी नहीं छपती।

प्रतिलिपि करना अलग व्यवहार करता है। एक प्रतिलिपि गंतव्य निर्देशिका में नया inode बनाती है, और नीति उस निर्देशिका के प्रकार से संदर्भ निर्धारित करती है, इसलिए प्रतिलिपि किया गया प्रमाणपत्र सामान्यतः सही लेबल पाता है जबकि स्थानांतरित किया गया गलत ही रहता है। यही एक अंतर इस वर्ग के टिकटों में अधिकांश भ्रम समझाता है।

फ़ाइलसिस्टम के बीच स्थानांतरण प्रतिलिपि-अर्थशास्त्र पर लौटता है, इसलिए वही आदेश दो मशीनों पर अलग व्यवहार कर सकता है, यह निर्भर करता है कि /etc अपने अलग वॉल्यूम पर है या नहीं। यह निष्कर्ष निकालने से पहले कि उपकरण अविश्वसनीय है, इसे जाँचें। माउंट तालिका पर एक नज़र आपको बताती है कि आपने किस प्रकार का स्थानांतरण किया।

वर्तमान लेबल को अपेक्षित के सामने पढ़ें

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

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

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

फिर अंतर को वास्तविक अस्वीकृति से जोड़ें। बेमेल गलत लेबल का साक्ष्य है, यह प्रमाण नहीं कि सेवा उसके कारण विफल हुई, और लॉग में संबंधित अस्वीकृति के बिना लागू किया गया सुधार अतिरिक्त कदमों वाला अनुमान है।

अपवाद गढ़ने के बजाय मैपिंग बहाल करें

मानक स्थान के लिए नीति पहले से पथ को मैप करती है, इसलिए restorecon उसे लागू करता है और काम पूरा हो जाता है। दायरा उसी निर्देशिका तक रखें जिसे आप ठीक कर रहे हैं; पूरी फ़ाइलसिस्टम को फिर से लेबल करना धीमा, बाधाकारक है, और यह मूल गलती को बहुत बड़े परिवर्तन के नीचे दबा देता है।

कस्टम निर्देशिका के लिए क्रम मायने रखता है, और उसे उलटने से ऐसा आदेश बनता है जो कुछ भी बदले बिना सफलता बताता है। मैपिंग नीति में होती है, पुनःलेबलिंग अंत में होती है, और शुष्क प्रवाह दोनों से पहले होता है। उस अंतिम भाग को छोड़ना ही वह तरीका है जिससे कभी गलत न रहा पथ भी फिर से लेबल हो जाता है।

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon मैपिंग लागू करता है; वह एक गढ़ नहीं सकता। यदि कोई नियम पथ का वर्णन नहीं करता, तो बहाल करने के लिए कुछ नहीं है, इसीलिए स्थायी मैपिंग पुनःलेबलिंग से पहले मौजूद होनी चाहिए। लिख लें कि कौन-सा कॉन्फ़िगरेशन उस मैपिंग का स्वामी है, क्योंकि अन्यथा बाद का स्थानांतरण, पैकेज अद्यतन या पुनःलेबलिंग खराबी को फिर से बना देते हैं और अगला व्यक्ति शून्य से शुरू करता है।

chcon ही समाधान क्यों नहीं है

chcon सीधे फ़ाइल पर संदर्भ लिखता है। यह तुरंत प्रभावी होता है और उपलब्ध सबसे कम टिकाऊ विकल्प है, क्योंकि फ़ाइलसिस्टम की पुनःलेबलिंग नीति को फिर से लागू करती है और पूछे बिना मैन्युअल बदलाव फेंक देती है। फ़ाइल मरम्मत की हुई दिखती है और मरम्मत की एक समाप्ति तिथि है जिसे किसी ने नहीं लिखा। इसके बजाय आपको पथ का वर्णन करने वाला नियम चाहिए, ताकि वहाँ पहुँचने वाली हर फ़ाइल को स्वतः वही व्यवहार मिले।

इससे भी बुरा, यह गलत पाठ सिखाता है: अंतर्निहित मैपिंग अभी भी गायब है, इसलिए खराबी हफ़्तों बाद स्पष्ट ट्रिगर और उस उपाय की स्मृति के बिना लौट आती है। chcon का उपयोग केवल किसी परिकल्पना की पुष्टि के लिए अस्थायी प्रयोग के रूप में करें, फिर उसे ऐसी मैपिंग से बदलें जो अगली पुनःलेबलिंग में टिके रहे, और जाँचें कि प्रतिस्थापन वास्तव में अपनी जगह पर है।

जब लेबल सही हो और पहुँच फिर भी विफल हो

मूल निर्देशिकाओं से शुरू करें। पथ के हर घटक पर ट्रैवर्सल अनुमति जाँची जाती है, इसलिए जिस निर्देशिका में सेवा प्रवेश नहीं कर सकती, उसमें सही लेबल वाला प्रमाणपत्र भी अपठनीय रहता है। SELinux और सामान्य अनुमति दोनों को हर चरण की अनुमति देनी होगी, और एक को ठीक करने से दूसरा ठीक नहीं होता।

फिर प्रक्रिया की पहचान और सेवा के अपने सैंडबॉक्सिंग की जाँच करें। प्रतिबंधात्मक सैंडबॉक्स वाली इकाई ऐसी फ़ाइल तक पहुँच से इनकार कर सकती है जिसे नीति खुशी से अनुमति देती, और लॉग पंक्ति से दोनों कारण एक जैसे दिखते हैं। पुष्टि करें कि वास्तव में कौन-सी प्रक्रिया माँग रही है, न कि आप किसे माँगता हुआ मानते हैं।

याद रखें कि dontaudit नियम अस्वीकृति संदेशों को दबा सकते हैं, इसलिए खाली ऑडिट लॉग प्रमाण नहीं, कमज़ोर साक्ष्य है। यदि नीति सही दिखती है और पहुँच फिर भी विफल हो, तो व्यापक अनुमति मॉड्यूल बनाने से पहले जाँच करें, और लक्षण गायब करने के लिए SELinux को बंद न करें। दोनों शॉर्टकट ऐसी प्रणाली देते हैं जो काम करती दिखती है और ऐसा सुरक्षा रुख जिसे कोई वर्णित नहीं कर सकता। एक छोटी जाँच दोनों में से किसी से भी बेहतर है।