कौन-से पहुँच अधिकार सुपरयुजर का उल्लंघन नहीं कर सकते?

23

फादर बीआर। जॉर्ज ने अपने एक व्याख्यान (यह रूसी में है) में बताया कि कुछ एक्सेस अधिकार हैं जो सुपरयुसर उल्लंघन नहीं कर सकते हैं। यह सही है, जो सुपरसुसर को कुछ करने से मना कर सकता है।

मुझे यह जानकारी इंटरनेट पर नहीं मिल पा रही थी और मैं उत्सुक हूं कि वे क्या हैं। यह शायद सिस्टम के मूल निष्पादन से संबंधित कुछ है, है ना? शायद वह कुछ सिस्टम प्रक्रियाओं को रोक नहीं सकता है? या शायद वह वास्तविक मोड में एक प्रक्रिया नहीं चला सकता है?

यह सवाल SELinux से संबंधित नहीं है (जॉर्ज सवाल के ठीक पहले इसके बारे में बात कर रहा था)।

root privileges access-control

— Kolyunya
स्रोत

2

एक "विशेषाधिकार" या "अनुमति" कुछ करने का अधिकार है, एक अधिकार जो विशिष्ट उपयोगकर्ता खातों को दिया जा सकता है। UNIX और Linux में (SELinux जैसे कठोर संस्करणों को छोड़कर), रूट के पास सभी अधिकार हैं। ऐसा कोई अधिकार नहीं है जिसे दिया जा सके root, और इसलिए ऐसा कोई अधिकार नहीं जिसे छीन लिया जा सके root।

— 14

1

@ दलाल, क्षमा करें? एक निश्चित रूप से UID 0 रख सकता है जबकि अभी भी प्रक्रिया क्षमताओं को रद्द कर रहा है।

— चार्ल्स डफी

... सेट किया SECBIT_NOROOTजा रहा है, और uid 0 अब एक क्षमताओं को स्वचालित रूप से अनुदान नहीं देता है।

— चार्ल्स डफी

इतने सारे उत्तर - क्या इसे सामुदायिक विकि में बदलने का कोई मतलब होगा, या किसी को सारांश उत्तर लिखना चाहिए?

— साइमन रिक्टर

1

@SimonRichter मैं जॉर्ज के रूप में हमें यह बताने जा रहा हूं कि उनके व्याख्यान में उनका क्या मतलब था।

— कोलुन्य्या

24

acess जड़ से इनकार :

rootप्रत्यक्ष नेटवर्क पहुंच से वंचित किया जा सकता है। यह इंटरनेट से जुड़ा होस्ट पर उपयोगी है के रूप में यह आवश्यक है कि आप के रूप में प्रवेश smithकरें, तो sudo।

कुछ सामान रूट नहीं कर सकते :

यह विशेषाधिकार की कमी के लिए नहीं है। मैं देख नहीं सकता कि कुछ भी नहीं कर सकता है, हालांकि कुछ तकनीकी मुद्दों को "निषिद्ध" के रूप में अनुभव किया जा सकता है।

मैं जड़ हूं, मैं इस फाइल को क्यों नहीं बना / हटा सकता, जबकि साधारण उपयोगकर्ता कर सकता है?

आप एक NFS / सांबा शेयर पर हैं, और आप विशिष्ट ( access=) प्राधिकरण नहीं दे रहे थे । साधारण उपयोगकर्ता सामान्य कानून में विफल रहता है। (स्थानीय बनाम दूरस्थ रूट नीचे देखें)

मैं जड़ हूँ, मैं इस प्रक्रिया को क्यों नहीं मार सकता?

एक लंबित I / O है और भौतिक ड्राइव / रिमोट LUN काट दिया गया है, प्रक्रिया को केवल रिबूट द्वारा मारा जा सकता है।

मैं रूट हूं, मुझे आर्कमियर का पासवर्ड कैसे मिलेगा?

आप su - archemarपिछले एक को जाने बिना आर्कमेयर के पासवर्ड को सही कर सकते हैं या बदल सकते हैं, लेकिन आप इसे (एक कुंजी लकड़हारा की कमी) नहीं पढ़ सकते हैं, क्योंकि पासवर्ड एक-तरफ़ा हैश का उपयोग करके संग्रहीत किए जाते हैं।

स्थानीय बनाम दूरस्थ जड़

आप अपने स्टेशन / पीसी पर रूट कर सकते हैं, और एक कंपनी / कॉलेज / विश्वविद्यालय / प्रदाता एनएफएस शेयर का उपयोग कर सकते हैं।
अगला आपके पास NFS निर्यात करने वाले कंप्यूटर पर केवल एक गैर-रूट लॉगिन हो सकता है।

अभी व

cp /bin/bash /nfs/home/me/bash
chown root /nfs/home/me/bash
chmod u+s /nfs/home/me/bash

बस एनएफएस सर्वर पर लॉग इन करें, भागो ./bashऔर आप कंपनी / विश्वविद्यालय सर्वर पर रूट हैं।

— Archemar
स्रोत

केस 1 मूल रूप से एक त्रुटि है क्योंकि आप केवल rootस्थानीय रूप से हैं, जरूरी नहीं कि अन्य प्रणालियों पर। केस 2 और 3 विशेषाधिकार नहीं हैं (वे किसी को भी नहीं दिए जा सकते)। तो +1, आपका पहला वाक्य सही प्रतीत होता है।

— 13

तकनीकी रूप से, rootस्थानीय मशीन पर कुछ भी ऐसा कर सकता है जो स्थानीय उपयोगकर्ता के समान विशेषाधिकार के साथ, su - usernameयदि कुछ और नहीं है। मुझे यकीन नहीं है कि उन्होंने इस rootतरह से नेटवर्क शेयर लिखने में असमर्थता क्यों जताई ; यह व्यर्थ लगता है।

— टॉम हंट

4

यह उम्र का पुराना सवाल है " rootएक पासवर्ड बना सकते हैं यहां तक कि वह एक्सेस नहीं कर सकता है?"

— corsiKa

5

@TomHunt, rootएनएफएस शेयरों को एक्सेस न देने के कारणों में से एक है, रिमोट सर्वर पर "suid root" बायनेरिज़ के निर्माण को रोकना, कुछ ऐसा जिसे सर्वर के पूर्ण रिमोट एक्सेस में बदला जा सकता है।

— मार्क

1

निर्बाध प्रतीक्षा में एक प्रक्रिया को मारना मेरे लिए एक अधिकार की तरह नहीं लगता है। यह ऐसा कुछ है जो आप अभी नहीं कर सकते। एक पूर्ण फाइलसिस्टम के लिए लेखन की तरह।

— ब्लैकलाइट शाइनिंग

11

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

(1) - अगर कोई सिस्टम किसी दिए गए फीचर को प्रदान नहीं करता है, जैसे कि कोई वास्तविक समय कर्नेल कार्यक्षमता नहीं है, तो मैं इस कथन पर विचार कर रहा हूं कि "जड़ की इस कार्यक्षमता तक पहुंच नहीं है" गलत है, क्योंकि यह कथन एक पर निर्भर करता है गलत धारणा (अर्थात दी गई सुविधा उस सिस्टम पर किसी के लिए भी उपलब्ध है)

— जॉन
स्रोत

1

आपके उत्तर के लिए धन्यवाद, जॉन! लेकिन उन्होंने स्पष्ट रूप से कहा कि यह प्रश्न SELinux से संबंधित नहीं है ...

— Kolyunya

फिर आगे के विवरणों को छोड़कर, मैं इस कथन पर विचार करने जा रहा हूं कि रूट की निश्चित कार्यक्षमता तक पहुंच नहीं है। (मैं BIOS के लॉक होने या BIOS सुरक्षा द्वारा समान होने के मामले पर विचार नहीं कर रहा हूं।)

— जॉन

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

— doneal24

2

जरूरी नहीं कि सच हो। इसके CAP_NET_ADMIN को हटा दें, और uid 0 होने के बावजूद अभी भी एक प्रक्रिया को नेटवर्क कॉन्फ़िगरेशन को बदलने नहीं देता है। (इसी तरह CAP_SYS_ADMIN और इसे नियंत्रित करने की क्षमता आदि के लिए)।

— चार्ल्स डफी

5

एक तरफ, ऐसी चीजें हैं जो कोई उपयोगकर्ता नहीं कर सकता है, जैसे कि

हार्ड-लिंकिंग निर्देशिका (फ़ाइल सिस्टम सीमाओं के कारण)
पहले से ही जले हुए CD-ROM पर लिखना (क्योंकि भौतिकी)

लेकिन वे विशेषाधिकार नहीं हैं, क्योंकि उन्हें प्रदान नहीं किया जा सकता है, वे किसी के लिए भी संभव नहीं हैं।

फिर पूरे सिस्टम या इसके कुछ हिस्सों के लिए प्रतिबंध हैं जिन्हें चालू या बंद किया जा सकता है।
उदाहरण के लिए, OS X पर केवल Apple द्वारा हस्ताक्षरित किए जाने पर कोड को चलाने की अनुमति देने का विकल्प है।

मैं इसे वास्तविक विशेषाधिकार नहीं मानता, क्योंकि सुपरयूजर नहीं कर सकता तो कोई भी उपयोगकर्ता इसे नहीं ले सकता। आप केवल विश्व स्तर पर इसे अक्षम कर सकते हैं।

संपादित करें:
निष्पादन योग्य बिट के बिना किसी फ़ाइल का आपका विचार भी इस श्रेणी में आएगा, क्योंकि शाब्दिक रूप से कोई भी ऐसा करने में सक्षम नहीं है, और कोई भी उस अनुमति को प्राप्त नहीं किया जा सकता है।
और यहां तक कि किसी अन्य उपयोगकर्ता या समूह को उस फ़ाइल को निष्पादित करने की अनुमति देते समय, लेकिन रूट या उपयोगकर्ता समूह रूट नहीं है, रूट अभी भी उस फ़ाइल को निष्पादित करने में सक्षम होगा (ओएस एक्स 10.10, 10.11 और Ubuntu 15.04 सर्वर पर परीक्षण किया गया)।

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

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

सिस्टम हैं, हालांकि, (आईओएस की तरह) जहां यह (मनमाने ढंग से) संभव नहीं है, कम से कम सुरक्षा पूर्ण दोहन के बिना नहीं। यह ज्यादातर बढ़ी हुई सुरक्षा के कारण होता है, जैसे कोड हस्ताक्षर प्रवर्तन।
उदाहरण के लिए, iDevices के प्रोसेसर में निर्मित एईएस एन्क्रिप्शन कुंजी हैं , जिन्हें केवल कर्नेल मोड से एक्सेस किया जा सकता है। कर्नेल मॉड्यूल सकता है उन तक पहुँचने, लेकिन उन कर्नेल मॉड्यूल में कोड भी गिरी उन्हें स्वीकार करने के लिए आदेश में एप्पल द्वारा हस्ताक्षर किए जाने के लिए होगा।

ओएस एक्स पर, संस्करण 10.11 (एल कैपिटन) के बाद से एक तथाकथित "रूटलेस मोड" भी है (हालांकि नाम भ्रामक है क्योंकि रूट अभी भी मौजूद है), जो प्रभावी रूप से रूट कुछ चीजों को मना करता है जो इंस्टॉलर अभी भी कर सकते हैं।
से हवाला देते हुए AskDifferent पर इस उत्कृष्ट जवाब :

यहां बताया गया है कि यह रूट से भी प्रतिबंधित है:

आप कुछ भी / सिस्टम, / बिन, / sbin, या usr (छोड़कर / usr / स्थानीय) में संशोधित नहीं कर सकते हैं; या किसी भी अंतर्निहित एप्लिकेशन और उपयोगिताओं। केवल इंस्टॉलर और सॉफ़्टवेयर अपडेट इन क्षेत्रों को संशोधित कर सकते हैं, और यहां तक कि वे केवल ऐप्पल-हस्ताक्षरित पैकेजों को स्थापित करते समय ही करते हैं।

— Siguza
स्रोत

1

वास्तव में, आप निष्पादन योग्य बिट्स सेट किए बिना एक निष्पादन योग्य चला सकते हैं: gcc -o hello hello.c && chmod 400 hello && /lib64/ld-linux-x86-64.so.2 ./helloअपेक्षित Hello, World!आउटपुट देता है ,

— doneal24

@ डगओल, लेकिन /lib64/ld-linux-x86-64.so.2तब वास्तविक निष्पादन योग्य नहीं है, और ./helloसिर्फ एक तर्क है? क्योंकि यह एक पाठ फ़ाइल को PHP दुभाषिया के लिए PHP कोड से युक्त है ... या उपयोग करके एक बैश स्क्रिप्ट को चलाने की तरह bash ./my_script...

— सिगुजा

1

@ डगओनील जो काम करता था, लेकिन ग्लिबक के हाल के संस्करणों में अक्षम था (इसे नोक्सेक माउंट्स के एक तुच्छ बायपास होने से रोकने के लिए)।

— डस्कवफ

@duskwuff हाल ही में ग्लिब का एक संस्करण कैसे? यह अभी भी Ubuntu 14.04 के तहत काम करता है।

— doneal24

1

Apple ने इसे ln में नहीं जोड़ा, लेकिन सिस्टम वर्ग, जो ln का उपयोग करता है, जैसे कि लिंक इस लिंक को देखने की अनुमति देता है stackoverflow.com/a/4707231/151019 इस तरह से टाइम मशीन काम करती है

— user151019

4

"सिस्टम कोर निष्पादन" जिसका आप उल्लेख कर रहे हैं, rootलोडेबल कर्नेल मॉड्यूल के माध्यम से उदाहरण के लिए अच्छी तरह से नियंत्रण में है। बेशक, यह मानता है कि कर्नेल मॉड्यूल को लोड करना कर्नेल द्वारा समर्थित है, कोई भी ऐसी क्रियाएं नहीं कर सकता जो व्यवहार्य नहीं हैं, यहां तक कि root।

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

अंत में, वास्तविक मोड: लिनक्स कर्नेल के पास इसके लिए कोई समर्थन नहीं है, इसलिए फिर से, कोई भी इन्फैटेबल नहीं कर सकता है, यहां तक कि नहीं root।

@ सिगुजा ने xअनुमति के बिना फाइलों के निष्पादन का उल्लेख किया , जो rootउपयोगकर्ता के लिए काफी संभव है :

/lib/ld-linux.so.2 /path/to/executable

— दिमित्री ग्रिगोरीव
स्रोत

... लेकिन एक uid-0 प्रक्रिया नए कर्नेल मॉड्यूल को लोड करने की क्षमता खो सकती है (या उन्हें हॉटपैच कर सकती है /proc/kmem) क्षमता निरसन के माध्यम से।

— चार्ल्स डफी

4

एक उदाहरण अपरिवर्तनीय फ़ाइल को संशोधित किया जा सकता है: आप एक फ़ाइल गुण सेट कर सकते हैं iके साथ chattrभी है कि जड़ के लिए फ़ाइल अपरिवर्तनीय बना देता है। उदाहरण के लिए:

# whoami
root
# touch god
# chattr +i god
# rm god
rm: cannot remove ‘god’: Operation not permitted
# touch god
touch: cannot touch ‘god’: Permission denied

ध्यान दें कि फ़ाइल ls -lआउटपुट में सामान्य लिखने योग्य फ़ाइल के रूप में दिखाई देती है :

# ls -l god
-rw-r--r-- 1 root root 0 Oct 26 19:27 god

iविशेषता देखने के लिए, आपको उपयोग करना होगा lsattr:

# lsattr god
----i----------- god

Chattr के मैनुअल पृष्ठ के बारे में निम्नलिखित राज्यों iविशेषता:

`I 'विशेषता वाली फ़ाइल को संशोधित नहीं किया जा सकता है: इसे हटाया या नाम बदला नहीं जा सकता है, इस फ़ाइल का कोई लिंक नहीं बनाया जा सकता है और फ़ाइल में कोई डेटा नहीं लिखा जा सकता है। केवल कैप्युसर या CAP_LINUX_IMMUTUT की क्षमता वाली एक प्रक्रिया इस विशेषता को निर्धारित या साफ़ कर सकती है।

हालांकि, रूट आसानी से अपरिवर्तनीयता को पूर्ववत कर सकता है:

# chattr -i god
# rm -v god
removed ‘god’

— टॉमस
स्रोत

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

— साइमन रिक्टर

2

FreeBSD पर, आप gmirrorरूट के रूप में पहले से ही माउंट किए गए विभाजन पर उपयोग नहीं कर सकते :

gmirror लेबल -v -b पसंद gm0s1 ad4s1
gmirror: ad4s1 पर मेटाडेटा संग्रहीत नहीं कर सकता: ऑपरेशन की अनुमति नहीं है।

आपको इसे करने में सक्षम होने के लिए sysctl( kern.geom.debugflags=16) सेट करना होगा।

rootएक विशेषाधिकार प्राप्त उपयोगकर्ता है, लेकिन ये अधिकार कर्नेल द्वारा दिए गए हैं। इसलिए कर्नेल की तुलना में अधिक विशेषाधिकार मिले हैं root।

— Vinz
स्रोत

1

मूल उपयोगकर्ता से सहयोग को मानते हुए, rootFUSE आरोह ( allow_otherया allow_rootविकल्पों के साथ) तक पहुँचने से रोका जा सकता है , लेकिन ऐसा इसलिए है क्योंकि FUSE को इस तरह से कार्य करने के लिए डिज़ाइन किया गया था। चूंकि FUSE एक आभासी परत पर रहता है, यह तर्क के आधार पर पसंद की गई किसी भी त्रुटि को वापस कर सकता है, जैसा कि सामान्य ब्लॉक डिवाइस मॉड्यूल के विपरीत है जो किसी अन्य परत को अनुमतियों को सौंपते हुए जितना संभव हो उतना पारदर्शी और पतला होने का प्रयास करता है।

यह रूट उपयोगकर्ता को विकल्प को अक्षम करने से रोकता नहीं है, या FUSE मॉड्यूल को एक के साथ प्रतिस्थापित करता है जो चुपचाप विकल्प को छोड़ देता है, जब तक कि आप फाइल सिस्टम को केवल पढ़ने के लिए नहीं बनाते हैं। हालांकि, यह केवल एक "जो पहरेदार देखता है" स्थिति की ओर जाता है: आप यह कैसे मान्य कर सकते हैं कि सिस्टम झूठ नहीं बोल रहा है? हो सकता है कि आपका खोल भी एक चौराहे पर बैठा हो, जो आपको एक वैध FUSE मॉड्यूल दिखाता है, जबकि कर्नेल वास्तव में इसका एक पुरुषवादी संस्करण चला रहा है।

— sleblanc
स्रोत

0

मैं कहूंगा कि गैर-निष्पादन योग्य फ़ाइलों को निष्पादित करने में असमर्थता तुच्छ रूप से एक सीमा है, क्योंकि यह फ़ाइल अनुमतियों पर निर्भर करता है। (यह संभव है कि कोई भी फ़ाइल न करने योग्य फ़ाइल के लिए /lib64/ld-linux-x86-64.so.2 का उपयोग करके इसे प्राप्त किया जा सकता है, लेकिन फ़ाइल को नो-एक्ज़क्यूट माउंट पर नहीं)

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

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

अन्य सीमाएँ हैं:

अपरिवर्तनीय फ़ाइलों को संशोधित नहीं कर सकते हैं, और केवल परिशिष्ट-केवल फ़ाइलों को संलग्न कर सकते हैं (linux सुपर उपयोगकर्ता को अपरिवर्तनीय को हटाने और किसी भी रन-स्तर पर केवल झंडे को जोड़ने की अनुमति देता है, हालांकि, आंशिक रूप से उनके उद्देश्य को हरा सकता है)

केवल-पढ़ने के लिए माउंट नहीं लिख सकते हैं, या नहीं-निष्पादित माउंट पर कुछ भी निष्पादित कर सकते हैं

एक अविश्वसनीय माउंट बाँध नहीं सकता

फ़ाइल सिस्टम को रीड-राइट के रूप में रिमूव नहीं किया जा सकता है यदि उसका ब्लॉक डिवाइस केवल पढ़ने के लिए है

किसी अन्य उपयोगकर्ता के स्वामित्व वाले फ़्यूज़ माउंट पर तब तक कुछ भी अंकित नहीं किया जा सकता, जब तक कि वह अनुमति-अन्य या अनुमति-रूट पर न चढ़ा हो

SELinux सेटिंग का उल्लंघन नहीं किया जा सकता है

सिस्टम में निहित जानबूझकर सीमाएं, जो रूट को प्रभावित करती हैं:

फ़ाइल के सी-टाइम (या जन्म के समय, यदि यह कभी लागू हो) को सीधे सेट नहीं किया जा सकता

सादा पाठ के रूप में पासवर्ड नहीं देख सकते हैं

— दूसरा आदमी
स्रोत