PAM प्रमाणीकरण हाथ से चलाने पर काम करता है, पर OpenVPN सेवा के रूप में विफल होता है
root शेल से काम करने वाला और systemd के अंतर्गत विफल होने वाला PAM लॉगिन पासवर्ड नहीं, सहायक की ओर इशारा करता है। विशेषाधिकार, फ़ाइल पहुँच और SELinux अलग करें।
PAM के माध्यम से प्रमाणीकरण तब सफल हो सकता है जब आप क्लाइंट को हाथ से चलाते हैं, और AUTH_FAILED के साथ विफल हो जाता है जब systemd वही प्रोफ़ाइल शुरू करता है। इन चलानों के बीच पासवर्ड नहीं बदलता; जो बदलता है वह उस प्रक्रिया के आसपास के प्रतिबंधों का समूह है जो PAM से प्रश्न पूछती है। PAM एक सहायक के माध्यम से उत्तर देता है, जिसकी अपने स्वयं के क्रेडेंशियल बदलने की क्षमता वही है जो एक सख्त unit हटा देता है। क्षमता-सूची को छूने से पहले वह सहायक और उसकी ज़रूरी सीमा खोजें।
unix_chkpwd वह बाइनरी है जो PAM के प्रश्न का उत्तर देती है
स्थानीय पासवर्ड प्रमाणीकरण के साथ, pam_unix शायद ही कभी स्वयं हैश फ़ाइल पढ़ता है। यह unix_chkpwd चलाता है, जिसे वितरण setuid root या setgid shadow के रूप में संस्थापित करते हैं ताकि एक पासवर्ड ऐसी प्रक्रिया की ओर से जाँचा जा सके जिसका /etc/shadow पढ़ने से कोई लेना-देना नहीं है। उस पहचान को पाने की क्षमता हटा दें और सहायक जाँच पूरी नहीं कर सकेगा, इसलिए मॉड्यूल साधारण प्रमाणीकरण विफलता लौटाता है।
तब विफलता क्लाइंट को दिखने वाले हर लॉग में क्रेडेंशियल समस्या जैसी दिखती है। यही जाल है: क्लाइंट बताता है कि PAM ने उसे क्या कहा, और PAM केवल बताता है कि स्टैक ने ना कहा। root के रूप में सहायक को हाथ से चलाना भी कुछ सिद्ध नहीं करता, क्योंकि वह उस विशेषाधिकार पथ का अभ्यास करता है जिसका सेवा कभी उपयोग नहीं करती। जो unit systemd ने वास्तव में लोड किया उसे पढ़ें, फिर किए गए प्रयास के लिए सिस्टम लॉग पढ़ें। ये दो दृश्य सैंडबॉक्स समस्या को गलत-पासवर्ड समस्या से अलग करते हैं।
पासवर्ड लॉग पढ़ने से पहले 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 अभी भी उसकी सेवा कर रहा है।