OpenVPN वर chroot अयशस्वी: AppArmor नियम की क्षमता?

डेमॉन chroot अयशस्वी नोंदवतो आणि प्रोफाइल आधीच उदार दिसते, त्यामुळे मोहक उपाय म्हणजे मार्ग नियम रुंद करून पुन्हा सुरू करणे. यामुळे सहसा काहीही बदलत नाही, कारण chroot अशा विशेषाधिकाराने नियंत्रित होतो जो प्रोफाइल कधीही देऊ शकले नाही. कोणत्या स्तराला स्पर्श करायचा हे ठरवण्यासाठी तीन स्वस्त तपासण्या लागतात: प्रक्रियेला काय ठेवण्याची परवानगी आहे, धोरण काय परवानगी देते, आणि त्या दोन्ही महत्त्वाच्या होण्यापूर्वी लाँचरने काय काढून टाकले.

दोन वेगळे दरवाजे, आणि फक्त एक AppArmor चा

chroot ला प्रक्रिया ज्या वापरकर्ता नामस्थानात चालते तिथे CAP_SYS_CHROOT आवश्यक आहे. हा नेहमीचा Linux विशेषाधिकार आहे, जो कर्नल कॉल मार्गांसोबत काही करण्यापूर्वी तपासतो. वेगळे, अंमलबजावणी करणारे AppArmor प्रोफाइल प्रक्रियेकडे क्षमता असूनही ती नाकारू शकते, कारण अनिवार्य धोरण क्रेडेन्शियल्सच्या जागी नाही तर त्यांच्यासोबत पाहिले जाते. हा फरक व्यवहारात महत्त्वाचा आहे: दोन्ही स्तर वेगळ्या फाइलांमध्ये राहतात आणि सहसा वेगळे लोक त्यांची देखभाल करतात.

ती दोन्ही दरवाजे एकाच errno ने अयशस्वी होतात. दोन्ही EPERM निर्माण करतात, आणि दोन्ही डेमॉन लॉगमध्ये सामान्य परवानगीची तक्रार म्हणून दिसतात, म्हणूनच प्रोफाइलच्या आशयाचा अंदाज लावणे इतका वेळ वाया घालवते. तुम्ही जोडणार होता तो मार्ग नियम chroot यशस्वी झाल्यानंतरच्या फाइल प्रवेशावर नियंत्रण ठेवतो; त्या क्रियेला मुळीच परवानगी आहे का याच्याशी त्याचा संबंध नाही.

तिसरा दरवाजा दोन्हींच्या वर आहे. जर सेवा व्यवस्थापक किंवा आवरणाने प्रक्रिया तिच्या मर्यादित संचात क्षमतेशिवाय सुरू केली असेल, तर कोणताही AppArmor बदल ती परत आणू शकत नाही, आणि प्रोफाइलमध्ये क्षमता जोडणे हे कर्नल मानणार नाही अशा हेतूची नोंद करते.

धोरण संपादित करण्यापूर्वी विशेषाधिकार स्थिती वाचा

सक्रिय असे तुम्हाला वाटणाऱ्या संरचनेपासून नाही, तर चालू असलेल्या प्रक्रियेपासून सुरुवात करा. स्थिती फाइल पाच क्षमता मास्क आणि no-new-privileges ध्वज दाखवते, आणि ते वेगवेगळ्या प्रश्नांची उत्तरे देतात:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff हा कॉलसाठी महत्त्वाचा संच आहे: CapBnd मध्ये असलेली पण CapEff मध्ये नसलेली क्षमता छताने परवानगी दिलेली आहे आणि सध्या धारण केलेली नाही. बायनरी नेहमीच्या setuid अर्थाने विशेषाधिकारित नसताना CapAmb महत्त्वाची ठरते, कारण पर्यावरणीय क्षमता हा सेवा फाइल क्षमतांशिवाय exec ओलांडून विशेषाधिकार टिकवण्याचा मार्ग आहे. CapInh मध्ये exec ओलांडून वारसा मिळू शकणारे बिट आहेत, पण फक्त तेव्हाच जेव्हा चालवल्या जाणाऱ्या फाइलचा वारसा संच परवानगी देतो, म्हणून तिथले एक बिट एकटे काहीही देत नाही.

मग कोणते प्रोफाइल खरोखर जोडलेले आहे याची खात्री करा. प्रक्रिया तुम्ही अपेक्षा न केलेल्या प्रोफाइल नावाने मर्यादित असू शकते, विशेषतः जेव्हा वितरण आपली युनिट फाइल आणि प्रोफाइल एकत्र पाठवते, आणि /proc/PID/attr/current वाचल्याने ते एका ओळीत ठरते. तुमच्या संपादित फाइलची कर्नल जे प्रोफाइल सांगते त्याच्याशी तुलना करणे म्हणजे कारण दुरुस्त करणे आणि कोणीही लोड न करणारी फाइल संपादित करणे यातील फरक.

ऑडिट ट्रेल तसे सांगत असेल तरच क्षमता नियम जोडा

कर्नल आणि ऑडिट नोंदी नाकारणाऱ्या स्तराचे नाव घेतात. क्रिया capable आणि नाव sys_chroot अशी, ती निर्माण करणाऱ्या प्रोफाइलसह येणारी नकार नोंद शोधा. जर ती नोंद असेल, तर प्रक्रियेकडे क्षमता आधीच होती आणि AppArmor ने नाकारली, आणि लक्ष्यित बदल खऱ्या प्रोफाइलमधील क्षमता नियम आहे:

capability sys_chroot,

तो खरोखर जोडलेल्या प्रोफाइलमध्ये तुकडा म्हणून ठेवा, आणि कीवर्ड असंबंधित ट्युटोरियलमधून नियम कॉपी करण्याऐवजी apparmor.d प्रोफाइल संदर्भाशी तपासा. तो सामायिक include मध्ये टाकल्याने ती फाइल ओढणाऱ्या प्रत्येक मर्यादित कार्यक्रमाला मिळतो, आणि प्रोफाइल complain मोडमध्ये बदलल्याने हे सोडवण्याऐवजी पुढील नकार लपतो. प्रोफाइल नियम धोरणाचा नकार काढतो; तो विशेषाधिकार निर्माण करत नाही, म्हणून प्रभावी संचात कधीही CAP_SYS_CHROOT नसलेली प्रक्रिया नियम असूनही अयशस्वी होईल.

ऑडिट नोंदीत AppArmor नकार अजिबात दिसत नसेल, तर प्रोफाइल संपादन थांबवा. तुम्ही क्रेडेन्शियल्सची समस्या पाहत आहात, आणि उर्वरित काम युनिट फाइल किंवा पालक प्रक्रियेत आहे, धोरण भाषेत नाही.

सेवा व्यवस्थापक आपली स्वतःची छत ठेवतो

systemd प्रत्येक सेवेसाठी क्षमतांचा मर्यादित संच ठरवतो, आणि डीफॉल्टनुसार तो संच अरुंद असतो. तिथे वगळलेले काहीही प्रोफाइल काय म्हणेल याची पर्वा न करता प्रक्रियेला उपलब्ध नसते, म्हणूनच कठोर केलेल्या युनिट्स डेमॉन हाताने सुरू केल्यावर चाललेल्या क्रियेत अयशस्वी होऊ शकतात. संबंधित निर्देश युनिटमध्ये वाचायला सोपे असतात आणि अनुप्रयोग अयशस्वीपणाची तक्रार करतो तेव्हा दुर्लक्षित होणेही सोपे असते. वितरण पॅकेज पुरवत असलेल्या drop-in फाइला हा कोणालाही आठवत नसलेल्या छताचा नेहमीचा स्रोत आहे.

छत उंचावणे आणि क्षमता देणे या दोन बदल आहेत, एक नाही. मर्यादित संचातील नोंद प्रक्रिया क्षमता धारण करू शकते असे सांगते; ती ती प्रभावी संचात जोडत नाही, आणि बाकी सर्व जुळले तरी NoNewPrivs पुढील उन्नयन यशस्वी होण्यास प्रतिबंध करू शकते. क्रियेला जे आवश्यक आहे तेवढेच जोडा, उर्वरित कठोरता टिकवा, आणि एक कॉल पास करण्यासाठी सर्व क्षमता देण्याच्या शॉर्टकटला नकार द्या.

येथे क्रमही महत्त्वाचा आहे. आधी युनिटची छत बदला, CapEff मध्ये आता ते बिट आहे याची खात्री करा, आणि मगच AppArmor अजूनही नाकारतो का ते ठरवा. दोन्ही बदल एकाच वेळी केल्यास अयशस्वीपणा कायम राहिल्यास तुम्ही पुन्हा अंदाजात राहता.

नकार दूर झाल्यावर तुरुंग स्वतः तपासा

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

chroot काय करत नाही हे लक्षात ठेवणेही उपयुक्त आहे. ही मार्गाची सीमा आहे, सँडबॉक्स नाही: विशेषाधिकार टिकवणारी प्रक्रिया त्यातून पळू शकते, म्हणूनच क्षमता सहसा कॉलनंतर सोडली जाते आणि म्हणूनच बंदिस्ती डेमॉनभोवती राहिली पाहिजे. AppArmor प्रोफाइल, क्षमता मर्यादित संच आणि फाइलसिस्टम निर्बंध एकत्र ठेवणे हेच या सरावाचे उद्दिष्ट आहे, सेवा सुरू झाल्यावर काढून टाकायचा उरलेला भाग नाही.

निर्णयाचा नियम छोटा आहे. ऑडिट नोंद AppArmor चे नाव घेत असेल, तर जोडलेल्या प्रोफाइलमध्ये एक क्षमता नियम जोडा. प्रभावी संच रिकामा असेल, तर युनिटची छत आणि विशेषाधिकार सोडण्याचा क्रम दुरुस्त करा. प्रोफाइल तुम्ही संपादित केलेले नसेल, तर संपादन थांबवा आणि खरे शोधा.