👩🏼‍🍳 📅 📲 लिनक्स नेमस्पेस में गहरा गोता लगाएं, भाग 2 🔇 🐤 🦉

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

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

लिनक्स पर, ये आईडी केवल पूर्णांक हैं जो सिस्टम में उपयोगकर्ताओं और समूहों की पहचान करते हैं। और उनमें से कुछ को प्रत्येक प्रक्रिया को निर्धारित करने के लिए सौंपा गया है, जो इस प्रक्रिया को संचालित / संसाधन कर सकते हैं और उन तक पहुँच प्राप्त नहीं कर सकते हैं। किसी प्रक्रिया को नुकसान पहुंचाने की क्षमता निर्धारित आईडी से जुड़ी अनुमतियों पर निर्भर करती है।

उपयोगकर्ता नामस्थान

हम केवल उपयोगकर्ता आईडी का उपयोग करके उपयोगकर्ता नामस्थान की क्षमताओं का वर्णन करेंगे। सटीक रूप से वही कार्य समूह आईडी पर लागू होते हैं, जिन्हें हम इस पोस्ट में बाद में संबोधित करेंगे।

उपयोगकर्ता नामस्थान में उपयोगकर्ता और समूह पहचानकर्ताओं की अपनी प्रति है। फिर अलगाव आपको उपयोगकर्ता नामस्थान के आधार पर आईडी के एक और सेट के साथ प्रक्रिया को संबद्ध करने की अनुमति देता है, जो वर्तमान में है। उदाहरण के लिए, $pid प्रक्रिया उपयोगकर्ता नाम स्थान P में root (UID 0) से चल सकती है और किसी अन्य उपयोगकर्ता नाम स्थान Q पर स्विच करने के बाद अचानक proxy (UID 13) से चलती रहती है ।

उपयोगकर्ता रिक्त स्थान हो सकता है! इसका मतलब यह है कि एक कस्टम नेमस्पेस (माता-पिता) के एक उदाहरण में शून्य या अधिक चाइल्ड नेमस्पेस हो सकते हैं, और प्रत्येक बच्चे के नामस्थान, अपने बच्चे के नामस्थान और इतने पर हो सकते हैं ... (32 घोंसले के स्तर की सीमा तक पहुंचने तक)। जब एक नया नाम स्थान C बनाया जाता है, तो Linux उस प्रक्रिया P के वर्तमान उपयोगकर्ता नाम स्थान C को C के लिए जनक बनाता है और इसे बाद में परिवर्तित नहीं किया जा सकता है। नतीजतन, सभी उपयोगकर्ता नामस्थानों में एक ही माता-पिता होते हैं, जो नामस्थानों की एक पेड़ जैसी संरचना बनाते हैं। और, पेड़ों के मामले में, इस नियम का एक अपवाद सबसे ऊपर है, जहां हमारे पास मूल (या प्रारंभिक, डिफ़ॉल्ट) नाम स्थान है। यह, यदि आप पहले से ही किसी प्रकार का कंटेनर मैजिक नहीं कर रहे हैं, तो सबसे अधिक संभावना है कि उपयोगकर्ता नेमस्पेस, जिसमें आपकी सभी प्रक्रियाएं हों, क्योंकि सिस्टम शुरू होने के बाद से यह एकमात्र यूजर नेमस्पेस है।

इस पोस्ट में, हम उस शेल को इंगित करने के लिए कमांड प्रॉम्प्ट P $ और C $ का उपयोग करेंगे जो वर्तमान में मूल P और चाइल्ड C यूजर नेमस्पेस में चल रहा है।

उपयोगकर्ता आईडी मैपिंग

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

 P$ whoami iffy P$ id uid=1000(iffy) gid=1000(iffy)

एक अन्य टर्मिनल विंडो में, आइए खोल को unshare शुरू unshare ( -U ध्वज नए उपयोगकर्ता नामस्थान में एक प्रक्रिया बनाता है):

 P$ whoami iffy P$ unshare -U bash #    ,     user namespace C$ whoami nobody C$ id uid=65534(nobody) gid=65534(nogroup) C$ ls -l my_file -rw-r--r-- 1 nobody nogroup 0 May 18 16:00 my_file

एक मिनट रुकिए, कौन? अब जब हम C में एक नेस्टेड शेल में हैं, तो वर्तमान उपयोगकर्ता कोई नहीं है? हमने अनुमान लगाया होगा कि चूंकि सी एक नया उपयोगकर्ता नाम है, इसलिए प्रक्रिया में एक अलग तरह की आईडी हो सकती है। इसलिए, हम शायद उससे iffy रहने की उम्मीद नहीं करते थे, लेकिन nobody मजाकिया नहीं है। दूसरी ओर, यह बहुत अच्छा है क्योंकि हमें वह अलगाव मिला जो हम चाहते थे। हमारी प्रक्रिया में अब सिस्टम में एक अलग (यद्यपि टूटा हुआ) आईडी प्रतिस्थापन है - वर्तमान में यह हर किसी को और प्रत्येक समूह को nogroup रूप में nogroup ।

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

यह मैपिंग वही है जो हमारे unshare शेल में टूटी हुई है। यह पता चला है कि नए उपयोगकर्ता नामस्थान रिक्त मानचित्रण के साथ शुरू होते हैं, और परिणामस्वरूप, लिनक्स डिफ़ॉल्ट रूप से भयानक उपयोगकर्ता का उपयोग करता है। हमें अपने नए नामस्थान में कोई उपयोगी कार्य करने से पहले इसे ठीक करने की आवश्यकता है। उदाहरण के लिए, वर्तमान में, सिस्टम कॉल (जैसे कि setuid ) जो कि यूआईडी के साथ काम करने का प्रयास विफल होगा। लेकिन डरो मत! ऑल- टू -फाइल परंपरा के अनुसार, लिनक्स इस मैपिंग को /proc फाइल सिस्टम /proc/$pid/uid_map (GID के लिए /proc/$pid/gid_map ) का उपयोग करके प्रस्तुत करता है, जहां $pid प्रक्रिया आईडी है। हम इन दो फाइलों को मैप फाइल कहेंगे ।

मानचित्र फ़ाइलें

मैप फाइलें सिस्टम में विशेष फाइलें हैं। क्या हैं खास? खैर, हर बार आपके द्वारा पढ़ी गई विभिन्न सामग्रियों को वापस करके, यह इस बात पर निर्भर करता है कि आपकी प्रक्रिया क्या पढ़ रही है। उदाहरण के लिए, मैप फ़ाइल /proc/$pid/uid_maps उपयोगकर्ता नामस्थान से /proc/$pid/uid_maps से मैपिंग देता है जो रीडिंग प्रक्रिया के उपयोगकर्ता नामस्थान में /proc/$pid/uid_maps लिए $pid प्रक्रिया का मालिक है। और, परिणामस्वरूप, X को संसाधित करने के लिए वापस लौटाई गई सामग्री Y से संसाधित करने के लिए अलग-अलग हो सकती है, भले ही वे एक ही समय में एक ही मानचित्र फ़ाइल पढ़ते हों।

विशेष रूप से, प्रक्रिया X , जो UID मैप फ़ाइल /proc/$pid/uid_map , स्ट्रिंग्स का एक सेट प्राप्त करती है। प्रत्येक पंक्ति $pid प्रक्रिया के उपयोगकर्ता नामस्थान C की UIDs की एक निरंतर श्रृंखला का नक्शा बनाती है, जो किसी अन्य नामस्थान में UIDs की श्रेणी के अनुरूप है।

प्रत्येक पंक्ति में $fromID $toID $length का प्रारूप है, जहां:

$fromID $pid प्रक्रिया के उपयोगकर्ता नामस्थान के लिए सीमा का शुरुआती यूआईडी है
$lenght सीमा की लंबाई है।
$toID का अनुवाद पढ़ने की प्रक्रिया X पर निर्भर करता है। यदि X किसी अन्य उपयोगकर्ता नामस्थान U से संबंधित है , तो $toID , U से उस श्रेणी का प्रारंभिक UID है, जो $fromID से $fromID । अन्यथा, $toID , P की श्रेणी का प्रारंभ UID है, प्रक्रिया C के मूल उपयोगकर्ता नाम स्थान ।

उदाहरण के लिए, यदि कोई प्रक्रिया फ़ाइल /proc/1409/uid_map और प्राप्त पंक्तियों के बीच आप 15 22 5 देख सकते हैं, तो प्रक्रिया के उपयोगकर्ता नामस्थान 1409 UIDs से 1409 रीडिंग प्रक्रिया के एक अलग उपयोगकर्ता नामस्थान की UID 22-26 पर मैप की जाती हैं।

दूसरी ओर, यदि कोई प्रक्रिया फ़ाइल /proc/$$/uid_map (या पढ़ने की प्रक्रिया के समान यूजर नेमस्पेस से संबंधित किसी भी प्रक्रिया का एक नक्शा फ़ाइल) और 15 22 5 प्राप्त करता है, तो 15 से 19 तक यूआईडी उपयोगकर्ता नाम स्थान C उपयोगकर्ता नामस्थान के लिए जनक के 22 से 26 तक UIDs में मैप करता है।

आइए इसे आजमाएँ:

 P$ echo $$ 1442 #   user namespace... C$ echo $$ 1409 # C      ,     C$ cat /proc/1409/uid_map #  #   namespace P      # UIDs    UID    P$ cat /proc/1442/uid_map 0 0 4294967295 # UIDs  0  4294967294  P  #  4294967295 -  ID no user -  C. C$ cat /proc/1409/uid_map 0 4294967295 4294967295

खैर, यह बहुत रोमांचक नहीं था, क्योंकि ये दो चरम मामले थे, लेकिन यह कुछ बातें कहती हैं:

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

यूआईडी मैप फाइल लिखना

हमारे नए बनाए गए उपयोगकर्ता नाम स्थान C को ठीक करने के लिए, हमें बस C से संबंधित किसी भी प्रक्रिया के लिए फाइल के लिए उनकी सामग्री को लिखकर अपनी आवश्यक मैपिंग प्रदान करनी होगी (हम इसे लिखने के बाद इस फाइल को अपडेट नहीं कर सकते हैं)। इस फ़ाइल को लिखना लिनक्स को दो बातें बताता है:

UIDs उन प्रक्रियाओं के लिए उपलब्ध हैं जो लक्ष्य उपयोगकर्ता नाम स्थान C से संबंधित हैं ।
वर्तमान उपयोगकर्ता नामस्थान में कौन सा यूआईडी सी में यूआईडी के अनुरूप है ।

उदाहरण के लिए, यदि हम बच्चे C नाम स्थान के लिए मैप फाइल में पेरेंट यूजर नेमस्पेस P से निम्नलिखित लिखते हैं:

 0 1000 1 3 0 1

हम अनिवार्य रूप से लिनक्स को बताते हैं कि:

सी में प्रक्रियाओं के लिए, सिस्टम में मौजूद एकमात्र यूआईडी, यूआईडी 0 और 3 । उदाहरण के लिए, setuid(9) सिस्टम कॉल हमेशा अमान्य उपयोगकर्ता आईडी जैसी किसी चीज़ के साथ समाप्त होगी।
पी में यूआईडी 1000 और 0 पी में यूआईडी 0 और 3 अनुरूप हैं । उदाहरण के लिए, यदि P के C में UID 1000 साथ चलने वाली एक प्रक्रिया है , तो यह पाएगा कि स्विच करने के बाद, इसका UID root 0 हो गया root ।

नाम स्थान और विशेषाधिकार मालिक

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

जब भी एक गैर-उपयोगकर्ता नाम स्थान N बनाया जाता है , तो Linux उस प्रक्रिया के वर्तमान उपयोगकर्ता नाम P को असाइन करता है जो N को नाम स्थान N का स्वामी बनाता है । यदि पी एक ही clone सिस्टम कॉल में अन्य नामस्थानों के साथ बनाया गया है, तो लिनक्स सुनिश्चित करता है कि पी पहले बनाया जाएगा और अन्य नामस्थानों का मालिक बनाया जाएगा।

नामस्थानों का स्वामी महत्वपूर्ण है क्योंकि एक संसाधन जो एक उपयोगकर्ता नाम स्थान नहीं है पर एक विशेषाधिकार प्राप्त कार्रवाई करने का अनुरोध करता है, उसके यूआईडी विशेषाधिकार इस उपयोगकर्ता नामस्थान के मालिक के खिलाफ जांचे होंगे, न कि रूट उपयोगकर्ता नामस्थान। उदाहरण के लिए, मान लें कि P , बच्चे C का मूल उपयोगकर्ता नामस्थान है , और P और C का अपना नेटवर्क नेमस्पेस M और N है। एम में शामिल नेटवर्क उपकरणों को बनाने के लिए एक प्रक्रिया के विशेषाधिकार नहीं हो सकते हैं, लेकिन यह एन के लिए ऐसा करने में सक्षम हो सकता है ।

हमारे लिए एक नेमस्पेस मालिक होने का नतीजा यह है कि जब हम किसी यूजर नेमस्पेस के निर्माण का अनुरोध करते हैं, तो बिना किसी का उपयोग किए कमांड को निष्पादित करते समय या isolate करते समय हम sudo आवश्यकता को छोड़ सकते हैं। उदाहरण के लिए, unshare -u bash को sudo आवश्यकता होगी, लेकिन unshare -Uu bash अब नहीं होगा:

 # UID 1000 --      user namespace P. P$ id uid=1000(iffy) gid=1000(iffy) #           # network namespace. P$ ip link add type veth RTNETLINK answers: Operation not permitted #     ,     #  user  network namespace P$ unshare -nU bash # :  sudo C$ ip link add type veth RTNETLINK answers: Operation not permitted # ,  . ,  # UID 0 (root)    ,  #     nobody.   . C$ echo $$ 13294 #   P,   UID 1000  P  UID 0  C P$ echo "0 1000 1" > /proc/13294/uid_map #   ? C$ id uid=0(root) gid=65534(nogroup) C$ ip link add type veth # !

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

आईडी का समाधान कैसे किया जाता है

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

जब भी किसी नेस्टेड यूजर नेमस्पेस में एक प्रक्रिया एक ऑपरेशन करती है, जिसके लिए अनुमति जाँच की आवश्यकता होती है - उदाहरण के लिए, एक फाइल बनाते हुए - इस यूजर नेमस्पेस में इसके यूआईडी की तुलना रूट यूज़र नेमस्पेस में समकक्ष यूजर आईडी के साथ की जाती है, जो नेमस्पेस ट्री में मैपिंग को रूट करके रूट करता है। विपरीत दिशा में एक आंदोलन है, उदाहरण के लिए, जब वह उपयोगकर्ता आईडी पढ़ता है, जैसा कि हम ls -l my_file साथ करते हैं। मालिक my_file UID को रूट उपयोगकर्ता नाम स्थान से वर्तमान एक और अंतिम संबंधित ID (या यदि कोई मैपिंग अनुपस्थित थी, तो पूरे वृक्ष के साथ अनुपस्थित है) से मैप किया जाता है।

समूह आईडी

यहां तक कि अगर हम सी में जड़ थे, तब भी हम अपने समूह आईडी के रूप में भयानक nogroup साथ जुड़े हुए हैं। हमें बस इसी /proc/$pid/gid_map लिए समान करने की आवश्यकता है। इससे पहले कि हम ऐसा कर सकें, हमें setgroups सिस्टम कॉल को अक्षम करने की आवश्यकता है (यह आवश्यक नहीं है यदि हमारे उपयोगकर्ता के पास पहले से ही P में CAP_SETGID क्षमता है, लेकिन हम इसे नहीं मानेंगे, क्योंकि यह आमतौर पर CAP_SETGID विशेषाधिकारों के साथ आता है) इस इनकार को लिखकर। "फ़ाइल की खरीद proc/$pid/setgroups :

 #  13294 -- pid  unshared  C$ id uid=0(root) gid=65534(nogroup) P$ echo deny > /proc/13294/setgroups P$ echo "0 1000 1" > /proc/13294/gid_map #  group ID   C$ id uid=0(root) gid=0(root)

कार्यान्वयन

इस पोस्ट के लिए स्रोत कोड यहां पाया जा सकता है ।

जैसा कि आप देख सकते हैं, उपयोगकर्ता नामस्थानों के प्रबंधन से जुड़ी कई कठिनाइयाँ हैं, लेकिन कार्यान्वयन काफी सरल है। हमें बस इतना करना है कि एक फ़ाइल में लाइनों का एक गुच्छा लिखना है - यह पता लगाने के लिए कि क्या और कहाँ लिखना है। आगे की हलचल के बिना, यहाँ हमारे लक्ष्य हैं:

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

1 हमारे clone सिस्टम कॉल में केवल CLONE_NEWUSER ध्वज को जोड़कर प्राप्त किया जाता है।

 int clone_flags = SIGCHLD | CLONE_NEWUTS | CLONE_NEWUSER;

2 हम prepare_user_ns फ़ंक्शन को prepare_user_ns हैं, जो root रूप में सावधानी से एक नियमित उपयोगकर्ता 1000 प्रतिनिधित्व करता root ।

 static void prepare_userns(int pid) { char path[100]; char line[100]; int uid = 1000; sprintf(path, "/proc/%d/uid_map", pid); sprintf(line, "0 %d 1\n", uid); write_file(path, line); sprintf(path, "/proc/%d/setgroups", pid); sprintf(line, "deny"); write_file(path, line); sprintf(path, "/proc/%d/gid_map", pid); sprintf(line, "0 %d 1\n", uid); write_file(path, line); }

और हम इसे कमांड प्रक्रिया का संकेत देने से ठीक पहले मूल उपयोगकर्ता नामस्थान में मुख्य प्रक्रिया से कहेंगे।

  ... //      . int pipe = params.fd[1]; //      namespace ... prepare_userns(cmd_pid); //   ,     . ...

चरण 3 हम यह सुनिश्चित करने के लिए cmd_exec फ़ंक्शन को अपडेट करते हैं कि कमांड को सामान्य अप्रभावित उपयोगकर्ता 1000 से निष्पादित किया जाता है जिसे हमने मैपिंग में प्रदान किया है (याद रखें कि टीम प्रक्रिया के उपयोगकर्ता नामस्थान में उपयोगकर्ता 0 उपयोगकर्ता 1000 ):

  ... //   ' '   . await_setup(params->fd[0]); if (setgid(0) == -1) die("Failed to setgid: %m\n"); if (setuid(0) == -1) die("Failed to setuid: %m\n"); ...

और वह सब है! isolate अब एक अलग उपयोगकर्ता नामस्थान में प्रक्रिया शुरू करता है।

 $ ./isolate sh ===========sh============ $ id uid=0(root) gid=0(root)

इस पोस्ट में काफी कुछ विवरण थे कि उपयोगकर्ता नाम स्थान कैसे काम करता है, लेकिन अंत में, उदाहरण की स्थापना अपेक्षाकृत दर्द रहित थी। अगली पोस्ट में, हम isolate का उपयोग करके अपने स्वयं के माउंट नेमस्पेस में एक कमांड चलाने की संभावना को देखेंगे ( Dockerfile से FROM बयान के पीछे के रहस्य को उजागर करते Dockerfile )। उदाहरण को ठीक से कॉन्फ़िगर करने के लिए हमें लिनक्स की थोड़ी और मदद करनी होगी।

लिनक्स नेमस्पेस में गहरा गोता लगाएं, भाग 2