विशेषाधिकार घटाएपछि: कुन OpenVPN फाइलहरू अझै काम गर्छन्?
घटाउनुअघि खोलिएका डिस्क्रिप्टरहरू काम गरिरहन्छन्; पछि फेरि खोलिने बाटाहरू गर्दैनन्। तपाईंको सेटअपले तीन रनटाइम फाइलमध्ये कुन फेरि खोल्नुपर्ने हो ठहर गर्नुहोस्।
लामो अपटाइमले त्यस क्षणमा डेमनसँग भएका विशेषाधिकारसहित सुरुवात सफल भएको मात्र प्रमाणित गर्छ। यहाँ महत्त्वपूर्ण असफलताहरू पछि आउँछन्: नयाँ क्लाइन्ट जोडिन्छ, रद्दीकरण सूची बदलिन्छ, सहायक स्क्रिप्टले फाइल लेख्नुपर्छ। यीमध्ये हरेक विशेषाधिकार नभएको खाताले गर्ने नयाँ खोलाइ हो, आफ्नै अनुमति प्रश्न र आफ्नै त्रुटि सन्देशसहित। तीन निर्णयले काम गरिरहने कन्फिगरेसनलाई अर्को घटनामा असफल हुनेबाट छुट्याउँछन्।
चाँडो लोड भएको र पछि खोलिने कुरा छुट्याउनुहोस्
डिस्क्रिप्टर भनेको खुला फाइल वर्णनमाथिको ह्यान्डल हो, र पहुँच मोड त्यो वर्णन बनाइँदा तय भएको थियो। पछि प्रक्रियाको प्रयोगकर्ता बदल्दा ह्यान्डल बन्द हुँदैन, त्यसैले root का रूपमा पढिएको कुञ्जी फाइल घटाएपछि पनि काम गर्छ। मोड पनि बदलिँदैन: पढ्नका लागि खोलिएको ह्यान्डल लेख्नयोग्य हुँदैन, र लेख्नयोग्य ह्यान्डल खाताले बाटोमा आफ्ना अधिकार गुमाएको कारणले मात्र फिर्ता लिइँदैन। यी दुई तथ्यले यी प्रतिवेदनमा देखिने अधिकांश अचम्मको व्यवहार व्याख्या गर्छन्।
अर्को आधा भाग स्मृति हो। डेमनले प्रमाणपत्र विश्लेषण गर्न, विश्लेषित सामग्री राख्न र फाइल बन्द गर्न सक्छ; प्रयोगमा रहने कुरा डाटा हो, खुला फाइल होइन। त्यसैले चलिरहेको ट्राफिकले डिस्क्रिप्टर खुला छ वा बाटोको नाम पुग्न सकिन्छ भनी प्रमाणित गर्दैन। यसले वर्तमान सत्रका लागि आवश्यक सामग्री पहिले नै प्राप्त भएको मात्र प्रमाणित गर्छ।
पछिको खोलाइ अर्को कारोबार हो। यो वर्तमान प्रमाणहरू, वर्तमान सुरक्षा सन्दर्भ र वर्तमान माउन्ट दृश्यअन्तर्गत चल्छ, त्यसैले सुरुवातमा पढ्नयोग्य बाटो अर्को जडानमा अस्वीकार हुन सक्छ। घुमाइले एउटा जाल थप्छ: उही बाटो नाममाथि नयाँ फाइल लेख्दा विद्यमान डिस्क्रिप्टर पुरानो वस्तुमा जोडिएको रहन्छ, त्यसैले पुनः लोड सफल देखिन सक्छ जबकि डेमन अझै अघिल्लो सामग्री प्रयोग गरिरहेको हुन्छ। घुमाइ लागू भयो भनी विश्वास गर्नुअघि प्रक्रियासँग भएको inode लाई डिस्कमा भएकोसँग तुलना गर्नुहोस्।
तीन रनटाइम पढाइ र प्रत्येक कहिले हुन्छ भनी नाम दिनुहोस्
तीन स्रोत सामान्यतया सुरुवातको धेरै पछि खोलिन्छन्, र ती फरक फरक क्षणमा असफल हुन्छन्। निश्चित क्लाइन्टको कन्फिगरेसन फाइल त्यो क्लाइन्ट जोडिँदा पढिन्छ, त्यसैले अरू चलिरहँदा एक प्रयोगकर्ताका लागि बिग्रन सक्छ। रद्दीकरण डाटा सहकर्मी प्रमाणीकरणका बेला र फाइल बदलिँदा फेरि हेरिन्छ। अस्थायी डाइरेक्टरीमा स्क्रिप्ट वा प्लगइनले केही लेख्दा मात्र हात लगाइन्छ।
तीनमध्ये कुनै पनि सुरुवाती बाटोको होइन, त्यसैले हप्तौंसम्म स्वस्थ रहेको सर्भर अर्को जडानमा असफल हुन सक्छ। श्रेणीले सुधारको मालिक पनि नाम दिन्छ: पहिला दुई डेमन खाताअन्तर्गत कन्फिगरेसनमा पढ्ने अनुमति हुन्, र तेस्रो साँघुरो उद्देश्यको लेख्नयोग्य स्थान हो।
| Path reopened later | What triggers the open | First sign when it fails |
|---|---|---|
| Client configuration file | A connection for that client identity | One client rejected while others connect |
| Revocation data | Peer authentication, including after replacement | Revoked and valid peers both refused |
| Script or plugin temporary directory | A helper needs to create a file | The helper exits with a path error |
persist-key धेरैले ठानेभन्दा साँघुरो प्रश्नको उत्तर दिन्छ। यसले कागजात गरिएका SIGUSR1 र ping-restart रिसेटभरि कुञ्जी फाइल खुला राख्छ, र CCD फाइल, रद्दीकरण डाटा, सहायक एक्जिक्युटेबल वा प्रक्रियाको पूर्ण पुनःसुरुवातका लागि केही गर्दैन। ती अझै आफ्नै खोलाइ बाटोमा हिँड्छन्, त्यस बेला चलिरहेको जुनसुकै खाताअन्तर्गत।
खाता र यसको वास्तविक दृश्य पुष्टि गर्नुहोस्
unit फाइलमाथि भर पर्नुको सट्टा चलिरहेको डेमनलाई कुन खाता प्रयोग गरिरहेको छ सोध्नुहोस्, त्यसपछि उत्तरलाई unit ले तय गरेकोसँग तुलना गर्नुहोस्। असमझदारी पहिले समाधान गर्नुपर्ने कुरा हो, किनकि पछिको हरेक अनुमति जाँच प्रक्रिया वास्तवमा जो छ त्यसैका रूपमा चल्छ। त्यसपछि बाटोलाई एक एक घटकका रूपमा हिँड्नुहोस्; पार गर्ने क्षमता हरेक तहमा मूल्याङ्कन हुन्छ, त्यसैले पार गर्न नसकिने डाइरेक्टरीभित्रको पढ्नयोग्य फाइल पनि अपठनीय रहन्छ। अन्तिम फाइल मोड पहिलो होइन, अन्तिम प्रश्न हो।
नेमस्पेस र सेवा स्यान्डबक्सले स्वामित्व र मोड बिटले वर्णन नगर्ने सीमा थप्छन्। तपाईंको शेलमा देखिने बाटो chroot, माउन्ट नेमस्पेस वा घरका डाइरेक्टरी लुकाउने unitभित्र अनुपस्थित वा पढ्ने मात्र हुन सक्छ। सुरक्षा मोड्युलले अर्को तह थप्छ, त्यसैले पढ्नयोग्य देखिने फाइल पनि खोल्दा अस्वीकार हुन सक्छ।
ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/aliceप्रशासकको शेलमा सफल पढाइले ती संयुक्त सर्तमध्ये एक पनि जाँच्दैन। जाँच डेमन खाताका रूपमा, उही नेमस्पेस र स्यान्डबक्ससहित चलाउनुहोस्, वा नतिजाले सर्भर होइन तपाईंको शेल वर्णन गर्छ भनी स्वीकार गर्नुहोस्। तेस्रो आदेश त्यो परीक्षणको सस्तो संस्करण हो: यसले हरेक घटकको मोड छाप्छ र डेमन खाताले पार गर्न नसक्ने पहिलो घटकमा असफल हुन्छ।
रनटाइम लेखाइलाई आफ्नै डाइरेक्टरी दिनुहोस्
पढाइ सूचीको आधा मात्र हो। सहायक स्क्रिप्टले स्थिति फाइल बनाउनुपर्ने हुन सक्छ, प्लगइनले आफ्नो कन्फिगरेसनको छेउमा अवस्था लेख्नुपर्ने हुन सक्छ, र ती लेखाइहरू कन्फिगरेसन रूख लेख्नयोग्य बनाएर ढाकिँदैनन्। निश्चित डाइरेक्टरीलाई त्यसको कार्यले चाहिने लेख्ने अनुमति दिनुहोस्, तपाईंले व्याख्या गर्न सक्ने मालिक र मोडसहित। पढिने मात्र सबै कुराका लागि पढ्ने-मात्र पहुँचलाई प्राथमिकता दिनुहोस्।
निजी कुञ्जीका अनुमति नीति फाइलबाट अलग राख्नुहोस्। रिसेटपछि फेरि पढ्नुपर्ने कुञ्जीको आवश्यकता हरेक जडानमा पढिने क्लाइन्ट फाइलभन्दा फरक हुन्छ, र दुवैका लागि एउटै उदार मोडले समस्याले मागेभन्दा बढी पहुँच दिन्छ। साँघुरो स्वामित्वको समर्पित डेमन खाता फराकिलो समूहभन्दा जाँच्न सजिलो हुन्छ। कुञ्जीले रिसेट सहनुपर्दा, persist-key डाइरेक्टरी फराकिलो बनाउनुको सट्टा पुनःपढाइ हटाउँछ।
तपाईंले पुनरुत्पादन गर्न सक्ने घटनाबाट निर्णय गर्नुहोस्
जीवित सुरुङले कोडभित्रको एउटा मात्र बाटो प्रमाणित गर्छ। फाइल चाहिने घटना नै तपाईंलाई महत्त्वपूर्ण खोलाइ ढाक्ने एक मात्र परीक्षण हो, त्यो नयाँ क्लाइन्ट जडान होस्, बदलिएको रद्दीकरण फाइल होस्, अनुमति दिइएको नरम रिसेट होस् वा योजना गरिएको पुनःसुरुवात होस्। घटना छान्नुहोस्, चलाउनुहोस्, र अन्तिम होइन पहिलो त्रुटि राख्नुहोस्।
नरम रिसेटका लागि एउटा सिग्नल र unit को लगले कुञ्जी फेरि पढियो कि भनेर देखाउँछ। सिग्नल पठाउनुहोस्, त्यसपछि unit ले लेखेका अन्तिम हरफहरू पढ्नुहोस्:
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pagerविशेषाधिकार घटेको मात्र कारणले सम्झौता भएको डेमनले अब फाइल बदल्न सक्दैन भनी निष्कर्ष निकाल्नु हुँदैन। यसले अझै के गर्न सक्छ भन्ने बाँकी प्रमाण, यसको क्षमता, यसले लेख्न सक्ने डाइरेक्टरी र अझै राखेको कुनै पनि लेख्नयोग्य डिस्क्रिप्टरमा निर्भर गर्छ। विशेषाधिकार घटाउँदा अधिकार साँघुरो हुन्छ, र रनटाइम खोलाइको सूचीले कति भन्ने देखाउँछ। त्यो सीमा कन्फिगरेसनको छेउमा लेख्नुहोस् ताकि अर्को व्यक्तिले फेरि पत्ता लगाउनु नपरोस्।