OpenVPN के user ड्रॉप पर systemd हार्डनिंग को न थपें

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

दो मॉडल, बदलाव का एक मालिक

पहला मॉडल डेमन का है। समुदाय OpenVPN के user और group विकल्प सुरंग और कुंजियाँ तैयार होने के बाद पहचान बदलते हैं, और persist-key के साथ persist-tun उन संसाधनों को बाद में भी उपयोगी रखते हैं।

दूसरा मॉडल सेवा प्रबंधक का है। systemd की User= या Group= सेटिंग तय करती है कि प्रक्रिया किस पहचान के अधीन शुरू हो, और क्षमता-निर्देश तय करते हैं कि वह क्या रख सकती है। मॉडलों में चुनाव सुरक्षा प्रश्न बनने से पहले पैकेजिंग का प्रश्न है, और पैकेज अनुरक्षक पहले ही इसका उत्तर दे चुका है। आपका काम तीसरा विकल्प गढ़ना नहीं, वही उत्तर खोजना है।

दोनों वैध हैं। गलती इन्हें एक ही डिज़ाइन की परतें मानना है, क्योंकि दूसरा मॉडल पहले की पहचान-बदली को ऐसा संचालन बना सकता है जिसकी अनुमति प्रक्रिया को अब नहीं है।

तय करें कि पहचान कहाँ बदलती है

यदि यूनिट पहले से समर्पित खाते के रूप में शुरू होती है, तो डेमन को दूसरा खाता बनने का निर्देश ऐसा setuid संक्रमण माँगता है जो कठोर किए गए सेवा ने कभी नहीं करना था। विफलता शुरू में अनुमति-त्रुटि के रूप में दिखती है, स्पष्ट नीति-संदेश के रूप में नहीं। यह अनुपस्थित क्षमता जैसा पढ़ा जाता है, जिससे लोग पहचान के प्रश्न की ओर नहीं, बल्कि अधिक चौड़े सीमा-समुच्चय की ओर बढ़ते हैं।

कुछ भी संपादित करने से पहले पढ़ें कि स्थापित पैकेज वास्तव में क्या देता है, उसकी drop-in निर्देशिका सहित। कुछ यूनिट जान-बूझकर डेमन का अपना उतरना छोड़ देती हैं क्योंकि प्रबंधक पहले ही उसे संभालता है, और कुछ आरंभ के बाद के बदलाव के लिए उन विकल्पों पर निर्भर हैं। कौन-सा मॉडल विरासत में मिला, यह जाने बिना कोई एक हटाना वही तरीका है जिससे चलती हुई सेवा शुरू होना बंद कर देती है।

चुना गया मॉडल एक पंक्ति में लिखें: प्रबंधक-स्वामित्व या डेमन-स्वामित्व। बाद का हर निर्देश उस वाक्य के अनुरूप होना चाहिए, और मिश्रित यूनिट को समझौता नहीं, बल्कि दोष माना जाना चाहिए।

क्षमताएँ सीमाएँ हैं, अनुदान नहीं

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

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

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

जीवनचक्र में अधिकार का मानचित्रण करें

हर चरण में प्रक्रिया को क्या करना है, सूचीबद्ध करें: आरंभ, स्थिर अवस्था, पुनःप्रमाणीकरण और विमोचन। इंटरफ़ेस बनाना, रूट बदलना, संरक्षित कुंजी पढ़ना और सहायक को बुलाना सब एक ही क्षण या एक ही आवश्यकताओं के अधीन नहीं होते। सूची को क्षमता से क्रमबद्ध करने से पहले चरण से क्रमबद्ध करें।

दृढ़ता विकल्प पुनर्वार्ता के दौरान संसाधन सुरक्षित रखते हैं, और वे वे अनुमतियाँ नहीं देते जो कभी थीं ही नहीं। जिस कुंजी को प्रक्रिया आरंभ में नहीं पढ़ सकती, वह बाद में भी अपठनीय रहेगी, दृढ़ता के फ़्लैग कुछ भी कहें। फ़्लैग वही सुरक्षित रखते हैं जो पहले से काम कर रहा था।

साझा नहीं, समर्पित खाते का उपयोग करें। OpenVPN के विकासकर्ता nobody को सामान्य उदाहरण के रूप में उपयोग करने की आदत के विरुद्ध चेताते हैं, क्योंकि होस्ट पर अन्य सेवाएँ पहले से उस खाते के रूप में चल सकती हैं और जो अलगाव आप सोचते हैं वह वहाँ नहीं है।

स्थानीय भार बदलने वाली सुविधाएँ, जैसे डेटा-चैनल ऑफ़लोड या अलग तरह से लिंक होने वाला बिल्ड, यह बदल सकती हैं कि कौन-से संचालन चाहिए। पैकेज बदलने पर मानचित्र की समीक्षा करें, केवल तब नहीं जब कुछ टूटे।

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

परिनियोजन रिकॉर्ड में प्रबंधक, आरंभिक पहचान, इच्छित स्थिर पहचान और हर अनुदान को उसके लिए आवश्यक संचालन के साथ नामित करना चाहिए। वही रिकॉर्ड अगले बदलाव को प्रयोग नहीं, समीक्षायोग्य बनाता है।

संपादन के दौरान कंसोल पहुँच उपलब्ध रखें, क्योंकि आरंभ में विफल होने वाली यूनिट को दूर से ठीक करना कठिन है। बदलाव को पूर्ण कहने से पहले पुनःआरंभ और पूर्ण रीबूट जाँचें। पुनःआरंभ सह लेने वाली यूनिट नेटवर्क ऊपर होने से पहले भी विफल हो सकती है।

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