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 बंद करू नका। दोन्ही शॉर्टकट अशी प्रणाली देतात जी काम करत असल्यासारखी दिसते आणि असे सुरक्षा स्थान ज्याचे कोणीही वर्णन करू शकत नाही। थोडक्यात तपासणी दोन्हींपेक्षा चांगली आहे।