तुमचा VPN आदेश विशेषाधिकारांशिवाय चालतो; सेवा नाही

VPN आदेश तुमच्या वापरकर्त्याप्रमाणे चालतो, पासवर्ड दिसत नाही, आणि बोगदा वर येतो। हा क्रम विशेषाधिकारांशिवाय क्रिया वाटतो, आणि सहसा तो नसतो। नेटवर्कचे बदल वेगळी सेवा करते, आणि मनोरंजक प्रश्न असा आहे की ती सेवा तिने पडताळणी न केलेल्या कॉलरसाठी काय करेल। पासवर्डच्या विनंत्या मोजल्याने त्या सीमेबद्दल काहीही कळत नाही।

इंटरफेस, यंत्रणा आणि तपासणी

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

भूमिका एका बायनरीमध्ये, दोन प्रक्रियांमध्ये, किंवा क्लायंट आणि प्रणाली सेवेत राहू शकतात, आणि वापरकर्त्याला दिसणारा आदेश कोणती हे क्वचितच उघड करतो। ट्रे चिन्ह आणि प्रणाली डेमन एकच अनुप्रयोग वाटू शकतात, पण ते खूप वेगळ्या अधिकाराने चालतात। स्थापनेच्या वेळचा विशेषाधिकार आणि विनंतीच्या वेळचा विशेषाधिकारही वेगळ्या गोष्टी आहेत। root म्हणून चाललेला स्थापक नंतरच्या विनंत्या ऐकणारी सेवा पॅकेज व्यवस्थापक संपल्यानंतर बराच काळ राहू देतो। अधिकार त्या सेवेकडे आहे, तुम्ही टाइप केलेल्या आदेशाकडे नाही।

सोपवणे ही सामान्य रचना आहे

विशेषाधिकार असलेले नेटवर्क काम सेवेकडे सोपवणे ही योग्य स्थापत्यरचना आहे। ती सामान्य अनुप्रयोग विशेषाधिकारांशिवाय ठेवते आणि काळजी लागणाऱ्या क्रिया केंद्रित करते। ही रचना तेव्हाच फायद्याची ठरते जेव्हा सेवा कोण मागतो आणि कशासाठी हेही तपासते। त्या तपासणीशिवाय ते फक्त रुंद दरवाजा आहे।

NetworkManager हे Linux वरील ठोस उदाहरण आहे। त्याचे संरचना मार्गदर्शक डीफॉल्ट सेटअपमध्ये PolicyKit root नसलेल्या विनंत्या कशा अधिकृत करते ते स्पष्ट करते। हे खऱ्या उत्पादनात सोपवलेली अधिकृतता दाखवते। हे प्रत्येक व्यावसायिक क्लायंट NetworkManager वापरतो हे सिद्ध करत नाही, आणि कोणत्याही विशिष्ट विक्रेत्याचा सॉकेट मार्ग किंवा धोरण वर्णन करत नाही।

नमुना म्हणजे मागे धोरण असलेले सोपवणे। उदाहरण त्या नमुन्याची एक अंमलबजावणी आहे, सार्वत्रिक नाही।

सीमा वाचा, विनंती नाही

सेवा, तिच्या संरचनेचा मालक आणि समोरील भाग वापरतो तो स्थानिक इंटरफेस शोधा। मग कोणते वापरकर्ते कोणत्या क्रिया मागू शकतात ते विचारा। एक साठवलेले प्रोफाइल वर-खाली करणे ही ऑपरेटरने कधीही तपासली नसलेली संरचना लोड करण्याची तीच परवानगी नाही। फरक हाच संपूर्ण सुरक्षा प्रश्न आहे।

सेवा व्यवस्थापक आणि क्लायंटच्या स्वतःच्या परवानग्यांविषयीच्या दृष्टिकोनापासून सुरुवात करा। खालील आदेश डेमन चालू आहे का, कॉलर त्याकडे काय मागू शकतो, आणि डेमन त्याच्या रनटाइम डिरेक्टरीखाली काय उघड करतो हे दाखवतात।

systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager

क्रिया कशावर परिणाम करते तेही विचारा। वैयक्तिक वाटणारा मेनू घटक संपूर्ण यंत्रासाठी मार्ग आणि DNS बदलू शकतो, याचा अर्थ तो इतर वापरकर्त्यांच्या सत्रांना अडथळा आणू शकतो। प्रभावाची त्रिज्या परवानगीच्याच आढाव्यात येते, आणि सेवेला अधिक अरुंद भूमिका हवी आहे का हे सहसा तीच ठरवते।

समर्थित पद्धतीने परवानग्या दुरुस्त करा

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

उत्पादन क्रियेसाठी अधिक अरुंद भूमिका देत असेल, तर सर्वसाधारण परवानगीपेक्षा तीच निवडा। निवडलेली भूमिका आणि तिचा मालक सेवेच्या नावाशेजारी लिहा।

चांगली विभागणी कशी दिसते

सामान्य अनुप्रयोग विशेषाधिकारांशिवाय राहतात, सेवा फक्त ज्यासाठी तयार केली ते सेटअप करते, आणि प्रत्येक कॉलरची एखाद्याच्या मालकीच्या धोरणाशी तपासणी होते। ती रक्षणीय रचना आहे। ती लेखापरीक्षणयोग्यही आहे, कारण धोरणाशी एक नाव जोडलेले आहे। यापेक्षा मोठी कोणतीही गोष्ट शांत परवानगी बदलाऐवजी लिखित अपवादास पात्र आहे।

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