मिथक या वास्तविकता: SELinux रूट उपयोगकर्ता को परिभाषित कर सकती है?


20

मैंने कहीं पढ़ा या सुना (शायद LinuxCBT के SELinux पाठ्यक्रम में ; लेकिन मुझे यकीन नहीं है) कि ऑनलाइन लिनक्स सर्वर हैं, जिसके लिए रूट उपयोगकर्ता का पासवर्ड भी दिया गया है। लिनक्स सर्वर को SELinux नियमों का उपयोग करके कठोर किया जाता है, जैसे कि हर कोई रूट उपयोगकर्ता के साथ लॉगिन कर सकता है, लेकिन OS को कोई नुकसान नहीं पहुंचा सकता।

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

इस तरह के एक लिनक्स बॉक्स एक हनीपोट के निर्माण के लिए एक शानदार शुरुआती बिंदु होगा ।

संपादित करें: एक जवाब (अब हटाए गए), और थोड़ा Googling के आधार पर, मुझे कम से कम दो लिंक मिले, जो इस तरह के कठोर लिनक्स सर्वरों की ओर इशारा करते थे। दुर्भाग्य से, दोनों सर्वर डाउन हैं। रिकॉर्ड के लिए, मैं यहां दिए गए विवरणों को कॉपी-पेस्ट करूंगा:

1) http://www.coker.com.au/selinux/play.html से :

एसई लिनक्स मशीन पर मुफ्त रूट एक्सेस!

रूट के रूप में play.coker.com.au को मेरी डेबियन प्ले मशीन ssh एक्सेस करने के लिए , पासवर्ड है ...

ध्यान दें कि ऐसी मशीनों को बहुत कौशल की आवश्यकता होती है यदि आप उन्हें सफलतापूर्वक चलाने के लिए हैं। यदि आपको पूछना है कि क्या आपको एक चलना चाहिए तो उत्तर "नहीं" है।

इसका उद्देश्य यह प्रदर्शित करना है कि सभी आवश्यक सुरक्षा एसई लिनक्स द्वारा बिना किसी यूनिक्स अनुमतियों के प्रदान की जा सकती है (हालांकि यह अभी भी अनुशंसित है कि आप यूनिक्स अनुमतियों के साथ-साथ वास्तविक सर्वर का भी उपयोग करें)। इसके अलावा यह आपको एसई मशीन में प्रवेश करने का मौका देता है और देख सकता है कि यह कैसा है।

आपको लगता है कि आप का उपयोग सुनिश्चित करें कि एक एसई लिनक्स खेलने मशीन बनाने के लिए के लिए लॉग इन जब -x अक्षम X11 अग्रेषण करने का विकल्प या सेट ForwardX11 अपने / etc / ssh / ssh_config फ़ाइल में कोई इससे पहले कि आप लॉग इन करें। यह भी सुनिश्चित करें कि आप ssh एजेंट को अक्षम करने के लिए -a विकल्प का उपयोग करते हैं या लॉगिन करने से पहले अपने / etc / ssh / ssh_config फ़ाइल में ForwardAgent को सेट नहीं करते हैं। यदि आप इन सेटिंग्स को सही ढंग से अक्षम नहीं करते हैं, तो प्ले मशीन में लॉग इन करने से आपको अपने एसएसएच क्लाइंट के माध्यम से हमला होने का खतरा होगा।

इस पर चर्चा करने के लिए एक IRC चैनल है, यह irc.freenode.net पर #selinux है ।

यहाँ एक त्वरित पूछे जाने वाले प्रश्न है

2) http://www.osnews.com/comments/3731 से

कठोर Gentoo का उद्देश्य उच्च सुरक्षा, उच्च स्थिरता उत्पादन सर्वर वातावरण के लिए Gentoo को व्यवहार्य बनाना है। यह परियोजना एक स्टैंडअलोन परियोजना नहीं है जो कि गेंटू से उचित रूप से जुड़ी हुई है; यह Gentoo डेवलपर्स की एक टीम होने का इरादा है जो Gentoo के समाधान देने पर केंद्रित है जो मजबूत सुरक्षा और स्थिरता प्रदान करते हैं। यह मशीन हार्डेंट जेंटू की सिलेन्क्स डेमो मशीन है । इसका प्राथमिक उपयोग SELinux एकीकरण, और नीति का परीक्षण और ऑडिट करना है।


2
यहाँ भी दावा किया गया है । हालांकि यह निश्चित रूप से संभव है, यह मेरे लिए कठिन लगता है (जब तक कि आप उस रूट उपयोगकर्ता को इतना सीमित नहीं करते कि वह कुछ भी उपयोगी नहीं कर सकता)। SELinux नियम लिखना जो वास्तव में आप जो करने के लिए निर्धारित करते हैं वह सबसे अच्छे मामलों में मुश्किल है।
गाइल्स का SO- बुराई पर रोक '22

4
हाल के कर्नेल के साथ, गैर-रूट उपयोगकर्ता ऐसे नामस्थान बना सकते हैं, जहां उनके पास UID 0. है। चूंकि वे toplevel नामस्थान में UID 0 नहीं हैं, इसलिए वे सिस्टम को नुकसान नहीं पहुंचा सकते। वे आंतरिक रूप से नुकसान के लिए कोई अवसर नहीं प्राप्त करते हैं, SELinux दृष्टिकोण के विपरीत जहां ऐसे सभी अवसरों को दूर करना होता है। कर्नेल देखें : नेपरस्पेस समर्थन , और सेपरेट ऑपरेटिंग सिस्टम स्थापित किए बिना दो खातों को पूरी तरह से अलग करें?
गाइल्स का SO- बुराई पर रोक '22

आपके ग्राफिक्स ड्राइवर पर निर्भर करता है कि यह वास्तव में सुरक्षित है या नहीं।
जोशुआ

जवाबों:


17

वास्तविकता: हाँ, SELinux रूट उपयोगकर्ता को परिभाषित कर सकता है।

यह संभव है क्योंकि SELinux वास्तव में वर्तमान यूनिक्स उपयोगकर्ता के बारे में परवाह नहीं करता है: यह सब देखता है कि एक पूरक मेटाडेटा है जिसे संदर्भ कहा जाता है (जिसमें अन्य फ़ील्ड्स, एक डोमेन फ़ील्ड शामिल है) और जो SELinux निर्णय लेने की क्रिया को अधिकृत कर सकता है या नहीं। नहीं।

रूट यूजर के रूप में आमतौर पर कोई क्या कल्पना करता है कि SELinux में रूट यूनिक्स उपयोगकर्ता unconfined_tया sysadm_tSELinux डोमेन के रूप में मैप किया जाएगा । यह शास्त्रीय पूर्ण-संचालित सर्वव्यापी रूट उपयोगकर्ता है।

हालाँकि, कोई अपने सिस्टम को रूट शेल (I मतलब रूट यूनिक्स यूजर शेल) को प्रतिबंधित करने के लिए पूरी तरह से सेटअप कर सकता है user_t। SELinux नीतियों के अनुसार, ऐसा शेल किसी भी अन्य प्रतिबंधित उपयोगकर्ता के शेल से अलग नहीं होगा और सिस्टम पर कोई विशेष विशेषाधिकार नहीं होगा, इस प्रकार रूट उपयोगकर्ता को प्रभावी ढंग से परिभाषित करेगा।

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

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

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


1

हाँ, यह मुमकिन है। लेकिन बहुत उपयोगी नहीं है।

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


सबसे पहले, मैं उतना ही निराशावादी था जितना आप हैं। लेकिन, अधिक ज्ञान प्राप्त करने के बाद, ऐसा लगता है कि "किसी भी क्रिया को करने से रूट उपयोगकर्ता को हटाने की कोई आवश्यकता नहीं है।" मेरे संपादित उत्तर की जाँच करें, जिसमें लिंक और जानकारी शामिल हैं, जो प्रमाण-अवधारणाओं के लिए हैं। दुर्भाग्य से, वे अब उपलब्ध नहीं हैं; लेकिन ऐसा लगता है कि कार्यान्वयन गंभीर रूप से प्रतिबंधित नहीं थे।
एमएस डौस्टी

-5

क्या लिनक्स बॉक्स (संभवतः SELinux के साथ) को सख्त करना संभव है, यहां तक ​​कि रूट उपयोगकर्ता भी उस पर विशिष्ट दुर्भावनापूर्ण गतिविधियां नहीं कर सकता है?

यह सस्ता लग सकता है, लेकिन यह आसान है: उपयोगकर्ता रूट के यूआईडी को गैर-शून्य में बदल दें। बस / etc / passwd और / etc / छाया में जाएं, मौजूदा uid = 0 प्रविष्टियों को "रूट" से कुछ और में बदलें, और फिर "root" नाम का एक खाता जोड़ें, जिसका uid शून्य और अप्रयुक्त नहीं है।

यह बिना उद्देश्य को प्राप्त करता है। यह दावा करने का एक तरीका भी है कि किसी को वास्तव में बढ़े हुए विशेषाधिकार प्रदान किए बिना "रूट एक्सेस" हो सकता है।


3
ठीक है, लेकिन तब rootउपयोगकर्ता वास्तव में मूल उपयोगकर्ता नहीं होता है। सवाल पूछ रहा है कि क्या वास्तविक सुपर उपयोगकर्ता को इस तरह से सीमित किया जा सकता है।
terdon

खतरनाक लगता है - इसके अलावा आप यूआईडी 0 के साथ एक और खाता बनाएं। लेकिन यह रूट का नाम बदलने और "रूट" नाम का पुन: उपयोग करने के समान होगा।
वोल्कर सेगेल

प्रश्न केवल "रूट" को संदर्भित करता है जो जरूरी नहीं कि सुपर-उपयोगकर्ता के बराबर है, अर्थात, यूआईडी = 0। दुर्लभ अवसरों पर, यह एक उपयोगी अंतर है।
ओथियस

2
फिर भी, संदर्भ यह स्पष्ट करता है कि ओपी पूछ रहा है कि क्या सुपर उपयोगकर्ता है, न कि कुछ यादृच्छिक उपयोगकर्ता जिनके उपयोगकर्ता नाम को rootइस तरह से सीमित किया जा सकता है।
terdon

1
ठीक। कम से कम, कृपया अपना उत्तर संपादित करें और बताएं कि आप जो सुझाव देते हैं वह कैसे हासिल किया जा सकता है। यह अपनी लंबाई के कारण निम्न गुणवत्ता के रूप में ध्वजांकित होता रहता है। इसलिए इसमें गिरावट आ रही है।
terdon
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.