PAM प्रमाणीकरण हातले चलाउँदा काम गर्छ तर OpenVPN सेवाका रूपमा असफल हुन्छ
root शेलबाट काम गर्ने र systemd अन्तर्गत असफल हुने PAM लगइनले पासवर्ड होइन, सहायकतर्फ सङ्केत गर्छ। विशेषाधिकार, फाइल पहुँच र SELinux अलग गर्नुहोस्।
PAM मार्फत प्रमाणीकरण तपाईंले क्लाइन्ट हातले चलाउँदा सफल हुन सक्छ, र systemd ले त्यही प्रोफाइल सुरु गर्दा AUTH_FAILED सँग असफल हुन्छ। ती चलाउने क्रममा पासवर्ड बदलिँदैन; बदलिने चाहिँ PAM लाई प्रश्न सोध्ने प्रक्रियाका वरिपरिका प्रतिबन्धहरूको समूह हो। PAM एउटा सहायकमार्फत जवाफ दिन्छ जसको आफ्नै प्रमाणहरू बदल्ने क्षमता नै कठोर बनाइएको unit ले हटाउँछ। क्षमता-सूची छुनुअघि त्यो सहायक र त्यसलाई आवश्यक सीमा खोज्नुहोस्।
unix_chkpwd PAM को प्रश्नको जवाफ दिने बाइनरी हो
स्थानीय पासवर्ड प्रमाणीकरणसँग, pam_unix आफैले ह्यास फाइल विरलै पढ्छ। यसले unix_chkpwd चलाउँछ, जसलाई वितरणहरूले setuid root वा setgid shadow का रूपमा स्थापना गर्छन् ताकि /etc/shadow पढ्नुसँग कुनै काम नभएको प्रक्रियाको तर्फबाट एउटा पासवर्ड जाँच्न सकियोस्। त्यो पहिचान प्राप्त गर्ने क्षमता हटाउनुहोस् र सहायकले जाँच पूरा गर्न सक्दैन, त्यसैले मोड्युलले साधारण प्रमाणीकरण असफलता फर्काउँछ।
त्यसपछि असफलता क्लाइन्टले देख्न सक्ने हरेक लगमा प्रमाण समस्याजस्तो देखिन्छ। यही जाल हो: क्लाइन्टले PAM ले आफूलाई के भन्यो त्यो रिपोर्ट गर्छ, र PAM ले स्ट्याकले नाइ भन्यो भनेर मात्र रिपोर्ट गर्छ। root का रूपमा सहायक हातले चलाउनुले पनि केही प्रमाणित गर्दैन, किनकि त्यसले सेवाले कहिल्यै नप्रयोग गर्ने विशेषाधिकार मार्ग अभ्यास गर्छ। systemd ले वास्तवमा लोड गरेको unit पढ्नुहोस्, त्यसपछि गरेको प्रयासका लागि प्रणाली लग पढ्नुहोस्। यी दुई दृष्टिकोणले स्यान्डबक्स समस्यालाई गलत पासवर्ड समस्याबाट अलग गर्छन्।
पासवर्ड लग पढ्नुअघि unit पढ्नुहोस्
प्याकेज गरिएको unit मा तपाईंले नलेखेको drop-in हुन सक्छ, र प्रभावकारी कन्फिगरेसन मिलाइएको परिणाम हो। unit लाई systemd ले देखेजस्तै प्रिन्ट गर्नुहोस्, सहायकले आफैलाई उठाउन सक्छ कि भनी निर्धारण गर्ने स्यान्डबक्स सेटिङसँगै। यो चरणमा पढ्ने-मात्र निरीक्षण पर्याप्त छ।
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -bपहिलो आदेशले unit र यसका drop-in कहाँबाट आउँछन् देखाउँछ, जो महत्त्वपूर्ण छ किनकि महिनौं अघि थपिएको ओभरराइड किन छ भन्ने स्मृतिभन्दा लामो बाँच्छ। दोस्रोले अर्को दुई खण्ड निर्भर हुने स्यान्डबक्स मानहरू प्रिन्ट गर्छ।
तपाईंले देखेको कुरालाई त्यही वितरण र संस्करणको कार्यरत होस्टसँग तुलना गर्नुहोस्। User, CapabilityBoundingSet वा NoNewPrivileges मा भिन्नता ठोस सङ्केत हो; गद्य टिप्पणीमा भिन्नता होइन। केही बदल्नुअघि मानहरू लेख्नुहोस्, किनकि चलायमान लक्ष्यसँग पछिको तुलनाले केही प्रमाणित गर्दैन। यदि सेवा खाली bounding सेटसहित गैर-विशेषाधिकार खातामा चल्छ भने सहायकसँग काम गर्न लगभग केही हुँदैन।
प्रमाण रूपान्तरण, फाइल पहुँच र नीति तीन सीमा हुन्
exec का क्रममा के हुन्छ त्यसबाट सुरु गर्नुहोस्। setuid बाइनरी वा फाइल क्षमता बोकेको फाइलले प्रमाण रूपान्तरण निम्त्याउँछ, त्यसैले परिणामस्वरूप पहिचान कल गर्नेको निरन्तरता होइन। bounding सेटले यस्तो फाइलले के प्राप्त गर्न सक्छ सीमित गर्छ, र NoNewPrivileges ले setuid, setgid र फाइल-क्षमता प्राप्ति पूर्ण रूपमा रोक्छ। ती तीनमध्ये कुनै पनि सहायक रोक्न सक्छ जबकि सेवाका अन्य सबै कार्य अक्षुण्ण रहन्छन्।
त्यसपछि फराकिलो विवेकाधीन बाइपासलाई साँघुरो पढाइ-पहुँचबाट अलग गर्नुहोस्। CAP_DAC_OVERRIDE लगभग सबै ठाउँमा विवेकाधीन जाँचहरू छोड्छ, जबकि CAP_DAC_READ_SEARCH आफ्नै थप अधिकारसहित पढाइ र निर्देशिका-यात्रा समेट्छ। ती फरक प्रभाव-त्रिज्या भएका फरक उपकरण हुन्, र कुनै पनि PAM लाई shadow फाइल पढ्न देऊ भन्ने वाक्यको हिज्जे होइन।
अन्तमा सोध्नुहोस्, अनिवार्य नीतिले यो कार्यलाई सुरुमै अनुमति दिन्छ कि। Linux क्षमताले SELinux लाई अगाडि पार्दैन, र एउटा राख्नुले type enforcement नियमबारे केही प्रमाणित गर्दैन। फाइल-पहुँच अस्वीकृति र क्षमता अस्वीकृतिलाई फरक प्रमाणका रूपमा लिनुहोस्, किनकि तिनले फरक सुधार र प्रायः फरक मालिकको नाम लिन्छन्। रेकर्डको हरेक फाँट पढ्नुहोस्, केवल denied शब्द होइन। कुन कार्यान्वयन-योग्य फाइलले कार्य गर्यो, कुन डोमेनमा चल्यो, कुन प्रकारको लक्ष्य छोयो, कुन वस्तु-वर्ग संलग्न थियो र नीतिले कुन अनुमति अस्वीकार गर्यो — प्रत्येकले फरक तरिकाले उत्तर साँघुरो बनाउँछ।
अडिट लगबाट अस्वीकृति निकाल्नुहोस्
लागू गर्ने होस्टमा, अडिट ट्रेल अस्वीकृति रेकर्ड गर्ने एकमात्र ठाउँ हो। हालैका घटनाहरू सोध्नुहोस् र तिनलाई असफल लगइनको टाइमस्ट्याम्पसँग तुलना गरेर पढ्नुहोस्, अनुसन्धान सुरु गरेको समयसँग होइन।
ausearch -m AVC,USER_AVC -ts recentखाली नतिजा निर्दोषताको प्रमाण होइन। यसको अर्थ या त अडिटिङ सङ्कलन गरिरहेको छैन, वा तपाईंको विन्डोले प्रयास छुटायो, र नीति बहिष्कृत गर्नुअघि दुवै सम्भावना बहिष्कृत गर्नुपर्छ।
Red Hat को SELinux समस्या निवारण मार्गदर्शन लेबल र कन्फिगरेसन जाँचलाई allow नियम उत्पादन गर्नुअघि राख्छ, जो यो समस्याका लागि पनि सही क्रम हो। गलत लेबल भएको सहायक बाइनरी र नीतिको खाडलले समान अस्वीकृति उत्पादन गर्छन् तर फरक मर्मत आवश्यक पर्छ। लेबलिङ त्रुटिका लागि allow नियम उत्पादन गर्दा दोष लुकाइन्छ र अर्को प्याकेज अपडेटले त्यसलाई फेरि भित्र्याउन दिन्छ। कुनै पनि नीति लेख्नुअघि स्थापित सहायकको लेबल पुष्टि गर्नुहोस्।
एक स्वीकृत र एक अस्वीकृत लगइनले परिवर्तन प्रमाणित गर्नुहोस्
तपाईंले देखाएको सीमा मात्र बदल्नुहोस्, त्यसपछि दुवै नतिजा जाँच्नुहोस्। प्रमाणीकरण हुनुपर्ने खाता सफल हुनुपर्छ, र गलत पासवर्ड भएको खाता अझै असफल हुनुपर्छ। हरेक प्रयास सफल बनाउने परिवर्तनले प्रमाणीकरण मर्मत गर्नुको सट्टा हटाएको छ।
वास्तविक जडान प्रयास गर्नुहोस् र तुरुन्तै जर्नल पढ्नुहोस्। मर्मत प्रमाणित गर्ने लाइन त्यो प्रयासको pam_unix(openvpn:auth) प्रविष्टि हो: त्यहाँ प्रमाणीकरण सफल लेखिएको हुनुपर्छ, र कुनै पनि AVC रेकर्डले त्यही सेकेन्ड बोक्नु हुँदैन।
journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpnकार्यरत टनेललाई पुनः जडान पनि चाहिन्छ, किनकि स्यान्डबक्स परिवर्तनले पहिलोभन्दा दोस्रो जडान बढी पटक तोड्छ। पुनः जडानपछि स्थापित सकेट जाँच्नुहोस् र त्यही unit ले अझै त्यसको सेवा गरिरहेको पुष्टि गर्नुहोस्।