टर्मिनलमध्ये रूट, SELinux अंतर्गत नाकारले: हुक का अयशस्वी होतो

तुम्ही up स्क्रिप्ट रूट म्हणून चालवता, ती पूर्ण होते, आणि सेवा तिला कॉल करते तेव्हा तीच स्क्रिप्ट अयशस्वी होते। फाइलच्या परवानग्यांमध्ये काहीही बदललेले नाही, त्यामुळे पुढचे साहजिक पाऊल त्या पुन्हा सैल करणे आहे, ज्यामुळे काहीही सुटत नाही। SELinux होस्टवर निर्णायक घटक अनेकदा प्रक्रिया कोण आहे हा नसतो, तर ती कोणत्या डोमेनमध्ये चालते हा असतो, आणि मर्यादित डोमेनमधील रूटही मर्यादितच राहतो।

तीच आज्ञा, दोन वेगवेगळे सुरक्षा डोमेन

प्रकार अंमलबजावणी स्रोत डोमेन, लक्ष्य लेबल आणि विनंती केलेली क्रिया एकत्र मूल्यांकन करते। तुमचे टर्मिनल सत्र अमर्यादित किंवा प्रशासकीय डोमेनमध्ये चालते, आणि डेमन त्याच्या युनिटला दिलेल्या डोमेनमध्ये चालते। त्यामुळे एकसारख्या आज्ञा वेगळे निर्णय देतात, आणि हा फरक धोरणातील बग नसून हेतुपुरस्सर आहे।

म्हणूनच दोन्ही रनची तुलना केवळ त्यांच्या संदर्भांची तुलना केल्यासच उपयुक्त ठरते। तीच आज्ञा शेलमधून आणि हुकमधून चालवा; शेलची आवृत्ती बायनरी अस्तित्वात आहे आणि वितर्क बरोबर आहेत हे सिद्ध करते, पण सेवेला ती चालवण्याची परवानगी आहे का याबद्दल काहीही सिद्ध करत नाही। दोन्ही मार्गांनी चालवा आणि केवळ एक्झिट कोड नव्हे, डोमेनची तुलना करा। हीच तुलना अस्पष्ट परवानगीच्या तक्रारीचे एका डोमेन आणि एका लेबलबद्दलच्या ठोस प्रश्नात रूपांतर करते।

या दोषाचे पारंपरिक स्वरूप म्हणजे बाह्य साधनाला कॉल करणारा सहाय्यक। हुक स्वतःला परवानगी असू शकते, पण तो ज्या साधनाला कॉल करतो त्यावर असे लेबल असते जे सेवा डोमेन चालवू शकत नाही, किंवा ते अशा डिरेक्टरीत लिहिते जिचे लेबल ते प्रतिबंधित करते।

हुक त्रुटीच्या शेजारी AVC रेकॉर्ड वाचा

AVC नाकार प्रकरण ठरवणारी क्षेत्रे नावाने सांगते: प्रक्रियेचा स्रोत संदर्भ, ऑब्जेक्टचा लक्ष्य संदर्भ, ऑब्जेक्ट वर्ग आणि नाकारलेली विशिष्ट परवानगी। सिद्धांत मांडण्यापूर्वी चारही वाचा, कारण एक्झिक्युटवरील नाकार आणि राइटवरील नाकार यांच्या दुरुस्त्या पूर्णपणे वेगळ्या आहेत।

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

स्रोत संदर्भ सेवा प्रत्यक्षात ज्या डोमेनमध्ये चालते त्याला जुळला पाहिजे, आणि लक्ष्य संदर्भ क्रियेने स्पर्श केलेल्या फाइल किंवा डिरेक्टरीच्या लेबलला जुळला पाहिजे। यापैकी कोणतेही तुम्ही पकडत असलेल्या त्रुटीशी जुळत नसेल, तर तुम्ही दुसरी घटना वाचत आहात।

रेकॉर्डच्या शेजारी धोरणाची आवृत्ती आणि एक्झिक्युटेबलचा नेमका मार्ग नोंदवा। एका वितरणाच्या धोरणात दिसणारे डोमेन नाव त्या इन्स्टॉलेशनबद्दलचा पुरावा आहे, दुसरे बिल्ड तेच नियम पुरवते याची हमी नाही। हाच संदर्भ दुसऱ्याला त्याच्या स्वतःच्या होस्टवर तुमचा निष्कर्ष पुन्हा तयार करू देतो। तो नसेल तर रेकॉर्ड पुराव्याऐवजी किस्सा म्हणून वाचला जातो।

लेबल, कॉन्फिगरेशन किंवा धोरण: तीन दुरुस्त्या

पहिली दुरुस्ती म्हणजे फाइलच्या इन्स्टॉल केलेल्या जागेशी न जुळणारे लेबल। cp ने जागेवर कॉपी केलेली किंवा एडिटरने लिहिलेली स्क्रिप्ट असे डीफॉल्ट लेबल घेऊन येऊ शकते जे सेवा डोमेन वापरू शकत नाही, आणि अपेक्षित संदर्भ पुनर्संचयित केल्यास धोरणाला स्पर्श न करताही ते सुटते।

दुसरी म्हणजे कॉन्फिगरेशन। वितरण क्रिया चालवण्याचा समर्थित मार्ग, सहाय्यकासाठी दस्तऐवजीकृत डिरेक्टरी, किंवा ती आधीच परवानगी देणारे अद्ययावत धोरण पॅकेज देऊ शकते। तुमची मांडणी समर्थित मांडणीत बदलणे धोरण लिहिण्यापेक्षा स्वस्त आहे आणि अद्ययावतांना टिकते।

तिसरा म्हणजे खरोखर गहाळ असलेला नियम, आणि तो शेवटचा उपाय असावा। ऑडिट साधनांनी उमेदवार तयार करा, तो प्रत्यक्षात कशाला परवानगी देतो ते वाचा, तुम्ही पाहिलेल्या क्रिया आणि डोमेनपर्यंत तो मर्यादित करा, आणि उत्पादनाजवळ जाण्यापूर्वी दुसऱ्याकडून त्याचे पुनरावलोकन करून घ्या।

जुना allow मॉड्यूल उत्तर का नाही

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

हे पुढील अपयशही लपवते। विस्तृत क्रियावर्गाला परवानगी देणारे मॉड्यूल ही त्रुटी नाहीशी करेल आणि पुढील त्रुटीला आरोपित करणे खूप कठीण अशी गोष्ट बनवेल। नंतर मॉड्यूल काढणेही असे बदल आहे जे कोणीही नियोजित करू इच्छित नाही, त्यामुळे शॉर्टकट कायमचा होण्याकडे झुकतो।

शिस्तबद्ध तुलना तुम्ही वाचू शकता त्या नाकार आणि तुम्ही सुचवत असलेल्या बदलामधील आहे। Red Hat चे SELinux समस्या निवारण मार्गदर्शक लेबलिंग आणि कॉन्फिगरेशन तपासण्या निर्माण झालेल्या धोरणापूर्वी ठेवते, तेही याच कारणामुळे। रेकॉर्डमध्ये जुळणारा नाकार नसल्यास, SELinux बहुधा तुमची समस्या नाही, आणि मार्ग, सँडबॉक्स किंवा परवानगीचे प्रश्न अजूनही खुले आहेत।