nosuid VPN सहाय्यकाला root होण्यापासून का प्रतिबंध करते

डिस्क एन्क्रिप्शन आणि nosuid माउंट एकाच कल्पनेचे प्रकार वाटतात, पण त्यांचा काहीच संबंध नाही। एक स्थिर अवस्थेतील डेटा संरक्षित करते, आणि दुसरे प्रोग्राम सुरू होण्याच्या क्षणी कर्नेल विशेषाधिकार बिटचा आदर करेल की नाही हे ठरवते। जो सहाय्यक आपली अपेक्षित ओळख गाठू शकत नाही तो दुसऱ्याबद्दल तक्रार करत असतो। पहिलेच कारण आहे असे गृहीत धरल्यामुळे लोक कधीही बिघडलेल्या नसलेल्या क्लायंट पुन्हा इंस्टॉल करायला जातात।

दोन असंबद्ध गुणधर्म

मशीन बंद असताना ब्लॉक कोण वाचू शकतो याचे उत्तर डिस्क एन्क्रिप्शन देते। कोणी फाइल चालवल्यावर कर्नेल तिच्या मोड बिट्ससोबत काय करेल याचे उत्तर माउंट पर्याय देते। पहिल्यातील काहीही दुसऱ्याला मर्यादित करत नाही, आणि पूर्णपणे एन्क्रिप्टेड लॅपटॉप सर्व निर्बंधांसह फाइल सिस्टम माउंट करू शकतो।

दोन्हींना एकच गुणधर्म म्हणून वाचल्यामुळे एन्क्रिप्टेड होम root प्रवेश रोखते हा सिद्धांत तयार होतो। तो सिद्धांत टिकतो कारण दोन्ही लक्षणे एकाच मशीनवर दिसतात, कारण त्यांचे कारण एक आहे म्हणून नाही।

संक्रमण खरोखर काय दाबते

execve संदर्भ स्पष्ट करतो की set-user-ID असलेली कार्यान्वित फाइल नव्या प्रक्रियेची प्रभावी ओळख फाइलच्या मालकाची कशी करते। त्याच पानावर ते संक्रमण दाबणाऱ्या अटी आणि गट ओळखकर्त्यांसाठी त्यांची समतुल्य अटी सूचीबद्ध आहेत: no_new_privs सेटिंग, nosuid ने माउंट केलेली फाइल सिस्टम, आणि ट्रेस होणारी प्रक्रिया। त्याच अटींमध्ये फाइल क्षमता दुर्लक्षित केल्या जातात। ते चार नियम अशा प्रकारच्या जवळपास प्रत्येक अहवालाला व्यापतात।

ती यादी स्पष्ट करते की ls छापतो तो मोड कधीही संपूर्ण अधिकृतता कथा नसतो। कोणत्या अटीमुळे एखादा विशिष्ट अपयश संदेश तयार झाला हे ती सांगत नाही, आणि ॲप्लिकेशन त्याच शब्दांत एखाद्या असंबद्ध क्रेडेन्शियल क्रियेची तक्रार करत असू शकते। निष्कर्ष काढण्यापूर्वी नेमका प्रोग्राम, लाँचर आणि त्रुटींचा क्रम नोंदवा।

समर्थित पॅकेजने इंस्टॉल केलेली कार्यान्वित फाइल, तिचा मालक, तिचा खरा मार्ग आणि ती ठेवणाऱ्या फाइल सिस्टमचे धोरण ओळखा। डाउनलोड फोल्डरमध्ये असलेली प्रत इंस्टॉल केलेला सहाय्यक नाही, तिचा मोड काहीही सांगो।

याबद्दल काय करू नये

तपास न केलेल्या बायनरीवर set-user-ID बिट लावणे आणि निर्बंध नाहीसा होईपर्यंत ती इकडून तिकडे हलवत राहणे ही दुरुस्ती नाही। ते तुम्हाला न समजलेल्या धोरणाच्या जागी तुम्ही ऑडिट करू शकत नाही असे विशेषाधिकार ठेवते, आणि सहाय्यकावर तोच उपाय केल्यास तो ज्ञात एस्कलेशन मार्ग आहे। माउंटवरून nosuid काढणे त्याहून वाईट आहे, कारण ते त्या फाइल सिस्टमवरील प्रत्येक प्रोग्रामवर परिणाम करते, फक्त एकावर नाही।

समर्थित मार्ग म्हणजे प्रशासकाने केलेले क्लायंटचे दस्तऐवजीकृत सहाय्यक किंवा सेवा इंस्टॉलेशन, जे बायनरी तेथे ठेवते जिथे धोरण तिची अपेक्षा करते। यामुळे दोनऐवजी एकच विशेषाधिकार यंत्रणा राहते।

खरा लॉन्च संदर्भ तपासा

अधिकृत दुरुस्तीनंतर सहाय्यक root शेलमधून नव्हे, तर उत्पादन जसा चालवतो तसाच चालवा। root म्हणून मिळालेले यश सामान्य वापरकर्त्याच्या मार्गाबद्दल काहीही सिद्ध करत नाही, आणि या दोन संदर्भांतील फरक हाच अपयशाचा खरा विषय होता।

मग सहाय्यक ज्या नेटवर्क क्रियेसाठी आहे ती तपासा। सुरू होतो पण इंटरफेस कॉन्फिगर करू शकत नाही असा सहाय्यक समस्या एक टप्पा पुढे सरकवतो, सोडवत नाही।

findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helper

माउंट पर्याय आणि सहाय्यकाची मालकी एकाच नोंदीत लिहा। नाहीतर हे डीबग करणारी पुढची व्यक्ती एन्क्रिप्शनचा सिद्धांत पुन्हा सुरुवातीपासून दोहराईल।