OpenVPN च्या user ड्रॉपवर systemd हार्डनिंग थर करू नका
दोन किमान-विशेषाधिकार पाककृती एकत्र केल्याने अधिक कठोर एक होत नाही. ओळख बदलणे कोण करते ते निवडा, नंतर संपूर्ण जीवनचक्रात अधिकाराचे मॅपिंग करा.
एकत्र चिकटवलेल्या दोन किमान-विशेषाधिकार पाककृती अधिक कठोर तैनाती देत नाहीत. एक मॉडेल डेमनला विशेषाधिकारांसह सुरू होऊन आरंभानंतर विशेषाधिकार नसलेल्या खात्यात उतरण्याची परवानगी देते; दुसरे सेवा व्यवस्थापकाला पहिल्या सूचनेपासूनच मर्यादित ओळखीखाली ते चालवू देते. प्रत्येक स्वतंत्रपणे कार्य करते, आणि दोघांची जोडणी अनेकदा दोन्ही कामांपैकी एकही स्वच्छ करू न शकणारी सेवा तयार करते. उर्वरित भाग निर्णय क्रमाने घेतो.
दोन मॉडेल, बदलाचा एक मालक
पहिले मॉडेल डेमनचे आहे. समुदाय OpenVPN चे user आणि group पर्याय बोगदा आणि किल्ल्या तयार झाल्यानंतर ओळख बदलतात, आणि persist-key सह persist-tun ती संसाधने नंतरही वापरण्यायोग्य ठेवतात.
दुसरे मॉडेल सेवा व्यवस्थापकाचे आहे. systemd ची User= किंवा Group= सेटिंग प्रक्रिया कोणत्या ओळखीखाली सुरू होते हे ठरवते, आणि क्षमता-निर्देश काय ठेवू शकते हे ठरवतात. मॉडेलांमधील निवड सुरक्षा प्रश्न होण्यापूर्वीच पॅकेजिंगचा प्रश्न आहे, आणि पॅकेज देखभालकर्त्याने त्याचे उत्तर आधीच दिले आहे. तुमचे काम तिसरा पर्याय शोधणे नाही, ते उत्तर शोधणे आहे.
दोन्ही वैध आहेत. चूक ही आहे की त्यांना एकाच रचनेचे स्तर मानणे, कारण दुसरे मॉडेल पहिल्याच्या ओळख-बदलाला प्रक्रियेला आता परवानगी नसलेली क्रिया बनवू शकते.
ओळख कुठे बदलते ते ठरवा
जर युनिट आधीच समर्पित खाते म्हणून सुरू होत असेल, तर डेमनला दुसरे खाते होण्याची सूचना अशा setuid संक्रमणाची मागणी करते जे कठोर केलेल्या सेवेने कधीही करू नये. अयशस्वीता सुरुवातीला परवानगी-त्रुटी म्हणून दिसते, स्पष्ट धोरण-संदेश म्हणून नाही. हे गहाळ क्षमतेसारखे वाचले जाते, ज्यामुळे लोक ओळखीच्या प्रश्नाकडे नाही तर अधिक रुंद मर्यादा-संचाकडे जातात.
काहीही संपादित करण्यापूर्वी स्थापित पॅकेज प्रत्यक्षात काय देते ते वाचा, त्याची drop-in निर्देशिका धरून. काही युनिट डेमनचे स्वतःचे उतरण जाणीवपूर्वक वगळतात कारण व्यवस्थापक आधीच ते सांभाळतो, आणि काही आरंभानंतरच्या बदलासाठी त्या पर्यायांवर अवलंबून असतात. कोणते मॉडेल वारसा मिळाले हे न जाणता यापैकी एक काढून टाकणे हा कार्यरत सेवा सुरू होणे थांबवण्याचा मार्ग आहे.
निवडलेले मॉडेल एका ओळीत लिहा: व्यवस्थापक-मालकीचे की डेमन-मालकीचे. पुढील प्रत्येक निर्देश त्या वाक्याशी सुसंगत असावा, आणि मिश्र युनिटला तडजोड नाही तर दोष मानले पाहिजे.
क्षमता मर्यादा आहेत, अनुदान नाही
क्षमता मर्यादा-संच सांगतो की प्रक्रिया जास्तीत जास्त काय ठेवू शकते. ती एक छत आहे, आणि तिथे क्षमता सूचीबद्ध केल्याने स्वतःच काहीही मिळत नाही, म्हणून उदार मर्यादा-संच असलेले युनिटही बोगदा तयार करण्यात अपयशी होऊ शकते.
क्षमतेला सेवेच्या आसपासच्या संचात प्रत्यक्षात ठेवते ते AmbientCapabilities=. systemd अंमलबजावणी संदर्भ दोन्ही निर्देश वेगळे नोंदवतो, आणि हाच फरक ऑनलाइन क्षमतेविषयीच्या गोंधळाच्या बहुतेक सल्ल्यांचे स्पष्टीकरण देतो.
क्षमता तेव्हाच जोडा जेव्हा अपयशी होणारी क्रिया ती ओळखते. अधिक रुंद मर्यादा-संच खरे कारण लपवतो आणि सेवा रचनेच्या हेतूपेक्षा जास्त विशेषाधिकारात ठेवतो. यामुळे युनिटचा आढावा घेणेही कठीण होते, कारण छत आता कामाचे वर्णन करत नाही. खरा दोष दुरुस्त झाल्यावर अतिरिक्त क्षमता काढून टाका.
जीवनचक्रभर अधिकाराचे मॅपिंग करा
प्रत्येक टप्प्यावर प्रक्रियेने काय करावे ते सूचीबद्ध करा: सुरुवात, स्थिर स्थिती, पुनर्प्रमाणीकरण आणि विघटन. इंटरफेस तयार करणे, मार्ग बदलणे, संरक्षित किल्ली वाचणे आणि सहाय्यकाला बोलावणे हे सर्व एकाच क्षणी किंवा एकाच गरजांखाली घडत नाही. यादी क्षमतेनुसार लावण्यापूर्वी टप्प्यानुसार लावा.
टिकाऊपणाचे पर्याय पुनर्वाटाघाटीतून संसाधने जपतात, आणि कधीही नसलेल्या परवानग्या देत नाहीत. सुरुवातीला प्रक्रिया वाचू न शकणारी किल्ली नंतरही न वाचता येणारी राहते, टिकाऊपणाचे झेंडे काहीही म्हणोत. झेंडे आधीच चाललेले जपतात.
सामायिक नाही, समर्पित खाते वापरा. OpenVPN चे विकासक nobody ला सामान्य उदाहरण म्हणून वापरण्याच्या सवयीविरुद्ध इशारा देतात, कारण यजमानावरील इतर सेवा आधीच त्या खात्याखाली चालत असू शकतात आणि तुम्हाला वाटणारे अलगीकरण तिथे नाही.
स्थानिक भार बदलणारी वैशिष्ट्ये, जसे डेटा-चॅनेल ऑफलोड किंवा वेगळ्या प्रकारे लिंक होणारे बिल्ड, कोणत्या क्रिया आवश्यक आहेत ते बदलू शकतात. पॅकेज बदलल्यावर नकाशा पुन्हा पाहा, केवळ काही तुटल्यावर नाही.
योजना लिहून ठेवा आणि पुनर्प्राप्ती प्रवेश ठेवा
तैनाती नोंदीत व्यवस्थापक, सुरुवातीची ओळख, इच्छित स्थिर ओळख आणि प्रत्येक अनुदान त्यास आवश्यक असलेल्या क्रियेसह नाव दिले पाहिजे. तीच नोंद पुढील बदलाला प्रयोग नाही तर आढावयोग्य बनवते.
संपादन करताना कन्सोल प्रवेश उपलब्ध ठेवा, कारण सुरुवातीला अपयशी होणारे युनिट दूरून दुरुस्त करणे कठीण आहे. बदल पूर्ण म्हणण्यापूर्वी पुन्हा सुरू करणे आणि पूर्ण रीबूट तपासा. पुन्हा सुरू होणे टिकून राहणारे युनिट नेटवर्क वर येण्यापूर्वीही अपयशी होऊ शकते.
यश म्हणजे समजलेले किमान-अधिकाराचे जीवनचक्र, अशी प्रक्रिया नाही जी योगायोगाने बिगर-root नावाखाली चालत असेल.