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 को नाम लिन्छ भने जोडिएको प्रोफाइलमा एउटा क्षमता नियम थप्नुहोस्। यदि प्रभावकारी समूह खाली छ भने युनिटको छत र विशेषाधिकार छोड्ने क्रम सुधार्नुहोस्। यदि प्रोफाइल तपाईंले सम्पादन गरेको होइन भने सम्पादन रोकेर साँच्चो खोज्नुहोस्।