OpenVPN को user ड्रपमा systemd हार्डनिङ थुपार्नु हुँदैन

सँगै टाँसिएका दुई न्यूनतम-विशेषाधिकार रेसिपीले अझ कडा परिनियोजन दिँदैनन्। एउटा मोडेलले डेमनलाई विशेषाधिकारसहित सुरु भएर आरम्भपछि अविशेषाधिकृत खातामा झर्न दिन्छ; अर्कोले सेवा व्यवस्थापकलाई पहिलो निर्देशनदेखि नै सीमित पहिचानमा चलाउन दिन्छ। प्रत्येक अलगै काम गर्छ, र दुवैको संयोजनले प्रायः दुई काममध्ये एउटै पनि सफा गर्न नसक्ने सेवा बनाउँछ। बाँकी लेखले निर्णय क्रमैसँग लिन्छ।

दुई मोडेल, परिवर्तनको एउटै मालिक

पहिलो मोडेल डेमनको हो। समुदाय OpenVPN का user र group विकल्पहरू सुरुङ र कुञ्जीहरू तयार भएपछि पहिचान बदल्छन्, र persist-key सँगै persist-tun ती स्रोतहरूलाई पछि पनि उपयोगी राख्छन्।

दोस्रो मोडेल सेवा व्यवस्थापकको हो। systemd को User= वा Group= सेटिङले प्रक्रिया कुन पहिचानमा सुरु हुन्छ भनी निर्धारण गर्छ, र क्षमता-निर्देशनहरूले के राख्न सक्छ भनी निर्धारण गर्छन्। मोडेलबीचको छनोट सुरक्षा प्रश्न बन्नुअघि प्याकेजिङको प्रश्न हो, र प्याकेज हेरचाहकर्ताले यसको उत्तर पहिले नै दिइसकेका छन्। तपाईंको काम तेस्रो विकल्प आविष्कार गर्नु नभई त्यही उत्तर खोज्नु हो।

दुवै वैध छन्। गल्ती भनेको तिनलाई एउटै डिजाइनका तहका रूपमा लिनु हो, किनकि दोस्रो मोडेलले पहिलोको पहिचान-परिवर्तनलाई प्रक्रियालाई अब अनुमति नभएको कार्य बनाउन सक्छ।

पहिचान कहाँ बदलिन्छ निर्धारण गर्नुहोस्

यदि युनिट पहिले नै समर्पित खाताको रूपमा सुरु हुन्छ भने, डेमनलाई अर्को खाता बन्न दिने निर्देशनले कडा गरिएको सेवाले कहिल्यै गर्नु नपर्ने setuid संक्रमण माग्छ। असफलता सुरुमा अनुमति-त्रुटिको रूपमा देखिन्छ, स्पष्ट नीति-सन्देशको रूपमा होइन। यो हराएको क्षमताजस्तो पढिन्छ, जसले मानिसहरूलाई पहिचानको प्रश्नतर्फ नभई अझ फराकिलो सीमा-समूहतर्फ धकेल्छ।

केही सम्पादन गर्नुअघि स्थापित प्याकेजले वास्तवमा के दिन्छ पढ्नुहोस्, त्यसको drop-in डाइरेक्टरीसमेत। केही युनिटले डेमनको आफ्नै अवतरण जानाजान छोड्छन् किनकि व्यवस्थापकले पहिले नै त्यसको हेरचाह गर्छ, र केहीले आरम्भपछिको परिवर्तनका लागि ती विकल्पहरूमा भर पर्छन्। कुन मोडेल उत्तराधिकारमा पाएको हो भन्ने नजानी एउटा हटाउनु नै चलिरहेको सेवा सुरु हुन छोड्ने बाटो हो।

छानिएको मोडेल एक हरफमा लेख्नुहोस्: व्यवस्थापक-स्वामित्व वा डेमन-स्वामित्व। पछिको हरेक निर्देशन त्यो वाक्यसँग मिल्नुपर्छ, र मिश्रित युनिटलाई सम्झौता नभई त्रुटि मान्नुपर्छ।

क्षमताहरू सीमा हुन्, अनुदान होइनन्

क्षमता सीमा-समूहले प्रक्रियाले बढीमा के राख्न सक्छ भनी बताउँछ। यो एउटा छाना हो, र त्यहाँ क्षमता सूचीबद्ध गर्दा आफैँमा केही दिँदैन, त्यसैले उदार सीमा-समूह भएको युनिटले पनि सुरुङ बनाउन असफल हुन सक्छ।

क्षमतालाई सेवाको वरपरको समूहमा वास्तवमा राख्ने कुरा AmbientCapabilities= हो। systemd कार्यान्वयन सन्दर्भ ले दुवै निर्देशन अलगअलग अभिलेख गर्छ, र यही भिन्नताले अनलाइनका अधिकांश भ्रमित क्षमता-सल्लाहहरू व्याख्या गर्छ।

असफल हुँदै गरेको कार्यले पहिचान गरेपछि मात्र क्षमता थप्नुहोस्। फराकिलो सीमा-समूहले वास्तविक कारण लुकाउँछ र सेवालाई डिजाइनले चाहेभन्दा बढी विशेषाधिकारमा छाड्छ। यसले युनिटको समीक्षा पनि कठिन बनाउँछ, किनकि छानाले अब कामको वर्णन गर्दैन। वास्तविक दोष सुधारिएपछि अतिरिक्त क्षमता हटाउनुहोस्।

जीवनचक्रभरि अधिकारको नक्साङ्कन गर्नुहोस्

प्रत्येक चरणमा प्रक्रियाले के गर्नुपर्छ सूचीबद्ध गर्नुहोस्: सुरुवात, स्थिर अवस्था, पुनःप्रमाणीकरण र विघटन। इन्टरफेस बनाउनु, मार्ग परिवर्तन, संरक्षित कुञ्जी पढ्नु र सहायकलाई बोलाउनु सबै एउटै क्षणमा वा एउटै आवश्यकतामा हुँदैन। सूचीलाई क्षमताअनुसार मिलाउनुअघि चरणअनुसार मिलाउनुहोस्।

दिगोपनका विकल्पहरूले पुनर्वार्तामा स्रोतहरू जोगाउँछन्, र कहिल्यै नभएका अनुमतिहरू दिँदैनन्। सुरुमा प्रक्रियाले पढ्न नसक्ने कुञ्जी पछि पनि नपढिने रहन्छ, दिगोपनका झन्डाहरूले जे भने पनि। झन्डाहरूले पहिले नै चलेको कुरा जोगाउँछन्।

साझा नभई समर्पित खाता प्रयोग गर्नुहोस्। OpenVPN का विकासकर्ताहरूले nobody लाई सामान्य उदाहरणका रूपमा प्रयोग गर्ने बानीविरुद्ध चेताउनी दिन्छन्, किनकि होस्टका अन्य सेवाहरू पहिले नै त्यही खातामा चलिरहेका हुन सक्छन् र तपाईंले ठान्नुभएको पृथकता त्यहाँ छैन।

स्थानीय भार फेर्ने सुविधाहरू, जस्तै डेटा-च्यानल अफलोड वा फरक तरिकाले लिङ्क हुने बिल्ड, कुन कार्यहरू आवश्यक छन् भन्ने सार्न सक्छन्। प्याकेज बदलिएपछि नक्सा फेरि हेर्नुहोस्, केही बिग्रिएपछि मात्र होइन।

योजना लेखेर राख्नुहोस् र पुनःप्राप्ति पहुँच राख्नुहोस्

परिनियोजन अभिलेखले व्यवस्थापक, सुरुवाती पहिचान, लक्षित स्थिर पहिचान र हरेक अनुदानलाई त्यसलाई आवश्यक पर्ने कार्यसँगै नाम दिनुपर्छ। त्यही अभिलेखले अर्को परिवर्तनलाई प्रयोग नभई समीक्षायोग्य बनाउँछ।

सम्पादन गर्दा कन्सोल पहुँच खुला राख्नुहोस्, किनकि सुरुमै असफल हुने युनिट टाढाबाट मर्मत गर्न गाह्रो हुन्छ। परिवर्तन पूरा भन्नुअघि पुनःसुरु र पूर्ण रिबुट परीक्षण गर्नुहोस्। पुनःसुरु सहन सक्ने युनिट पनि सञ्जाल माथि आउनुअघि असफल हुन सक्छ।

सफलता भनेको बुझिएको न्यूनतम-अधिकार जीवनचक्र हो, गैर-root नाममा संयोगवश चलिरहेको प्रक्रिया होइन।