VPN बटन प्रशासकका लागि काम गर्छ र अरू सबैका लागि असफल हुन्छ, त्यसैले कसैले sudoers मा एउटा लाइन थप्छ। त्यो लाइन सामान्यतया समाधान गर्नुपर्ने समस्याभन्दा लामो समय बाँच्छ, र बटनलाई चाहिनेभन्दा बढी अधिकार दिन्छ। नीति सम्पादन गर्नुअघि समर्थित जडानको मालिकले यो काम पहिले नै गर्न सक्छ कि भनी जाँच्नुहोस्। तलका तीन सर्तहरूले sudo संलग्न छ कि छैन भन्ने निर्धारण गर्छन्।

सर्त 1: समर्थित मालिकले यो sudo बिना गर्न सक्छ

अधिकांश Linux डेस्कटपमा नेटवर्क म्यानेजर पहिले नै VPN जडानको मालिक हुन्छ, र यसको अधिकृति sudo होइन, polkit मार्फत जान्छ। जडान उठाउन अनुमति पाएको प्रयोगकर्ताले कुनै पनि root नियम बिना आदेश लाइनबाट यो गर्न सक्छ। बटनलाई विशेषाधिकार चाहिन्छ भनी मान्नुअघि म्यानेजरले के अनुमति दिन्छ जाँच्नुहोस्। उत्तर हो भने, sudoers परिवर्तन नभएको समस्या समाधान गर्दै छ।

nmcli connection show
nmcli connection up "Work VPN"

म्यानेजरले अस्वीकार गरेमा कारण पढ्नुहोस्: हराएको polkit नियम, अर्को प्रयोगकर्ताको स्वामित्वको जडान वा प्रयोगकर्ताले पढ्न नसक्ने ठाउँमा राखिएको प्रोफाइल। यीमध्ये प्रत्येकका लागि sudo नियमभन्दा साँघुरो समर्थित उपाय छ। विशेषाधिकार बढाउनु अन्तिम उपाय हो, पहिलो होइन।

सर्त 2: नियमले एउटा कार्यान्वयनयोग्य फाइल र त्यसका तर्कहरू नाम दिन्छ

sudo साँच्चै आवश्यक भएमा, नियमले ठ्याक्कै आदेश र सम्भव भएमा यसले प्रयोग गर्न सक्ने तर्कहरू नाम दिनुपर्छ। प्रयोगकर्तालाई आवरण स्क्रिप्ट चलाउन दिने नियम त्यस स्क्रिप्टको अनुमतिजति मात्र सुरक्षित हुन्छ, किनभने प्रयोगकर्ताले root ले के चलाउने भन्ने सम्पादन गर्न सक्छ। आदेशपछि वाइल्डकार्ड भएको नियम त्यही समस्याको छोटो रूप हो।

sudo -l -U alice
ls -l /usr/local/sbin/vpn-up

आदेश शृंखलाको प्रत्येक मार्ग जाँच्नुहोस्: बाइनरी, यसले बोलाउने स्क्रिप्ट, यसले पढ्ने कन्फिगरेसन फाइल र तिनीहरूबीचको कुनै पनि डाइरेक्टरी। यीमध्ये कुनै पनि प्रयोगकर्ताले लेख्न सक्ने भएमा, सीमित नियम व्यवहारमा असीमित root हो। तर्क पनि महत्त्वपूर्ण छन्, किनभने कन्फिग मार्ग स्वीकार गर्ने आदेशलाई प्रयोगकर्ताले नियन्त्रण गर्ने फाइलतिर फर्काउन सकिन्छ। नियम बटनका लागि होइन, कार्यका लागि लेख्नुहोस्।

आदेशलाई काम गर्न प्रयोगकर्ता-नियन्त्रित फाइल चाहिएमा रोक्नुहोस्। त्यसपछि डिजाइन गलत छ, र कुनै पनि sudoers वाक्यरचनाले यसलाई सुरक्षित बनाउने छैन।

सर्त 3: पूरै नीति पार्स हुन्छ, तपाईंको लाइन मात्र होइन

फाइल लक गर्ने र वाक्यरचना जाँच्ने सम्पादकबाट प्रमाणित गर्नुहोस्, र टुक्रा होइन, जोडिएको नीति प्रमाणित गर्नुहोस्। आफैं पार्स हुने फाइलले पनि समावेशन क्रम तोड्न सक्छ वा व्यवहार बदल्ने गरी नियम दोहोर्याउन सक्छ।visudo पुस्तिका यहाँ प्रयोग गरिएको लकिङ सम्पादक र जाँच-मात्र मोड दुवैको दस्तावेजीकरण गर्छ।

sudo visudo -c
sudo visudo -cf /etc/sudoers.d/vpn-launcher

जाँच असफल हुँदा फाइल र लाइन बताउँछ, र त्यही प्रतिवेदन उपयोगी भाग हो। ज्ञात त्रुटि जबरजस्ती सुरक्षित गर्नुको सट्टा सम्पादकमार्फत इच्छित परिवर्तन सुधार्नुहोस्, किनभने भाँचिएको नीतिले सबै प्रशासकलाई एकैपटक बाहिर राख्न सक्छ। समावेशन डाइरेक्टरीका फाइललाई पनि पुस्तिकाले माग गर्ने स्वामित्व र मोड चाहिन्छ, नभए ती बेवास्ता वा अस्वीकार गरिनेछन्। वाक्यरचना पहिलो ढोका मात्र हो: त्यो पार भएपछि नियम फेरि पढ्नुहोस् र यसले वास्तवमा के अनुमति दिन्छ सोध्नुहोस्।

परिवर्तन कार्यान्वयन गर्ने एकमात्र उपाय वाक्यरचना जाँच बन्द गर्नु भएमा रोक्नुहोस्। त्यो नीति होइन, त्यो रिबुट पर्खिरहेको अवरोध हो।

पुनःप्राप्ति: अझै काम गर्ने सत्र राख्नुहोस्

सुरक्षित गर्नुअघि अधिकृत प्रशासनिक सत्र पहिले नै खुला छ र मेसिनमा दोस्रो मार्ग छ भनी सुनिश्चित गर्नुहोस्। sudoers गल्तीले त्यसलाई सुधार्ने क्षमता तपाईंबाट खोस्न सक्छ, र डेस्कटपको बटन त्यो जोखिमको योग्य छैन। sudo पहिले नै भाँचिएको भए आफैं बनाउनुको सट्टा प्रणालीको दस्तावेजीकृत पुनःप्राप्ति मार्ग प्रयोग गर्नुहोस्।

sudo -n true
id

pkexec जस्ता विकल्प आफ्नै स्थापना र नीतिमा निर्भर हुन्छन्, त्यसैले ती ग्यारेन्टी दोस्रो root प्रम्प्ट होइनन्। स्थानीय अधिकृतिलाई VPN गोप्य कुरा उपलब्ध गराउनेबाट पनि अलग राख्नुहोस्: sudo नियमले अनुपस्थित गोप्य एजेन्ट खोल्न सक्दैन, र गेटवेको MFA पूरा गर्दैन। सुधारपछि सामान्य खाताले मात्र इच्छित कार्य गरेको परीक्षण गर्नुहोस्, त्यसपछि म्यानेजरका सामान्य नियन्त्रण प्रयोग गर्नुहोस्।

कुन सर्तले sudo लाई न्यायोचित ठहर्यायो, नियमले के नाम दिन्छ, पूरै नीति पार्स हुन्छ, र नभए तपाईं कसरी पुनःप्राप्त गर्नुहुन्थ्यो भनी भन्न सक्ने भएपछि निर्णय टुंगिन्छ। प्रशासनिक पहुँच गुमाउने विशेषाधिकारप्राप्त लन्चर खराब सौदा हो, र सामान्यतया यो टार्न सकिन्छ।

सम्बन्धित लेखहरू