टर्मिनलमा रुट, 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 सम्भवतः तपाईंको समस्या होइन, र मार्ग, स्यान्डबक्स वा अनुमतिका मुद्दा अझै खुला छन्।