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

माउंट विकल्प और सहायक का स्वामित्व एक ही नोट में दर्ज करें। वरना इसे डीबग करने वाला अगला व्यक्ति एन्क्रिप्शन सिद्धांत को फिर से शुरू से दोहराएगा।