रूट एक्सेस जो रूट पासवर्ड नहीं बदल सकता है?

Question

हमें सर्वर पर थोड़ी समस्या हो रही है। हम चाहते हैं कि कुछ उपयोगकर्ता उदा sudoऔर रूट करने में सक्षम हों , लेकिन इस प्रतिबंध के साथ कि उपयोगकर्ता रूट पासवर्ड को बदल नहीं सकता है। यही है, एक गारंटी है कि हम अभी भी उस सर्वर पर लॉगिन कर सकते हैं और इस बात की जड़ बन सकते हैं कि अन्य उपयोगकर्ता क्या करेंगे।

क्या यह संभव है?

Comments

आप sudoकेवल विशिष्ट रूट-विशेषाधिकार प्राप्त आवेदन के लिए अनुमति देने के लिए उपयोग कर सकते हैं । इस तरह, उपयोगकर्ता को रूट पासवर्ड बदलने की अनुमति नहीं दी जाएगी

— SHW

आपको sudoइन उपयोगकर्ताओं की आवश्यकता क्यों है यदि आप उन पर भरोसा नहीं करते हैं, तो उन्हें sudoपहली जगह पर पहुंच न दें । यह भी ध्यान दें कि आदर्श रूप से, रूट में एक पासवर्ड नहीं होना चाहिए , लेकिन आपको प्रमाणीकरण के अन्य साधनों का उपयोग करना चाहिए। (जो उपयोगकर्ता अभी भी "हैक" करने में सक्षम होगा, भले ही आप प्रोटेक्ट करेंगे /etc/passwd)

— Anony-Mousse

उन उपयोगकर्ताओं को वास्तव में क्या करने की आवश्यकता है?

— ओलिवियर दुलैक

वे अपनी जड़-विशेषाधिकारों के साथ क्या करने जा रहे हैं? आप जो सोच रहे हैं, उससे बेहतर उपाय हो सकता है।

— स्पार्टिकवीज

यह उन लोगों में से एक है "क्या ईश्वर इतना बड़ा पत्थर बना सकता है कि वह खुद उसे उठा न सके?" प्रश्न टाइप करें। यदि आपके पास रूट एक्सेस है, तो आप कुछ भी कर सकते हैं, यही कारण है कि रूट एक्सेस को विवेकपूर्ण रूप से दिया गया है। sudoऔर setuidअधिकांश समस्याओं को हल कर सकते हैं।

— bsd

Answer 1

हम चाहते हैं कि कुछ उपयोगकर्ता उदाहरण के लिए sudoऔर रूट बनने में सक्षम हों ,

खैर, यह समस्या सूडो को हल करने के लिए डिज़ाइन की गई है, ताकि यह हिस्सा काफी आसान हो।

लेकिन प्रतिबंध के साथ कि उपयोगकर्ता रूट पासवर्ड को बदल नहीं सकता है।

आप कर सकते हैं, जैसा कि SHW ने एक टिप्पणी में कहा है, केवल कुछ उपयोगकर्ताओं द्वारा रूट के रूप में ली जाने वाली कुछ क्रियाओं को अनुमति देने के लिए sudo कॉन्फ़िगर करें। यही है, आप उपयोगकर्ता 1 को करने की अनुमति दे सकते हैं sudo services apache2 restart, उपयोगकर्ता 2 को करने की अनुमति दे सकते हैं sudo rebootलेकिन कुछ और नहीं, जबकि काम पर रखने वाले सिस्टम-व्यवस्थापक user3को करने की अनुमति देता है sudo -i। वहाँ कैसे इस तरह sudo स्थापित करने के लिए उपलब्ध पर howtos हैं, या आप यहाँ (या पूछ) खोज सकते हैं। यह एक हल करने योग्य समस्या है।

हालांकि, एक उपयोगकर्ता जिसे एक शेल ( sudo -iया उदाहरण के लिए) की क्षमता दी गई है, वह कुछ भी कर सकता है। ऐसा इसलिए है कि जब तक सूडो शेल को लॉन्च करते हैं, तब तक सुडो खुद तस्वीर से बाहर हो जाता है। यह एक अलग उपयोगकर्ता (सबसे अधिक बार रूट) का सुरक्षा संदर्भ प्रदान करता है, लेकिन निष्पादित एप्लिकेशन क्या करता है, इसमें कोई कुछ नहीं कहा गया है। यदि वह अनुप्रयोग बदले में लॉन्च होता है, तो इसके बारे में कुछ भी सूडो नहीं कर सकता है। ध्यान दें कि यह अन्य अनुप्रयोगों के माध्यम से भी किया जा सकता है; उदाहरण के लिए, कई अधिक उन्नत संपादक शेल के माध्यम से एक कमांड निष्पादित करने के लिए सुविधाएं प्रदान करते हैं, एक शेल जो उस संपादक प्रक्रिया के प्रभावी यूआईडी (यानी, रूट) के साथ निष्पादित किया जाएगा ।sudosudo bashpasswd root

यही है, एक गारंटी है कि हम अभी भी उस सर्वर पर लॉगिन कर सकते हैं और इस बात की जड़ बन सकते हैं कि अन्य उपयोगकर्ता क्या करेंगे।

माफ़ करना; यदि आप वास्तव में "यह सुनिश्चित करते हैं कि हम लॉग इन कर पाएंगे और सिस्टम का उपयोग करने में सक्षम होंगे, चाहे कोई भी रूट एक्सेस वाला कोई भी व्यक्ति इसे करता हो", कि (सभी इरादों और उद्देश्यों के लिए) नहीं किया जा सकता है। एक त्वरित "sudo rm / etc / passwd" या "sudo chmod -x / bin / bash" (या जो भी शेल रूट का उपयोग करता है) और आप वैसे भी बहुत अधिक hosed हैं। "बहुत ज्यादा hosed" अर्थ "आपको बैकअप से पुनर्स्थापित करने की आवश्यकता होगी और आशा है कि उन्होंने उंगलियों की एक पर्ची से भी बदतर कुछ नहीं किया"। आप एक अनुपयोगी प्रणाली के कारण होने वाली आकस्मिक दुर्घटना के जोखिम को कम करने के लिए कुछ कदम उठा सकते हैं , लेकिन आप बहुत गंभीर समस्याओं को पैदा करने से दुर्भावना को नहीं रोक सकते हैं और इस प्रणाली को खरोंच से या बहुत कम से कम पुनर्निर्माण की आवश्यकता सहित अच्छा बैकअप।

किसी उपयोगकर्ता को किसी सिस्टम पर अनफ़िट किए गए रूट एक्सेस देकर, आप उस उपयोगकर्ता पर भरोसा करते हैं (किसी भी सॉफ़्टवेयर सहित वे निष्पादित करने के लिए चुन सकते हैं, यहां तक ​​कि सांसारिक के रूप में कुछ भी) दुर्भावनापूर्ण इरादा नहीं है, और दुर्घटना से गड़बड़ नहीं करने के लिए। यह रूट एक्सेस की प्रकृति है।

उदाहरण के लिए sudo के माध्यम से सीमित रूट का उपयोग थोड़ा बेहतर है, लेकिन आपको अभी भी किसी भी हमले के वैक्टर को नहीं खोलने के लिए सावधान रहना होगा। और रूट एक्सेस के साथ, विशेषाधिकार वृद्धि हमलों के लिए बहुत सारे संभावित हमले वैक्टर हैं।

यदि आप उन तक पहुँचने के स्तर के साथ उन पर भरोसा नहीं कर सकते हैं जो रूट की आवश्यकता होती है, तो आपको या तो बहुत कड़े नीचे sudo कॉन्फ़िगरेशन की आवश्यकता होगी , या किसी भी तरह से, sudo या अन्यथा सभी के माध्यम से प्रश्न रूट एक्सेस में उपयोगकर्ता को आसानी से अनुदान नहीं देना होगा।

Comments

मुझे खेद है कि मेरे उत्तर को सभी प्रचार मिल गए (मैं इसे प्राप्त नहीं करता!)। आपका जवाब उत्कृष्ट अंक उठाता है और मुझे आशा है कि यह स्वीकार हो जाएगा। आप को +1, सर।

— जोसेफ आर।

@JosephR। कभी-कभी एक संक्षिप्त जवाब पसंद किया जाता है।

— डेविड काउडन

@DavidCowden हाँ, ऐसा लगता है कि यह यहाँ मामला है ...

— यूसुफ आर।

@JosephR। मेरी कोई चिंता नहीं। स्टैक एक्सचेंज समुदाय हमेशा अनुमानित नहीं होता है, और ऐसे प्रश्न जिनके पास पहले से ही बहुत सारे upvotes हैं वे अधिक आकर्षित करते हैं। हालांकि upvote के लिए धन्यवाद। :)

— बजे एक CVn

Answer 2

यह व्यावहारिक रूप से असंभव है। सबसे पहले, यदि आप उन्हें जड़ बनने की शक्ति प्रदान करते हैं , तो कुछ भी नहीं है जो आप उन्हें कुछ भी करने से रोक सकते हैं। आपके उपयोग के मामले में, sudoअपने उपयोगकर्ताओं को कुछ मूल शक्तियां प्रदान करने के लिए उपयोग किया जाना चाहिए , जबकि दूसरों को रूट किए बिना उन्हें प्रतिबंधित करना ।

अपने परिदृश्य में, आप के लिए उपयोग को प्रतिबंधित करने की आवश्यकता होगी suऔर passwdबाकी काफी सब कुछ करने के लिए आदेश और खुली पहुंच। समस्या यह है कि कुछ भी नहीं है जो आप अपने उपयोगकर्ताओं को सीधे /etc/shadow(या /etc/sudoersउस मामले के लिए) संपादन से रोकने के लिए कर सकते हैं और एक रूट रूट पासवर्ड को हाईजैक करने के लिए रूट में छोड़ सकते हैं। और यह सिर्फ सबसे सीधा "हमला" परिदृश्य संभव है। एक या दो आदेशों को छोड़कर अप्रतिबंधित शक्ति वाले शूडर पूर्ण रूट एक्सेस को प्रतिबंधित करने के लिए प्रतिबंधों के आसपास काम कर सकते हैं।

एकमात्र समाधान, जैसा कि टिप्पणियों में SHW द्वारा सुझाया गया है, sudoअपने उपयोगकर्ताओं को आदेशों के प्रतिबंधित सेट तक पहुंच प्रदान करने के लिए उपयोग करना है।

---

अपडेट करें

प्रमाणीकरण के लिए यदि आप Kerberos टिकट का उपयोग करते हैं तो इसे पूरा करने का एक तरीका हो सकता है। फ़ाइल के उपयोग के बारे में बताते हुए इस दस्तावेज़ को पढ़ें .k5login।

मैं संबंधित भागों को उद्धृत करता हूं:

मान लीजिए कि उपयोगकर्ता की ऐलिस के पास उसके घर निर्देशिका में एक .k5login फ़ाइल थी जिसमें निम्न पंक्ति थी:
[e-mail]
यह बॉब को Kerberos नेटवर्क अनुप्रयोगों, जैसे ssh (1) का उपयोग करने, एलिस के खाते तक पहुँचने के लिए, बॉब के Kerosos टिकट का उपयोग करने की अनुमति देगा।
...
ध्यान दें कि क्योंकि बॉब अपने स्वयं के प्रिंसिपल के लिए केर्बोस टिकट को बरकरार रखता है, उसके [e-mail]पास किसी भी विशेषाधिकार नहीं हैं जो एलिस के टिकट की आवश्यकता होती है, जैसे कि साइट के किसी भी मेजबान के लिए रूट एक्सेस, या एलिस का पासवर्ड बदलने की क्षमता।

हालांकि मुझसे गलती हो सकती है। मैं अभी भी प्रलेखन के माध्यम से जा रहा हूँ और अभी तक खुद के लिए Kerberos की कोशिश करना है।

Comments

आपने उस शांत संदर्भ को एक टिप्पणी के लिए कैसे किया? मैंने आपके उत्तर के लिए स्रोत को देखा और उसके चारों ओर देखा ()। शांत गुप्त टोपी!

— जो

@ जो समय एक टिप्पणी पोस्ट किया गया था वह वास्तव में टिप्पणी का एक लिंक है।

— जोसफ आर।

@Joe <tr id="thisistheid"...टिप्पणी करने के लिए आईडी ( ) का पता लगाएं (जैसे क्रोम राइट-क्लिक और Inspect element), फिर इसे पूर्ववर्ती लिंक के साथ थ्रेड लिंक पर जोड़ें #। आपके मामले में (आईडी = comment-162798) यह इस तरह दिखता है: unix.stackexchange.com/questions/105346/…

— polym

उत्तर के लिए धन्यवाद, मुझे नहीं पता था कि मुझे यह स्वीकार करना चाहिए या कि @ मिचेल काजर्लिंग से, मैंने उनका चयन इसलिए किया क्योंकि इसमें अधिक विवरण है - मेरे जैसे एक noob द्वारा आवश्यक :) हालांकि, आपका भी मददगार था

— 244

@ 244 कोई चिंता नहीं। मैंने खुद भी यही सिफारिश की होगी । :)

— जोसेफ़ आर।

Answer 3

मैं मान रहा हूं कि आप यह सुनिश्चित करना चाहते हैं कि आपके पास "आपातकालीन व्यवस्थापक" की पहुंच हो, भले ही आपका वास्तविक प्रशासक खराब हो (लेकिन इसके अलावा, आप मुख्य प्रशासक पर पूरा भरोसा करते हैं)।

एक लोकप्रिय दृष्टिकोण (हालांकि बहुत हैकिश) के साथuid=0 एक दूसरा उपयोगकर्ता है , जिसे आमतौर पर नाम दिया गया है toor(मूल पीछे की ओर)। इसका एक अलग पासवर्ड है, और बैकअप एक्सेस के रूप में काम कर सकता है। जोड़ने के लिए, आप की संभावना को संपादित करना होगा /etc/passwdऔर /etc/shadow(कॉपी rootलाइनों)।

यह सब लेकिन विफल-सुरक्षित है, लेकिन अगर आपको "मुख्य प्रशासक" को बिना सूचना के पासवर्ड बदलने की सुरक्षा करने की आवश्यकता है, तो यह काम करेगा। toorखाते को हटाकर इसे अक्षम करना तुच्छ है ; इसलिए एकमात्र लाभ एक अलग पासवर्ड है।

वैकल्पिक रूप से, आप वैकल्पिक प्रमाणीकरण तंत्र, यानी sshचाबियाँ libnss-extrausers, एलडीएपी आदि को देखना चाहते हैं ।

ध्यान दें कि व्यवस्थापक अभी भी बुरी तरह से खराब हो सकता है। उदाहरण के लिए, फ़ायरवॉल को अवरुद्ध करके।

यदि आप एक बहुत ही सुरक्षित प्रणाली चाहते हैं, तो SELinux का उपयोग करने पर विचार करें, जहां यूनिक्स उपयोगकर्ता (जैसे रूट) भी एक भूमिका के साथ आ रहा है, जो बहुत अधिक बारीक हो सकता है। आप अपने व्यवस्थापक को रूट एक्सेस देना चाह सकते हैं, लेकिन केवल एक प्रतिबंधित भूमिका (उदाहरण के लिए केवल अपाचे को प्रशासित करना)। लेकिन इसके लिए पॉलिसी को सही ढंग से कॉन्फ़िगर करने के लिए आपकी तरफ से काफी प्रयास करने की आवश्यकता होगी।

Comments

यह वास्तव में उपयोगकर्ता toorको रूट पासवर्ड बदलने से नहीं रोकता है ; यह केवल रूट करने के लिए दूसरा पासवर्ड प्रदान करता है।

— एलेक्सिस

-1, तब। आप एक पिछले दरवाजे के पासवर्ड का सुझाव दे रहे हैं ताकि वे इसे खो देने के बाद प्रवेश को ठीक कर सकें? जैसा कि आपने कहा, यह सिर्फ गलत है, और इसके अलावा pesky उपयोगकर्ता इसे आसानी से अक्षम कर सकते हैं। पिछले दरवाजे को स्थापित करने के लिए बहुत अधिक विश्वसनीय तरीके हैं।

— एलेक्सिस

@alexis वह है जो IMHO प्रश्न के लेखक से पूछा है। इसके लिए -1 क्यों दें? toorदशकों से यूनिक्स पर रिकवरी अकाउंट एक आम बात है (हालांकि पर आधारित है)।

— ऐनी-मूस

यदि एकमात्र लक्ष्य आकस्मिक पासवर्ड परिवर्तनों से बचाव है , तो यह एक अच्छा उत्तर है। यदि लक्ष्य कुछ भी दुर्भावनापूर्ण नहीं है, तो यह बहुत मदद नहीं है। चूंकि ओपी ने यह नहीं बताया कि लक्ष्य क्या था, हम नहीं जानते।

— बोबसन

यही कारण है कि मैंने अपने पहले वाक्य में कहा है: "शिकंजा कसता है ... इसके अलावा, आपको भरोसा है ... पूरी तरह से"। यह वास्तव में केवल "समर्थन पहुंच" समाधान है; सुरक्षा सुविधा नहीं। अतिरिक्त रूट ssh कुंजियों का उपयोग करते हुए, बिना हैक किए बिना ही प्राप्त होता है।

— एनोनी-मूस

Answer 4

मूल का सार सिस्टम की अप्रतिबंधित कमान है। आप इसे SELinux से जोड़ सकते हैं (एक डेमो साइट हुआ करती थी जहां कोई भी रूट के रूप में लॉग इन कर सकता था, लेकिन इसकी शक्ति एक्सेस सिस्टम के माध्यम से अपंग हो गई थी), लेकिन यह बात नहीं है। मुद्दा यह है कि यह आपकी समस्या का गलत समाधान है।

अब, आपने यह नहीं बताया कि आपकी समस्या क्या है, लेकिन यदि आप इन उपयोगकर्ताओं को रूट पासवर्ड बंद रखने के लिए विश्वास नहीं करते हैं, तो उनका कोई व्यवसाय नहीं है। यदि उन्हें वेबसर्वर, या विभिन्न हार्डवेयर डिवाइस, या ताना ड्राइव या जो कुछ भी प्रशासित करना है, उसके लिए एक समाधान सेट करना होगा। एक सुपर-पावर्ड ग्रुप बनाएं, इसे उसकी ज़रूरत की सभी एक्सेस दें, और उन्हें इसमें जोड़ें। यदि उन्हें रूट-ओनली सिस्टम कॉल निष्पादित करने की आवश्यकता है, तो कुछ सेट्यूइड प्रोग्राम लिखें।

बेशक उस तरह का उपयोग (और थोड़ा सा ज्ञान) वाला उपयोगकर्ता शायद सिस्टम को आसानी से हैक कर सकता है, लेकिन कम से कम आप ओएस सुरक्षा मॉडल के साथ काम कर रहे हैं, इसके खिलाफ नहीं।

पुनश्च। पासवर्ड के बिना अपने लिए रूट एक्सेस की व्यवस्था करने के कई तरीके हैं; एक के लिए, यदि आप /etc/sudoers(प्रतिबंधों के बिना) हैं, तो आपको केवल रूट करने के लिए अपना पासवर्ड चाहिए, जैसे कि sudo bash। लेकिन आपको बस वहां जाने की जरूरत नहीं है।

Comments

लेकिन समस्या यह है कि आप हमलावर को एक शोषण के माध्यम से जड़ हासिल करने से नहीं रोक सकते, SELinux गहराई में रक्षा प्रदान करता है।

— टिमोथी लेउंग

Answer 5

यह संभव है, कम से कम सिद्धांत में, SELinux का उपयोग करके ऐसा करने के लिए । यह आपको उपयोगकर्ता या प्रक्रिया क्या है या क्या करने की अनुमति नहीं है, इसके बारे में अधिक सटीक नियम सेट करने की अनुमति देता है। SELinux के साथ भी, उपयोगकर्ता के लिए रूट पासवर्ड बदलना असंभव बनाने के लिए मुश्किल हो सकता है, लेकिन फिर भी वे जो कुछ भी करने की आवश्यकता हो सकती है वह करने में सक्षम है।

वास्तव में यह इस बात पर निर्भर करता है कि जो उपयोगकर्ता रूट पासवर्ड को बदलने की अनुमति नहीं देता है वह वास्तव में क्या करने में सक्षम होना चाहिए। यह शायद आसान होगा और सुरक्षित होगा कि क्या है, और विशेष रूप से सुडो का उपयोग करके उन अनुमतियों को अनुदान दें।

Comments

जबकि SELinux के साथ ऐसा करना सिद्धांत में संभव हो सकता है (और मुझे यकीन नहीं है), यह दावा करते हुए कि यह वास्तविक नियमों को दिखाए बिना किसी की मदद करने वाला नहीं है।

— गिल्स

@ अच्छी तरह से वास्तव में , यह वही है जो SELinux के लिए डिज़ाइन किया गया था। SELinux मानक POSIX अनुमतियों के अतिरिक्त आवश्यक अनुमतियों की एक परत है । ठीक से कॉन्फ़िगर की गई SELinux मशीन पर, रूट एक्सेस अर्थहीन है क्योंकि आपकी वास्तविक अनुमतियाँ सुरक्षा संदर्भ और ऑब्जेक्ट लेबलिंग द्वारा निर्धारित की जाती हैं।

— टाइरेल

यदि आप जानते हैं कि यह कैसे करना है, तो कृपया मिथक या वास्तविकता का

— गिल्स

सैद्धांतिक रूप से, यह अभी भी SELinux के साथ संभव हो सकता है; हालाँकि, इस तरह की चीज़ का सेटअप "सामान्य" फ़ाइल-सिस्टम (जिस पर rootउपयोगकर्ता की पूर्ण पहुंच है) से सभी SELinux- संबंधित कॉन्फ़िगरेशन फ़ाइलों के लिए एक मजबूत पृथक्करण सुनिश्चित करने के लिए और अधिक जटिल होने की आवश्यकता होगी । अंत में, इस तरह की जुदाई के लिए "सबसे आसान" विधि (

— सिलेन्क्स के

Answer 6

शायद आपको उपयोगकर्ताओं को वर्चुअल मशीन या LXC कंटेनर में रूट एक्सेस देने पर विचार करना चाहिए। यह उन्हें सिस्टम में पूर्ण रूट एक्सेस करने की अनुमति देगा, बिना उन्हें होस्ट में प्रवेश करने या प्रशासनिक कार्रवाई करने से रोकता है।

Comments

यह IMHO विकल्पों में से कई से अधिक सुरक्षित होगा।

— एल्डर गीक

Answer 7

मुझे नहीं पता कि यह व्यावहारिक रूप से संभव होगा लेकिन यहां एक गंदा हैक है:

1. एक रैपर स्क्रिप्ट / प्रोग्राम लिखें जो /etc/passwdवास्तविक कॉल करने से पहले फ़ाइल को किसी अन्य स्थान पर कॉपी कर देगाsudo
2. सामान्य उपयोगकर्ता को उपयोग करने की अनुमति दें sudo
3. एक बार जब उसने अपना कार्य पूरा कर लिया, या जब वह सुडो से बाहर आया, तो /etc/passwdफ़ाइल को पुनर्स्थापित करें

मुझे पता है, इसको हासिल करने के लिए बहुत सारी प्लस-माइनस चीजें हैं जिन पर आपको विचार करना है। आखिरकार, यह एक गंदा हैक है

Comments

इस बात की संभावना हमेशा बनी रहती है कि कोई दुर्भावनापूर्ण उपयोगकर्ता इस स्क्रिप्ट को पढ़ेगा और बैकअप प्रतिलिपि बना देगा।

— जोसेफ आर।

यह भी बहुत ज्यादा है vipwऔर दोस्त पहले से ही क्या करते हैं।

— एक CVn

इस कार्यक्रम पर विचार करें, और केवल रूट एक्सेस

— SHW

rootके बाद "अन्य स्थान" को संपादित कर सकते हैं sudo।

— ऐनी-मूस

आप संभावित दुर्भावनापूर्ण उपयोगकर्ता के लिए रूट क्यों प्राप्त करेंगे ??? जड़ के रूप में, यह एक पिछले दरवाजे को स्थापित करने के लिए तुच्छ है जो सूडो और / या रैपर से गुजरने पर निर्भर नहीं करता है ...

— एलेक्सिस

Answer 8

यह कथन sudoकेवल जड़ देने के लिए है और इसके बाद कोई सुरक्षा नहीं है।

आप visudosudoers फ़ाइल को संशोधित करने के लिए उपयोग करते हैं । यहाँ एक उदाहरण पंक्ति है:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

• redsandroवह उपयोगकर्ता नाम है जिसे हम अनुमति दे रहे हैं। %इसे एक समूह पर लागू करने के लिए सामने की ओर रखें ।
• ALLइस नियम का एक नाम है। Sudoers वैश्विक अनुमतियों की तुलना में बहुत अधिक कर सकते हैं। हालांकि यह जटिल हो जाता है।
• = कोई स्पष्टीकरण की जरूरत है
• ALL:ALLके रूप में पढ़ता है (who_to_run_it_as: what_group_to_run_it_as)। इस तरह आप एक कमांड चलाने की अनुमति दे सकते हैं, लेकिन केवल एक विशिष्ट उपयोगकर्ता या समूह के संदर्भ में।
• NOPASSWD: इसे पासवर्ड प्रांप्ट को बंद करना बताता है।
• /path/to/command आपको विशिष्ट कमांड path_to_commmand, other_command निर्दिष्ट करने देता है

याद रखने वाली बात यह है कि जहां sudoज्यादातर घरेलू उपयोगकर्ताओं द्वारा रूट विशेषाधिकारों को बढ़ाने के लिए उपयोग किया जाता है, वहीं इसका उपयोग विशिष्ट आदेशों तक पहुंच को नियंत्रित करने के लिए किया जा सकता है।

संदर्भ

• यहाँ मेरे दूसरे जवाब से

Comments

यह उत्तर बताता है कि सीमित रूट एक्सेस के लिए सुडो को कैसे सेट किया जाए, लेकिन यह बेहतर होगा यदि उत्तर ऐसा कहा जाए और यह कहां जाना चाहिए।

— एक CVn

@ माइकलकॉर्जिंग ने किया

— रोबॉटहूमंस

"बयान है कि सुडो सिर्फ जड़ देने के लिए है और उसके बाद कोई सुरक्षा नहीं है। मान लें कि मैं sudo viकिसी उपयोगकर्ता को एक्सेस प्रदान करता हूं क्योंकि मैं चाहता हूं कि वे सिस्टम कॉन्फ़िगरेशन फ़ाइलों को संपादित करने में सक्षम हों। वह उपयोगकर्ता तब :!/bin/bashएक sudo viसत्र के अंदर करता है । Sudo की क्षमता को कैसे प्रतिबंधित किया जा सकता है जो उपयोगकर्ता sudo के माध्यम से उन कमांड को निष्पादित कर सकता है जो उन परिस्थितियों में मेरे सिस्टम को सुरक्षित रखने में मदद करता है? (किसी ने भी नहीं कहा है कि sudo को ऑल- sudo -i

— ऑर-नॉन

किसी कार्य को करने का तरीका जानना एक दृष्टिकोण की सीमाओं को समझना उतना ही महत्वपूर्ण है।

— एक CVn

@ माइकलकॉर्जलिंग, मुझे लगता है कि यह सिर्फ एक उदाहरण है। लेकिन स्पष्ट होने के लिए, उपयोगकर्ताओं को सिस्टम कॉन्फ़िगरेशन फ़ाइलों को संपादित करने का सही तरीका उन्हें चलाने देना है sudoedit। आप विशेष रूप से पहचान कर सकते हैं कि उन्हें कौन सी फाइलें सक्षम होनी चाहिए sudoedit। इसमें है man sudoers।

— मैथ्यू फ्लैशेन

Answer 9

(मैं ubuntu नहीं जानता, लेकिन यह फेडोरा / रेड-हेट के समान होना चाहिए)
रूट पासवर्ड को बदलने के लिए उपयोग को प्रतिबंधित करने की केवल एक ही चीज की मैं कल्पना कर सकता हूं कि पूर्ण रूट एक्सेस नहीं दे रहा है, शायद sudo के साथ, या एक्सेस को प्रतिबंधित करने के लिए सेलाइनक्स का उपयोग कर रहा है पासवर्ड फ़ाइल के लिए ... लेकिन मैं या तो बहुत अधिक पहुंच के साथ भरोसा नहीं करूंगा क्योंकि रूट में आम तौर पर अप्रतिबंधित पहुंच होती है और वह पासवर्ड बदलने के लिए सेलाइनक्स को अपडेट कर सकता है, या पासवर्ड फ़ाइल को पुनः लोड कर सकता है, या कुछ पूर्व -प्राय प्रोग्राम चला सकता है।

यदि आप उन पर भरोसा नहीं करते हैं तो पासवर्ड को बदलने के लिए न करें जो आपको संभवतः उन्हें रूट एक्सेस नहीं देना चाहिए। अन्यथा मुझे लगता है कि आप दुर्घटनाओं से बचने की कोशिश कर रहे हैं।

यदि आप केवल रूट तक अपनी पहुंच की सुरक्षा करने का प्रयास कर रहे हैं, तो एक प्रोग्राम सेट करें जो रूट पासवर्ड को पुनर्स्थापित कर सकता है, इसलिए भले ही यह बदल गया हो, इसे न्यूनतम एक्सेस के साथ बहाल किया जा सकता है। (sudo यह खुद पर अच्छा करता है)

Answer 10

आपकी आवश्यकता है:

हमें एक सर्वर […] पर थोड़ी समस्या हो रही है, इस बात की गारंटी है कि हम अभी भी उस सर्वर पर लॉगिन कर सकते हैं और इस बात की जड़ बन सकते हैं कि अन्य उपयोगकर्ता क्या करेंगे।

आपके प्रश्न से ऐसा लगता है जैसे आप अपने सिस्टम को नष्ट करने के इरादे से यादृच्छिक दुर्भावनापूर्ण उपयोगकर्ताओं का सामना नहीं कर रहे हैं, लेकिन इसके बजाय अर्ध-विश्वसनीय उपयोगकर्ता हैं जो अभी और फिर शरारत का कारण बन सकते हैं (शायद छात्र?)। मेरे सुझाव उस स्थिति को संबोधित करते हैं, न कि दुर्भावनापूर्ण उपयोगकर्ताओं द्वारा किए गए हमले।

1. वर्चुअल वातावरण के अंदर सर्वर चलाएँ। आप सर्वर के फाइलसिस्टम को माउंट करने और ज्ञात-अच्छे संस्करणों के साथ परिवर्तित फ़ाइलों को बदलने में सक्षम होंगे। आपके द्वारा अनुमानित संभावित नुकसान के आधार पर, आप सभी महत्वपूर्ण निर्देशिकाओं (/ बिन, / sbin, / etc, / usr, / var, आदि) का स्नैपशॉट ले सकते हैं और बाकी हिस्सों को छोड़ते हुए क्षतिग्रस्त फ़ाइलों को अधिलेखित करने के लिए स्नैपशॉट का विस्तार कर सकते हैं। सिस्टम बरकरार है।

2. डीवीडी-आर से सिस्टम केवल पढ़ने के लिए, जैसे। यदि आप सिस्टम के अधिकांश हिस्सों को अगले रिबूट तक स्थिर होने के साथ रह सकते हैं, तो यह एक अच्छा विकल्प है। आप वर्चुअल वातावरण के साथ रीड-ओनली बैकिंग स्टोर का भी उपयोग कर सकते हैं या नेटवर्क पर बेस सिस्टम को लोड कर सकते हैं, जिससे रिबूट के बीच परिवर्तन करना एक नया डीवीडी-आर लिखने की तुलना में बहुत आसान है।

3. कर्नेल मॉड्यूल। कर्नेल के लिनक्स सुरक्षा मॉड्यूल (एलएसएम) सुरक्षित मॉड्यूल बनाने के लिए आधार प्रदान करते हैं। LSM का उपयोग SELinux द्वारा किया जाता है, लेकिन इसका उपयोग स्मैक, TOMOYO और AppArmor जैसे कई कम-ज्ञात और सरल प्रणालियों द्वारा भी किया जाता है। इस लेख में विकल्पों का अच्छा अवलोकन है। संभावना उन लोगों में से एक है जो / etc / passwd, / etc / shadow, या किसी भी अन्य फ़ाइल (ओं) को लिखने से रोकने के लिए आउट-ऑफ-बॉक्स को कॉन्फ़िगर कर सकते हैं, जिसे आप मूल रूप से चाहते हैं।

4. # 1 के रूप में एक ही विचार है, लेकिन जब सर्वर एक आभासी वातावरण में नहीं है। आप सर्वर चेन-लोड को केवल एक लाइव ओएस जैसे रीड-ओनली ओएस में रख सकते हैं, जो स्वचालित रूप से सर्वर की फाइलसिस्टम को माउंट करेगा और ज्ञात-अच्छी प्रतियों के साथ प्रत्येक बूट पर आधार प्रणाली को अधिलेखित करेगा। रीड-ओनली OS तब मुख्य OS में बूट होगा।

5. फिर, यह मानते हुए कि ये अर्ध-विश्वसनीय उपयोगकर्ता हैं जो उच्च-शिक्षक (शिक्षक / बॉस) के प्रति जवाबदेह हैं, सबसे अच्छा जवाब लिनक्स रिटिट हो सकता है । इस तरह आप हर सुरक्षा-संगत कार्रवाई को जान पाएंगे और इसे किसने लिया है (आपको पता चल जाएगा कि इसे किसने लिया क्योंकि अगर सभी उपयोगकर्ता रूट खाते को साझा करते हैं, तो पहले उनके उपयोगकर्ता खाते से sudo'ed होगा)। वास्तव में आप रियल टाइम में ऑडिट लॉग को पार्स करने और क्षतिग्रस्त फाइलों को बदलने में सक्षम हो सकते हैं। / आदि / छाया अधिलेखित? कोई समस्या नहीं है, बस मॉनिटरिंग सर्वर तुरंत इसे एक ज्ञात-अच्छे संस्करण के साथ बदल देता है।

अन्य तकनीकें जिन्हें आप अपनी आवश्यकताओं के आधार पर जांचना चाहते हैं:

• लिनक्स इंटीग्रिटी मेजरमेंट आर्किटेक्चर / एक्सटेंडेड वेरिफिकेशन मॉड्यूल (IMA / EVM), और
• विश्वसनीय प्लेटफ़ॉर्म मॉड्यूल (टीपीएम)।

Answer 11

अन्य उत्तरों को पूरक करने के लिए, मैं यह मानकर चल रहा हूं कि आप एक दुर्लभ स्थिति पर नियंत्रण खोने का अनुभव करते हैं, और उन मामलों में सर्वर रिबूट की अनुमति है। (आखिरकार, यदि आपको लगता है कि मशीन से छेड़छाड़ की गई है तो आप इसे वैसे भी ऑफ़लाइन लेना चाहेंगे।)

इसका महान लाभ यह है कि कॉन्फ़िगर करने के लिए कुछ भी नहीं है। आपका प्रश्न बन जाता है: " मैं रूट पासवर्ड भूल गया हूं, मैं कैसे वापस आ सकता हूं? " और इसका उत्तर रीबूट करना है, और मशीन के ऊपर आने पर सिंगल-यूजर मोड का चयन करना है। आपको पासवर्ड जानने की आवश्यकता के बिना एक रूट शेल देता है। उस बिंदु पर आप एक नया पासवर्ड सेट कर सकते हैं। (साथ ही जाने और किसी भी नुकसान की मरम्मत ...)

Comments

जैसा कि माइकल ने स्पष्ट रूप से उल्लेख किया है , दुर्भावनापूर्ण उपयोगकर्ता केवल बायनेरिज़ को मैसेज करके पासवर्ड को अपहरण किए बिना रूट एक्सेस को रोक सकता है। यहां तक ​​कि init=...दृष्टिकोण को अनुदैर्ध्य बायनेरिज़ से निष्पादन अनुमतियों को हटाने से रोका जा सकता है। मुझे लगता है कि इस मामले में एक बेहतर समाधान है, अपने रूट फाइलसिस्टम को लाइवसीडी के माध्यम से माउंट करना और नुकसान को ठीक करने का प्रयास करना। फिर, यदि आपको लगता है कि सिस्टम से समझौता किया गया है, तो आप किसी भी तरह से बैकअप से बहाल करना बेहतर होगा।

— जोसेफ आर।

सहमत @JosephR; क्षति की खोज करना और उसे ठीक करना जटिल है, और मैं अभी भी पुनः स्थापित करूंगा। लेकिन मुझे लगता है कि ओपी की चिंता किसी को गलती से उन्हें बंद करने के बारे में अधिक थी ... किसी काम या स्कूल की स्थिति में जानबूझकर हैक करना थोड़ा आत्मघाती है। ;-)

— डैरेन कुक

जरुरी नहीं। वास्तव में एक दुर्भावनापूर्ण उपयोगकर्ता जो एक लापरवाह / कुलीन वर्ग के साथ संयुक्त है अनिर्णित विशेषाधिकार बढ़ा सकता है। मैं इस बात से सहमत हूं कि ओपी का मूल इरादा शायद दुर्भावनापूर्ण इरादे के खिलाफ गार्ड के बजाय निर्दोष गलतियों को दूर करना था, लेकिन सवाल "सुरक्षा" को टैग किया गया था और हम सिर्फ इसके साथ भागे थे, मुझे लगता है :)

— जोसेफ आर।

Answer 12

यदि आप अपने सर्वर को VM (जैसे VirtualBox ) में क्लोन करते हैं , तो आप लोगों को अनफिट रूट एक्सेस दे सकते हैं और फिर भी गारंटी दे सकते हैं कि आपके पास अतिथि ऑपरेटिंग सिस्टम के विभाजन (एस) तक सीधी पहुंच होगी, और इसलिए अंतिम नियंत्रण बनाए रखें /etc/passwdऔर जैसे कि, आपके पास होस्ट सिस्टम पर रूट होगा।

बेशक, अनफ़िट किए गए रूट एक्सेस देना अभी भी सही समाधान नहीं हो सकता है: यदि डेटा सुरक्षा किसी समस्या या आपकी जिम्मेदारी पर है, तो आप रूट एक्सेस को दूर नहीं कर सकते।

Answer 13

आवश्यकता तकनीकी रूप से संभव नहीं है। जैसा कि पहले से ही स्पष्ट रूप से टिप्पणी की गई है, उपयोगकर्ता को असीमित या उससे अधिक सीमित sudoअधिकार प्रदान करने का मतलब है कि आपको उस उपयोगकर्ता पर भरोसा है। किसी के पास बुरे इरादे और पर्याप्त तकनीकी क्षमता और दृढ़ता है जो किसी भी बाधा से गुजर सकती है।

हालांकि, यह मानते हुए कि आप अपने उपयोगकर्ताओं पर भरोसा नहीं कर सकते हैं कि वे बुरे इरादे से नहीं हैं, आप पासवर्ड पर प्रतिबंध को नीति का मामला बना सकते हैं । आप passwdप्रोग्राम के लिए एक रैपर बना सकते हैं जो उन्हें याद दिलाएगा "कृपया रूट पासवर्ड न बदलें"। यह समस्या का स्रोत मानता है कि रूट पासवर्ड बदलने वाले उपयोगकर्ता गलतफहमी के कारण ऐसा कर रहे हैं (जैसे कि शायद यह सोचकर कि वे ऐसा करने के बाद अपना पासवर्ड बदल रहे हैं sudo bash)।

विशेष (दुर्लभ) परिस्थितियों में, यदि पूर्ण विश्वास संभव नहीं है और sudoपर्याप्त लेकिन यथोचित सुरक्षित विखंडू तक पहुंच को तोड़ना संभव नहीं है , तो आप पासवर्ड बदलने (या सिस्टम छेड़छाड़ के किसी अन्य निर्दिष्ट रूप) के खिलाफ संगठनात्मक प्रतिबंधों पर विचार कर सकते हैं , व्यवस्था करें महत्वपूर्ण संसाधनों की निगरानी करना ताकि निर्धारित नीतियों के आसपास जाने में आसानी न हो - और उपयोग नियमों और निगरानी के बारे में सार्वजनिक और पारदर्शी रहें।

निगरानी और खोज का पहलू कठिन तकनीकी समस्या है जिससे आपको उस रास्ते पर चलना चाहिए। मुझे लगता है कि हमें इसकी आवश्यकता होगी

1. जब कोई उपयोगकर्ता पहचान को रूट और किसी भी बनाई गई प्रक्रियाओं का ट्रैक रखने के लिए पहचानता है;
2. तब से प्रक्रिया कृतियों को लॉग करें, यह देखने के लिए कि प्रत्येक प्रक्रिया के लिए जिम्मेदार मूल उपयोगकर्ता कौन है, और दूरस्थ होस्ट का उपयोग करके जहां आधे-भरोसेमंद उपयोगकर्ताओं को लॉग भेजने के लिए पहुंच नहीं है;
3. जो हो रहा है उसे लॉग इन करने के लिए किसी भी तरह के सिस्टम ट्रेसिंग का उपयोग करें और बाद में पता करें कि पॉलिसी उल्लंघन के पीछे कौन था।

हमें कम से कम लेखन, प्रक्रिया निर्माण exec(), और निश्चित रूप से नेटवर्किंग बदलने के किसी भी प्रयास के लिए फ़ाइलों के सुरक्षित सेट के अलावा अन्य को खोलने की आवश्यकता होगी ।

कार्यान्वयन संशोधित libc या (बहुत बेहतर) सिस्टम कॉल ट्रेसिंग द्वारा किया जा सकता है ।

बेशक, इस तरह के अनुरेखण और लॉगिंग कार्य को 100% सही ढंग से करना असंभव है, इसे लागू करना आसान नहीं है, और इसे संचालित करने के लिए अतिरिक्त संसाधनों की भी आवश्यकता होती है। यह पासवर्ड परिवर्तन या अन्य अवांछित प्रणाली छेड़छाड़ को नहीं रोकेगा , लेकिन यह दोषी उपयोगकर्ता को खोजने के लिए (अधिक संभावना) संभव बना देगा या कम से कम एक भ्रम पैदा करेगा कि निगरानी है और इसे कुछ बुरे दिमाग वाले उपयोगकर्ताओं के लिए कम आमंत्रित करना है (लेकिन कुछ समस्याग्रस्त हैकर्स, जो तकनीकी उपायों की मूलभूत निरर्थकता को देखते हैं, को चुनौती को गले लगाने के लिए प्रोत्साहित किया जा सकता है और सिस्टम को इसके लिए मज़बूत बनाने की कोशिश करते हुए महसूस किया जा सकता है)।

Answer 14

मूल तैयार प्रश्न बेकार है। ऐसा लगता है कि मुख्य लक्ष्य "अभी भी लॉगिन है" इसलिए कुछ आपातकालीन प्रवेश के बारे में बोल रहा है जो किसी अन्य व्यक्ति को दिए गए रूट एक्सेस के साथ भी काम करना सुनिश्चित करता है। Anony-Mousse के लिए चीयर्स जिन्होंने पहली बार इसे स्पष्ट रूप से नोट किया था।

समस्या यह है: यदि मालिक के पास बॉक्स तक भौतिक पहुंच है, तो यह सिस्टम को आसानी से तार्किक शुल्क वसूल कर सकता है (बशर्ते यह अभी भी जीवित है :)। यदि नहीं - रूट पासवर्ड रखने से sshd डाउन या खराब नेटवर्क सेटअप से बचाव नहीं होगा, इस प्रकार सिस्टम अभी भी वैसे भी सुलभ नहीं है।

प्रशासनिक विशेषाधिकारों वाले किसी व्यक्ति द्वारा प्रणाली को नुकसान से कैसे बचाया जाए, इस विषय में एसई प्रश्न प्रारूप फिट करने के लिए बहुत व्यापक लगता है।

रिमोट इमरजेंसी एंटर सॉल्यूशन के बारे में बोलते हुए सबसे अच्छा तरीका आईपीएमआई है (मुझे लगता है) अगर यह उपलब्ध है। सिस्टम का मालिक कभी भी वर्चुअल ड्राइव को अटैच कर सकता है, इससे बूट कर सकता है और सिस्टम रिकवरी से जुड़ा हो सकता है।

यदि IPMI किसी भी उपयुक्त वर्चुअलाइजेशन तकनीक के लिए उपलब्ध नहीं है, तो यह काम के आसपास हो सकता है, जैसा कि पहले ही ऊपर प्रस्तावित किया जा चुका है।

Answer 15

आप अपनी /etc/sudoersफ़ाइल में sudo तक पहुँच को सीमित कर सकते हैं

/ Etc / sudoers के सिंटैक्स को पूरी तरह से समझाने के लिए, हम एक नमूना नियम का उपयोग करेंगे और प्रत्येक कॉलम को तोड़ेंगे:

jorge  ALL=(root) /usr/bin/find, /bin/rm

पहला कॉलम परिभाषित करता है कि यह सुडोल नियम किस उपयोगकर्ता या समूह पर लागू होता है। इस मामले में, यह उपयोगकर्ता जोर्ज है। यदि इस कॉलम में शब्द% प्रतीक से पहले है, तो यह इस मान को एक उपयोगकर्ता के बजाय एक समूह के रूप में नामित करता है, क्योंकि एक प्रणाली में समान नाम वाले उपयोगकर्ता और समूह हो सकते हैं।

दूसरा मूल्य (ALL) परिभाषित करता है कि यह सुडोल नियम किस पर लागू होता है। जब आप एक से अधिक सिस्टम में एक sudo वातावरण परिनियोजित करते हैं तो यह कॉलम सबसे अधिक उपयोगी होता है। एक डेस्कटॉप उबंटू प्रणाली, या एक प्रणाली के लिए जहां आप कई प्रणालियों में सुडो भूमिकाओं को तैनात करने की योजना नहीं बनाते हैं, आप इस मूल्य को ALL पर सेट करने के लिए स्वतंत्र महसूस कर सकते हैं, जो एक वाइल्डकार्ड है जो सभी होस्ट से मेल खाता है।

तीसरा मान कोष्ठक में सेट किया गया है और परिभाषित करता है कि उपयोगकर्ता या उपयोगकर्ता पहले कॉलम में एक कमांड को किस प्रकार निष्पादित कर सकते हैं। यह मान रूट पर सेट किया गया है, जिसका अर्थ है कि रूट को अंतिम कॉलम में निर्दिष्ट कमांड को रूट उपयोगकर्ता के रूप में निष्पादित करने की अनुमति होगी। यह मान सभी वाइल्डकार्ड पर भी सेट किया जा सकता है, जो सिस्टम पर किसी भी उपयोगकर्ता के रूप में कमांड को चलाने के लिए जॉर्ज को अनुमति देगा।

अंतिम मान (/ usr / bin / find, / bin / rm) एक अल्पविराम से अलग की गई कमांड है जिसे उपयोगकर्ता पहले कॉलम में तीसरे कॉलम में उपयोगकर्ता (एस) के रूप में चला सकता है। इस मामले में, हम जोर्ज को चलाने और rm को रूट के रूप में चलाने की अनुमति दे रहे हैं। यह मान सभी वाइल्डकार्ड के लिए भी सेट किया जा सकता है, जो सिस्टम के सभी कमांड को रूट के रूप में चलाने के लिए जॉर्ज को अनुमति देगा।

इसे ध्यान में रखते हुए, आप एक्स कमांड को कॉमा सीमांकित फैशन में अनुमति दे सकते हैं और जब तक आप इसे नहीं जोड़ते हैं तब passwdतक आपको ठीक होना चाहिए

Answer 16

कोई 1/2 रूट नहीं है :) एक बार जब आप रूट विशेषाधिकार देते हैं तो वे जो चाहें कर सकते हैं। वैकल्पिक रूप से आप sudo का उपयोग प्रतिबंधित बैश शेल चलाने के लिए कर सकते हैं या रूट विशेषाधिकार के बिना rbash चलाने के लिए कर सकते हैं ।

यदि आप सर्वर में रूट के रूप में लॉगिन करने के लिए एक विफल तंत्र चाहते हैं, तो आप या तो एक अन्य उपयोगकर्ता बना सकते हैं या uid=0एक साधारण क्रोन बना सकते हैं जो रूट पासवर्ड को समय-समय पर रीसेट करेगा।

Comments

प्रतिबंधित बैश से बचना आसान है, इस सेन्स ब्लॉग को

— फ्रैंकलिन पिअट

Answer 17

सुडो का उपयोग करने के बजाय एक पहिया समूह को जोड़ने का प्रयास करें। sudo एक उपयोगकर्ता को निष्पादित करने की अनुमति देता है जैसे कि वे जड़ हैं जिसका अर्थ है कि यह चलने से अलग नहीं है:

सु -

जड़ बनना जड़ uid = 0; पहिया uid = 10। लोग नामों का उपयोग करते हैं लेकिन ओएस यूआईडी का उपयोग करता है। पहिया समूह के सदस्य द्वारा कुछ आदेश नहीं चलाए जा सकते हैं। (यदि आप पहिया का उपयोग करते हैं तो पहिया समूह के सदस्य के रूप में रूट जोड़ने की गलती न करें)। अगर आप नहीं जानते कि Red Hat प्रलेखन पर ध्यान दें कि पहिया क्या है।

एक अन्य विकल्प पासवर्ड के बजाय ssh कुंजी का उपयोग करना है। यह मानते हुए कि आप यह सुनिश्चित कर सकते हैं कि sudo का उपयोग करने वाले लोग अपनी सार्वजनिक कुंजियों को ~ / .ssh / अधिकृतकी फ़ाइल में न जोड़ें, यह रूट पासवर्ड बदलने की किसी भी चिंता के आसपास हो जाता है क्योंकि रूट पासवर्ड को प्रभावी रूप से अनदेखा किया जाता है।

यदि आप इन उपयोगकर्ताओं पर विस्तृत विश्वास प्राप्त करना चाहते हैं (अपनी स्वयं की सार्वजनिक कुंजी नहीं जोड़ने के लिए) विस्तारित फ़ाइल विशेषताओं का उपयोग करके और अपरिवर्तनीय बिट का उपयोग करने का प्रयास करें। अपनी ~ / .ssh / प्राधिकृत फाइल बनाने के बाद, और / etc / ssh / sshd_config और / etc / ssh / ssh_config को अपनी इच्छानुसार कॉन्फ़िगर करने के बाद, Immutable बिट सेट करें। यकीन है, वहाँ भी उस के साथ पेंच करने के तरीके हैं - कुछ भी सही नहीं है।

किसी भी प्रणाली में, अंदरूनी सूत्रों को सबसे अधिक खतरा होता है। शो चलाने वाला व्यक्ति ढेर के शीर्ष पर है। एक संबंधित विचार अनुबंध से संबंधित है। वकील आपको बताएंगे, "कभी भी किसी ऐसे व्यक्ति के साथ व्यवसाय न करें, जिसे आपके साथ व्यापार करने के लिए अनुबंध की आवश्यकता है"। सामान्य ज्ञान हमें बताता है, "कभी भी अनुबंध के बिना व्यापार न करें"। जब आपको कोई ऐसा व्यक्ति मिल जाए जिस पर आप व्यापार करने के लिए पर्याप्त रूप से भरोसा करते हैं, तो एक-दूसरे की जरूरतों के आधार पर अनुबंध लिखें।

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

-जॉन क्राउट

Comments

sudoहै बेहद से अलग su -। इसे बार-बार इंगित किया गया है, उदाहरण के लिए SHW , जोसेफ आर। , खुद , hbdgaf और संभवतः संभवतः कई और टिप्पणी क्षेत्र भी शामिल करने के लिए बहुत कम हैं ...

— एक CVn

सभी सच, लेकिन अप्रासंगिक। आप रूट बनने के वैकल्पिक तरीकों और रूट एक्सेस देने के जोखिमों पर चर्चा कर रहे हैं, लेकिन ऐसा कुछ भी नहीं है जिसका "रूट एक्सेस पर कोई असर हो जो रूट पासवर्ड को बदल न सके"।

— गिलेस

सच। प्रश्न एक तार्किक ऑक्सीमोरन है; यह तब तक मौजूद नहीं हो सकता जब तक कि इंस्टॉलेशन टूट न जाए। उपयोगकर्ता लॉगिन / खाता कितना अच्छा है जहाँ वह उपयोगकर्ता अपना पासवर्ड नहीं बदल सकता है, फिर भी उसकी जड़ तक पहुँच है? इसलिए प्रस्तावित किए गए सुझाव लागू होते हैं कि प्रश्नकर्ता का क्या मतलब हो सकता है; सवाल लिखने के तरीके से नहीं। किसी भी एक्सेस कंट्रोल विधि में अंतर्निहित जोखिम होता है।

— जॉन क्राउट

Answer 18

एक तरीका यह सुनिश्चित करना होगा कि /etcयह योग्य नहीं है। किसी के द्वारा, जब तक sudoerआसपास कोई हो सकता है ।

इसे नेटवर्क पर बढ़ते हुए और दूसरी तरफ यह सुनिश्चित करने के द्वारा किया जा सकता है कि डिवाइस को लिखा नहीं जा सकता है।

यह एक स्थानीय उपकरण का उपयोग करके किया जा सकता है जो इसे लिखने की पहुंच को रोकता है। ( write blockerहार्डवेयर देखें)

महत्वपूर्ण हिस्सा यह है कि प्रतिबंध को उस मशीन की जड़ अवधारणा के बाहर लागू करना होगा। एक रचनात्मक हैकर आपको पर्यावरण पर नियंत्रण रखने वाले वातावरण में मौजूद सभी बाधाओं के आसपास अपना रास्ता खोज लेगा। इसलिए अगर रूट अपना पासवर्ड बदल सकता है, तो ए sudoer।

यह सुनिश्चित करने के लिए कि उपयोगकर्ता आपकी लॉगिन क्षमताओं को भी नहीं बढ़ा सकता है, आपके पास केवल-पढ़ने के लिए माउंटेड /binऔर है /sbin।

और आपके पास एक स्क्रिप्ट होनी चाहिए जो समय-समय पर नेटवर्क कनेक्शन को पुनर्स्थापित करती है।

(एक विचार के रूप में: यदि आप सूडोअर को केवल बहुत सीमित आदेशों के लिए अनुमति देते हैं और उनमें से प्रत्येक के लिए सुरक्षित है कि वे उनमें से तोड़ नहीं सकते हैं / उन्हें बदल सकते हैं आदि, तो आप इसे /etcलिखने से रोक सकते हैं ।

Comments

माउंटिंग / आदि केवल पढ़ने के लिए, जबकि शायद संभव हो (आपको initrd की बूट स्क्रिप्ट में पिवट-रूट के दौरान सावधान रहना होगा, उदाहरण के लिए), बल्कि एक नाजुक सेटअप होने का जोखिम चलाता है। इसके अलावा, कई चीजें हैं जो रूट एक्सेस के साथ एक उपयोगकर्ता कर सकते हैं जो अन्य उपयोगकर्ताओं की रूट विशेषाधिकार प्राप्त करने की क्षमता को अपंग कर देता है जिसमें / आदि में संशोधन करना शामिल नहीं है।

— एक CVn

@ MichaelKjörling सेटअप नाजुक नहीं है, मैं इसे अक्सर उपयोग करता हूं (जैसा कि केवल-पढ़ने के लिए स्थानीय माउंट)।

— एंजेलो फुच्स

@ माइकलकॉर्जिंग मैंने कुछ अन्य तत्व जोड़े हैं जिन्हें आप केवल पढ़ना चाहते हैं-यदि आप यह सुनिश्चित करना चाहते हैं कि आप अभी भी लॉग इन कर सकते हैं। तो, यदि आप उस सड़क से नीचे जाते हैं तो आपको जिन कार्यों को करना है, उनकी सूची इतनी कम नहीं है, लेकिन इसका एकमात्र तरीका यह है कि "एक गारंटी है कि हम अभी भी उस सर्वर पर लॉगिन कर सकते हैं और इस बात की जड़ बन सकते हैं कि अन्य उपयोगकर्ता क्या करेंगे।"

— एंजेलो फुच्स

मैं मानता हूँ कि मैंने कभी इसे आज़माने की ज़रूरत नहीं देखी है, लेकिन एक चीज़ मैं निश्चित रूप से देख सकता हूँ कि यह जोखिम भरा होगा कि कैसे init को संभालना है / etc / initab को उसके पैरों के नीचे प्रतिस्थापित किया जा रहा है। या यदि प्रारंभिक और बाद के रिमाउंटिंग / आदि / fstab अलग हैं तो सिस्टम क्या करेगा। और वहाँ / etc / mtab है। अन्य उपयोगकर्ता अपने स्वयं के पासवर्ड को बदलना चाह सकते हैं, जिसमें / etc / shadow और संभवतः / etc / passwd लिखना शामिल है। और बढ़ते / पढ़ते-पढ़ते केवल अभी भी केवल एक आंशिक समाधान है। मैं यह नहीं कह रहा हूं कि यह एक समाधान का हिस्सा नहीं हो सकता है, लेकिन यह निश्चित रूप से ओपी की स्थिति में पहला कदम नहीं है।

— एक CVn 12

हाँ। ऐसा करना खतरनाक है और गलत काम करने पर गंभीर समस्याएं होती हैं। फिर भी जहां तक ​​मैं इसका एकमात्र व्यवहार्य तरीका देख सकता हूं कि उन उपयोगकर्ताओं के लिए ओपी अनुरोध को हल किया जा सकता है जिन्हें रूट बनने की अनुमति दी जानी चाहिए।

— एंजेलो फुच्स