Linux विशेषाधिकारों (क्षमताओं) के बारे में संक्षेप में

लेख का एक अनुवाद विशेष रूप से लिनक्स प्रशासक पाठ्यक्रम के छात्रों के लिए तैयार किया गया था।

---

SystemD, Docker, और ऑर्केस्ट्रेटर जैसे Kuberneses के बड़े हिस्से में क्षमताओं का अधिक से अधिक धन्यवाद किया जा रहा है। लेकिन, जैसा कि मुझे लगता है, प्रलेखन को समझना थोड़ा मुश्किल है और विशेषाधिकारों के कार्यान्वयन के कुछ हिस्से मेरे लिए कुछ भ्रमित करने वाले हैं, इसलिए मैंने इस छोटे से लेख में अपने वर्तमान ज्ञान को साझा करने का निर्णय लिया।



सबसे महत्वपूर्ण विशेषाधिकार लिंक क्षमताओं (7) मैन पेज है। लेकिन वह एक प्रारंभिक परिचित के लिए बहुत उपयुक्त नहीं है।

प्रक्रिया की क्षमता

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

रूट उपयोगकर्ता विशेषाधिकारों को कम करने के लिए, POSIX (POSIX क्षमताएं) अनुमतियाँ विशेषाधिकार प्राप्त सिस्टम संचालन के समूहों को सीमित करने का एक तरीका प्रदान करती हैं जो एक प्रक्रिया और उसके वंशजों को प्रदर्शन करने की अनुमति है। संक्षेप में, वे सभी "मूल" अधिकारों को अलग-अलग विशेषाधिकारों के एक समूह में विभाजित करते हैं। क्षमताओं का विचार 1997 में POSIX 1003.1e के मसौदे में वर्णित किया गया था।

लिनक्स पर, प्रत्येक प्रक्रिया (कार्य) में पांच 64-बिट संख्या (सेट) होती हैं जिसमें अनुमति बिट्स होती हैं (लिनक्स 2.6.25 से पहले वे 32-बिट थे), जिसे अंदर देखा जा सकता है

  / proc / <pid> / स्थिति 

।

CapInh: 00000000000004c0 CapPrm: 00000000000004c0 CapEff: 00000000000004c0 CapBnd: 00000000000004c0 CapAmb: 0000000000000000 

ये संख्याएँ (यहाँ हेक्साडेसिमल नोटेशन में दिखाई गई हैं) बिटमैप हैं जिसमें अनुमति सेट का प्रतिनिधित्व किया जाता है। यहाँ उनके पूर्ण नाम हैं:

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

यदि कार्य एक विशेषाधिकार प्राप्त ऑपरेशन (उदाहरण के लिए, पोर्ट <1024) से बाइंड करने के लिए कहता है , तो कर्नेल CAP_NET_BIND_SERVICE के लिए वर्तमान बाउंडिंग सेट की जाँच करता है। यदि यह स्थापित है, तो ऑपरेशन जारी है। अन्यथा, ऑपरेशन EPERM (ऑपरेशन की अनुमति नहीं है) के साथ खारिज कर दिया गया है। ये CAP_ कर्नेल स्रोत कोड में CAP_ किए गए हैं और क्रमिक रूप से गिने गए हैं, इसलिए CAP_NET_BIND_SERVICE , 10 के बराबर, का अर्थ है बिट 1 << 10 = 0x400 (यह मेरे पिछले उदाहरण में हेक्साडेसिमल अंक "4" है)।

वर्तमान में परिभाषित विशेषाधिकारों की एक पूरी मानव-पठनीय सूची वर्तमान क्षमताओं (7) मैन पेज (केवल यहां संदर्भ के लिए सूची है ) में पाई जा सकती है।

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

 # capsh --print Current: = cap_setgid,cap_setuid,cap_net_bind_service+eip Bounding set = cap_setgid,cap_setuid,cap_net_bind_service Ambient set = Securebits: 00/0x0/1'b0 secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: no (unlocked) secure-no-ambient-raise: no (unlocked) uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) 

यहाँ कुछ भ्रमित करने वाले बिंदु हैं:

• वर्तमान - प्रारूप प्रक्रिया cap_to_text (3) में capsh प्रक्रिया के प्रभावी, विरासत में मिला और उपलब्ध विशेषाधिकार प्रदर्शित करता है। इस प्रारूप में, अधिकारों को अनुमति समूहों के रूप में सूचीबद्ध किया गया है “capability[,capability…]+(e|i|p)” , जहां “e” अर्थ प्रभावी है, “i” विरासत में मिला है, और “p” उपलब्ध है। सूची को “,” प्रतीक द्वारा अलग नहीं किया गया है, जैसा कि आपने अनुमान लगाया होगा (cap_setgid+eip, cap_setuid+eip) । अल्पविराम एक क्रिया समूह में अनुमतियों को विभाजित करता है। कार्रवाई समूहों की वास्तविक सूची को तब रिक्त स्थान द्वारा अलग किया जाता है। दो एक्शन ग्रुप के साथ एक और उदाहरण “= cap_sys_chroot+ep cap_net_bind_service+eip” । और क्रियाओं के निम्नलिखित दो समूह “= cap_net_bind_service+e cap_net_bind_service+ip” समान मान को एक “cap_net_bind_service+eip” रूप में एन्कोड करेंगे।
• बाउंडिंग सेट / एम्बिएंट सेट । आगे भ्रमित करने के लिए, इन दो पंक्तियों में रिक्त स्थान द्वारा अलग किए गए इन सेटों में परिभाषित अनुमतियों की एक सूची है। यहां cap_to_text प्रारूप का उपयोग नहीं किया गया है, क्योंकि इसमें उपलब्ध, प्रभावी और विरासत में मिली अनुमतियों के सेट नहीं हैं, लेकिन केवल एक (सीमा / परिवेश) सेट है।
• सिक्योरबिट्स : टास्क के सिक्योरिटी फ्लैग्स को दशमलव / हेक्साडेसिमल / वेरिलॉग फॉर्मेट में प्रदर्शित करता है (हाँ, हर कोई इसे यहाँ उम्मीद करता है, और यह इस बिंदु से पूरी तरह से स्पष्ट है कि प्रत्येक सिस्टम एडमिनिस्ट्रेटर अपने स्वयं के FPGA और ASIC प्रोग्राम करता है)। निम्नलिखित राज्य सुरक्षित है। वास्तविक झंडे को SECBIT_* रूप में परिभाषित किया गया है। SECBIT_* में, और क्षमताओं (7) में भी वर्णित है।
• इस उपयोगिता में "NoNewPrivs" जानकारी के प्रदर्शन का अभाव है, जिसे देखा जा सकता है

    / proc / <pid> / स्थिति 

  । यह केवल prctl (2) में उल्लिखित है, हालाँकि यह फ़ाइल अनुमतियों (नीचे और अधिक विवरण में) के साथ उपयोग किए जाने पर सीधे अधिकारों को प्रभावित करता है। NoNewPrivs को निम्नानुसार वर्णित किया गया है: “ no_new_privs साथ 1 पर no_new_privs करें, निष्पादित करें (2) विशेषाधिकारों को अनुदान नहीं देने का वादा करता है जो कॉल किए बिना निष्पादित नहीं किए जा सकते थे (2) (उदाहरण के लिए, set-user-ID , set-group-ID बिट्स को संसाधित करना set-group-ID और अक्षम फ़ाइल अनुमतियाँ प्रसंस्करण) । स्थापना के बाद, no_new_privs विशेषता रीसेट नहीं की जा सकती। इस विशेषता का मूल्य कांटे (2) और क्लोन (2) के माध्यम से बनाए गए वंशों द्वारा विरासत में मिला है और निष्पादित (2) के माध्यम से संग्रहीत किया गया है। " Kubernetes इस ध्वज को 1 पर सेट करता है जब allowPrivilegeEscalation फली सुरक्षा में गलत है।

निष्पादित (2) के माध्यम से एक नई प्रक्रिया शुरू करते समय, क्षमताओं में निर्दिष्ट सूत्र का उपयोग करके बच्चे की प्रक्रिया के लिए अनुमतियों को परिवर्तित किया जाता है: (7)

 P'(ambient) = (file is privileged) ? 0 : P(ambient) P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding)) | P'(ambient) P'(effective) = F(effective) ? P'(permitted) : P'(ambient) P'(inheritable) = P(inheritable) [ie, unchanged] P'(bounding) = P(bounding) [ie, unchanged] where: P() denotes the value of a thread capability set before the execve(2) -      execve(2) P'() denotes the value of a thread capability set after the execve(2) -      execve(2) F() denotes a file capability set -   

ये नियम सभी अनुमति सेटों में प्रत्येक बिट के लिए किए गए कार्यों का वर्णन करते हैं (परिवेश / अनुमति / प्रभावी / अंतर्निहित / सीमा)। मानक C सिंटैक्स का उपयोग किया जाता है (और - तार्किक AND; के लिए - तार्किक OR के लिए)। P 'एक बाल प्रक्रिया है। P वर्तमान प्रक्रिया को निष्पादित (2) कहता है। एफ निष्पादित के माध्यम से लॉन्च की गई फ़ाइल की तथाकथित "फ़ाइल अनुमति" है।

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

• यदि कॉलर के पास CAP_SETPCAP नहीं है, तो नए विरासत में दिए गए सेट में P (विरासत में मिला) और P (उपलब्ध) का एक उपसमूह होना चाहिए
• (लिनक्स 2.6.25 के साथ) नया विरासत वाला सेट पी (विरासत में मिला) और पी (सीमित) का सबसेट होना चाहिए
• नया उपलब्ध सेट P का उपसमूह होना चाहिए (उपलब्ध)
• नया कुशल सेट पी का सबसेट होना चाहिए (प्रभावी)

फ़ाइल की अनुमति

कभी-कभी सीमित अधिकारों के साथ एक उपयोगकर्ता को एक फ़ाइल चलाने की आवश्यकता होती है जिसमें अधिक विशेषाधिकारों की आवश्यकता होती है। इससे पहले बाइनरी फ़ाइल में chmod + s ./executable बिट ( chmod + s ./executable ) सेट करके प्राप्त किया गया था। ऐसी फाइल, यदि यह रूट की है, तो किसी भी उपयोगकर्ता द्वारा निष्पादित किए जाने पर पूर्ण रूट अधिकार होंगे।

लेकिन यह तंत्र एक फ़ाइल को बहुत अधिक विशेषाधिकार देता है, इसलिए POSIX अनुमतियों ने "फ़ाइल अनुमतियाँ" नामक एक अवधारणा को लागू किया है। उन्हें "Security.capability" नामक एक विस्तारित फ़ाइल विशेषता के रूप में संग्रहीत किया जाता है, इसलिए आपको विस्तारित विशेषताओं (जैसे *, XFS, Raiserfs, Brtfs, overlay2, ...) के समर्थन के साथ एक फ़ाइल सिस्टम की आवश्यकता होती है। इस विशेषता को बदलने के लिए, CAP_SETFCAP अनुमति CAP_SETFCAP (प्रक्रिया अनुमतियों के उपलब्ध सेट में)।

 $ getfattr -m - -d `which ping` # file: usr/bin/ping security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA= $ getcap `which ping` /usr/bin/ping = cap_net_raw+ep 

विशेष मामले और टिप्पणियां

बेशक, वास्तव में, सब कुछ इतना सरल नहीं है, और क्षमताओं (7) मैन पेज में वर्णित कई विशेष मामले हैं। संभवतः उनमें से सबसे महत्वपूर्ण हैं:

• यदि NoNewPrivs स्थापित है या फ़ाइल सिस्टम को nosuid के साथ आरोहित किया गया है या सेट-कॉल को निष्पादित करने की प्रक्रिया को नजरअंदाज किया जाता है तो ptrace द्वारा पता लगाया जाता है। फ़ाइल अनुमतियों को भी नजरअंदाज कर दिया जाता है जब कर्नेल no_file_caps विकल्प के साथ no_file_caps होता है।
• एक "डंब" फ़ाइल (क्षमता-डंब) एक बाइनरी फ़ाइल है जो एक सेतु फ़ाइल से फ़ाइल अनुमतियों के साथ एक फ़ाइल में बदल जाती है, लेकिन इसके स्रोत कोड को बदले बिना। ऐसी फाइलें अक्सर उन पर + ep अनुमतियाँ सेट करके प्राप्त की जाती हैं, उदाहरण के लिए, “setcap cap_net_bind_service+ep ./binary” । महत्वपूर्ण हिस्सा "ई" है - प्रभावी। निष्पादित करने के बाद, ये अनुमतियाँ उपलब्ध और मौजूदा दोनों में जोड़ी जाएंगी, इसलिए निष्पादन योग्य विशेषाधिकार प्राप्त ऑपरेशन का उपयोग करने के लिए तैयार हो जाएगा। इसके विपरीत, एक "क्षमता-स्मार्ट" फ़ाइल जो libcap या समान कार्यक्षमता का उपयोग करती है , किसी भी समय "प्रभावी" या "विरासत में" बिट्स सेट करने के लिए cap_set_proc (3) (या capset ) का उपयोग कर सकती है यदि वह अनुमति पहले से ही है सस्ती ”किट। इसलिए, " setcap cap_net_bind_service+p ./binary” एक "स्मार्ट" फ़ाइल के लिए पर्याप्त होगा, क्योंकि यह एक विशेषाधिकार प्राप्त ऑपरेशन को लागू करने से पहले एक प्रभावी सेट में आवश्यक अनुमतियों को सेट करने में सक्षम होगा। नमूना कोड देखें।
• सेतु-रूट वाली फाइलें काम करना जारी रखती हैं, जब उपयोगकर्ता गैर-रूट के रूप में शुरू होता है, तो सभी रूट विशेषाधिकार प्रदान करते हैं। लेकिन अगर उनके पास फ़ाइल अनुमति सेट है, तो केवल उन्हें ही अनुमति दी जाएगी। आप अनुमतियों के खाली सेट के साथ एक सेटिड फ़ाइल भी बना सकते हैं, जो इसे बिना किसी अनुमति के यूआईडी 0 के साथ एक उपयोगकर्ता के रूप में चलाएगा। रूट उपयोगकर्ता के लिए विशेष मामले हैं जब कोई फाइल सेटुयड-रूट के साथ चल रही है और विभिन्न सुरक्षा झंडे स्थापित कर रही है (आदमी देखें)।
• एक बाउंडिंग सेट मास्क उपलब्ध अनुमतियाँ हैं, लेकिन विरासत में नहीं मिली हैं। पी '(उपलब्ध) = एफ (उपलब्ध) और पी (सीमित) याद रखें। यदि किसी स्ट्रीम को उसके विरासत वाले सेट में अनुमति है जो उसके बाउंडिंग सेट में नहीं है, तो वह अभी भी अपने उपलब्ध सेट में एक फ़ाइल चलाकर यह अनुमति प्राप्त कर सकता है जिसकी अनुमति विरासत में दिए गए सेट में है - P '(उपलब्ध) = P ( विरासत में मिली) और एफ (विरासत में मिली)।
• उस प्रोग्राम को निष्पादित करना जो सेट-यूज़र-आईडी, सेट-ग्रुप-आईडी बिट्स के माध्यम से यूआईडी या जीआईडी ​​को बदलता है, या किसी प्रोग्राम को निष्पादित करने के लिए जिसके द्वारा कोई फ़ाइल अनुमतियाँ सेट की जाती हैं , परिवेश सेट को साफ़ कर देगा । अनुमतियाँ आसपास के सेट में PR_CAP_AMBIENT prctl का उपयोग करके PR_CAP_AMBIENT जाती हैं । इन अनुमतियों को पहले से ही सुलभ और विरासत में मिली प्रक्रिया सेट में मौजूद होना चाहिए।
• यदि यूआईडी के साथ 0 के अलावा कोई प्रक्रिया निष्पादित (2) निष्पादित होती है , तो इसके उपलब्ध और सक्रिय सेट के सभी अधिकार हटा दिए जाएंगे।
• यदि SECBIT_KEEP_CAPS (या व्यापक SECBIT_NO_SETUID_FIXUP ) सेट नहीं है, और UID को 0 से बदलकर SECBIT_NO_SETUID_FIXUP से विरासत में मिली, पहुँच योग्य और प्रभावी सेट से सभी अनुमतियाँ हटा दी जाती हैं ।

इसलिए ...

यदि आधिकारिक nginx कंटेनर, ingress-nginx या आपकी स्वयं की रोक या त्रुटि के साथ पुनरारंभ होता है:

bind() to 0.0.0.0:80 failed (13: Permission denied)

... इसका मतलब यह है कि पोर्ट 80 पर एक अनप्रीविलाइज्ड (0 नहीं) उपयोगकर्ता के रूप में सुनने का प्रयास था, और वर्तमान अनुमति CAP_NET_BIND_SERVICE में कोई CAP_NET_BIND_SERVICE नहीं थी। इन अधिकारों को प्राप्त करने के लिए, आपको कम से कम cap_net_bind_service+ie nginx फ़ाइल अनुमति के लिए xattr और सेट ( setcap का उपयोग setcap ) का उपयोग करना होगा। इस फ़ाइल की अनुमति को लीगेसी सेट (पॉड सिक्योरिटीकॉन्टेक्स / क्षमता / ऐड / NET_BIND_SERVICE से निर्धारित सीमा के साथ निर्दिष्ट) के साथ जोड़ा जाएगा, और यह भी उपलब्ध अनुमतियों के सेट में रखा जाएगा। परिणाम cap_net_bind_service+pie ।

यह सब तब तक काम करता है जब तक SecurityContext / allowPrivilegeEscalation सही पर सेट हो जाता है और docker / rkt स्टोरेज ड्राइवर (docker प्रलेखन देखें) xattrs का समर्थन करता है।

यदि nginx अनुमतियों के संबंध में स्मार्ट थे, तो cap_net_bind_service+i पर्याप्त होगा। तब वह उपलब्ध सेट से प्रभावी तक अधिकारों के विस्तार के लिए libcap का उपयोग कर सकता था। परिणामस्वरूप प्राप्त होने के बाद cap_net_bind_service+pie ।

Xattr का उपयोग करने के अलावा, एक गैर-रूट कंटेनर में cap_net_bind_service प्राप्त करने का एकमात्र तरीका cap_net_bind_service को अपनी बाहरी क्षमताओं (परिवेश क्षमताओं) को सेट करने देना है। लेकिन अप्रैल 2019 तक, यह अभी तक लागू नहीं किया गया है ।

कोड उदाहरण

एक कुशल अनुमति सेट में CAP_NET_BIND_SERVICE को जोड़ने के लिए CAP_NET_BIND_SERVICE का उपयोग करके नमूना कोड यहां दिया गया है । बाइनरी फ़ाइल के लिए इसे CAP_BIND_SERVICE+p अनुमति की आवश्यकता है।

संदर्भ (संलग्न):

• क्षमताओं आदमी पृष्ठ (7)
• लिनक्स कर्नेल स्रोत कोड
• स्रोत कोड Libcap
• पुरानी क्षमताएं FAQ