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 असू शकते, आणि प्रभावी कॉन्फिगरेशन हे एकत्रित परिणाम आहे. systemd जसे पाहते तसे unit छापा, सहाय्यक स्वतःला उंचावू शकतो का हे ठरवणाऱ्या सँडबॉक्स सेटिंग्जसह. या टप्प्यावर फक्त-वाचन तपासणी पुरेशी आहे.
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 अजूनही त्याची सेवा करत असल्याची खात्री करा.