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 बन्द नगर्नुहोस्। दुवै छोटो बाटोले काम गरेजस्तो देखिने प्रणाली र कसैले वर्णन गर्न नसक्ने सुरक्षा अडान दिन्छन्। छोटो अनुसन्धान दुवैभन्दा राम्रो हुन्छ।