टर्मिनल में रूट, 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 संभवतः आपकी समस्या नहीं है, और पथ, सैंडबॉक्स या अनुमति के मुद्दे अभी भी खुले हैं।