👪 👩🏾‍🏫 💡 एलएसएम के उपयोग से लिनक्स कर्नेल के प्रमुख तंत्र में एम्बेड करने की विशेषताएं 🕳️ 👶🏽 🙍🏾

एक सॉफ्टवेयर सिस्टम में एंबेडिंग को अतिरिक्त (थर्ड-पार्टी) सॉफ्टवेयर तत्वों को पेश करने की प्रक्रिया के रूप में समझा जाता है, इसे इस तरह से लागू किया जाता है कि, एक तरफ, इसके कामकाज को संरक्षित किया जाता है, और दूसरी तरफ, इसकी कार्यक्षमता का विस्तार या परिवर्तन किया जाता है।

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

एलएसएम के लिनक्स कर्नेल कार्यान्वयन के बारे में

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

एलएसएम सबसिस्टम वास्तुकला सरल है। तकनीकी रूप से, यह ओएस के कर्नेल में स्थापित हुक का एक सेट है जो कस्टम हैंडलर को लागू करने के लिए एक इंटरफ़ेस प्रदान करता है जिसे सिस्टम विभिन्न कार्यों के दौरान कॉल करता है। मूल सुरक्षा मॉडल डिस्क्रिप्टर संरचना सुरक्षा_ऑपरेशन संरचना है, जिसका विवरण इसमें शामिल / linux / security.h फ़ाइल में पाया जा सकता है:

 struct security_operations { char name[SECURITY_NAME_MAX + 1]; ... int inode_permission(struct inode * inode, int mask); ... }

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

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

 static struct security_o perations * security_ops; static struct security_o perations default_security_ops = { . name = "default", };

सिस्टम स्टार्टअप पर इस सूचक का प्रारंभिक मान default_security_ops संरचना द्वारा वर्णित मानक सुरक्षा मॉडल से मेल खाता है और इसमें सिस्टम के डिफ़ॉल्ट व्यवहार को लागू करना शामिल है। इसी समय, हैंडलर कार्यों को भरना न्यूनतम है। हालांकि, अगर सिस्टम के संचालन के दौरान किसी अन्य मॉडल को सक्रिय करना आवश्यक हो जाता है, तो यह बस इस सूचक की सामग्री को प्रतिस्थापित करके किया जा सकता है। निम्नलिखित हुक में सुरक्षा_ का उपयोग करने का एक उदाहरण है:

 int security_inode_permission(struct inode *inode, int mask) { if (unlikely(IS_PRIVATE(inode))) return 0; return security_ops->inode_permission(inode, mask); }

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

 int inode_permission(struct inode *inode, int mask) { int retval; retval = sb_permission(inode->i_sb, inode, mask); if (retval) return retval; return __inode_permission(inode, mask); } int __inode_permission(struct inode *inode, int mask) { int retval; if (unlikely(mask & MAY_WRITE)) { /* * Nobody gets write access to an immutable file. */ if (IS_IMMUTABLE(inode)) return -EACCES; } retval = do_inode_permission(inode, mask); if (retval) return retval; retval = devcgroup_inode_permission(inode, mask); if (retval) return retval; return security_inode_permission(inode, mask); }

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

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

सबसे पहले, उनकी संख्या उल्लेखनीय है। वास्तव में, यदि संस्करण v2.6.11 के कर्नेल में 134 हुक थे, तो संस्करण 3.8 के कर्नेल में पहले से 189 हुक थे, जो कर्नेल में एलएसएम एकीकरण की गहराई की डिग्री का एक संकेतक है। दूसरे, हुक की संख्या में परिवर्तन की गतिशीलता, संस्करण v2.6.34 से पहले एलएसएम के तेजी से विकास को इंगित करता है और इसके बाद कुछ स्थिरीकरण होता है, जो कि उपतंत्र की परिपक्वता, इसकी सापेक्ष पूर्णता और वास्तुशिल्प स्थिरता का सूचक है।

LSM का उपयोग कर एम्बेड करने के बारे में

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

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

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

संस्करण v2.6.24 बाद से, security_ops पॉइंटर का निर्यात नहीं किया गया है और इसे static के रूप में चिह्नित किया गया है (देखें कमिट 189b3b1c89761054fee3438f063d7f257306e2d8 );
संस्करण v2.6.35 से शुरू होने पर, register_security फ़ंक्शन निर्यात नहीं किया जाता है और इसे __init के रूप में चिह्नित किया __init , जिसका अर्थ है कि मेमोरी कोड को कोड के बाद लोड करना अनलोड करना (देखें प्रतिबद्ध c1e992b99603a84ddebb188542b64f2d9232c07 );

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

एम्बेड करने के व्यावहारिक पहलू

यह ऊपर उल्लेख किया गया था कि कर्नेल v2.6.34 शुरू v2.6.34 , सिस्टम के संचालन के दौरान वर्तमान सुरक्षा मॉडल को बदलने की कोई नियमित क्षमता नहीं है। हालांकि, इस परिस्थिति को दूर किया जा सकता है यदि वर्तमान मॉडल पॉइंटर के पते का निर्धारण करने के लिए एक विधि पाई जाती है - security_ops । यह निर्धारित करने के लिए सरल और विश्वसनीय तरीकों में से एक कर्नेल कोड को अलग करना है, अर्थात् उन कार्यों में से एक जहां इस सूचक का उपयोग किया जाता है। वास्तव में, यह एक उदाहरण के रूप में विचार करने के लायक है gdb डीबगर का उपयोग करके 64-बिट x86 सिस्टम के लिए प्राप्त निर्यात की गई gdb हुक फ़ंक्शन की सूची:

 int security_sb_copy_data(char *orig, char *copy) { return security_ops->sb_copy_data(orig, copy); } EXPORT_SYMBOL(security_sb_copy_data);

 # gdb vmlinux /proc/kcore (gdb) x/7i security_sb_copy_data 0xffffffff811f61b0: push %rbp 0xffffffff811f61b1: mov %rsp,%rbp 0xffffffff811f61b4: data32 data32 data32 xchg %ax,%ax 0xffffffff811f61b9: mov 0x881690(%rip),%rax # 0xffffffff81a77850 0xffffffff811f61c0: callq *0x98(%rax) 0xffffffff811f61c6: pop %rbp 0xffffffff811f61c7: retq (gdb) x/s* 0xffffffff81a77850 0xffffffff81850fa0: "default"

जैसा कि आप देख सकते हैं, प्रेषण निर्देश callq *0x98(%rax) sb_copy_data हैंडलर sb_copy_data को ऑफसेट 0x98 पर कॉल करता है, जो %rax में संग्रहीत सूचक के सापेक्ष है। अर्थात्, %rax में security_ops भी है। इस प्रकार, इस सूचक को प्राप्त करने के लिए, यह आवश्यक है, अनुक्रमिक रूप से, निर्देशों के बाद निर्देश, इस फ़ंक्शन की शुरुआत से कमांड को स्कैन करने के लिए mov 0x881690(%rip),%rax , mov 0x881690(%rip),%rax में वांछित मान लोड करना और अपने ऑपरेंड का एक सरल विश्लेषण करना। , आवश्यक सूचक प्राप्त करें। नीचे वह कोड है जो इसे udis86 disassembler का उपयोग करके x86 के लिए करने की अनुमति देता है:

 static void * get_lsm_entry(void) { /* this one is exported */ return (void *)&security_sb_copy_data; } static struct security_operations ** get_lsm_sop(void) { ud_t ud; void * entry = get_lsm_entry(), * result = NULL; ud_initialize(&ud, BITS_PER_LONG, UD_VENDOR_ANY, entry, 128); while (ud_disassemble(&ud) && ud.mnemonic != UD_Iret) { if (ud.mnemonic == UD_Imov && \ ud.operand[0].type == UD_OP_REG && ud.operand[1].type == UD_OP_MEM) { #ifdef CONFIG_X86_64 result = entry + ud_insn_off(&ud) + ud_insn_len(&ud); #endif result = result + ud.operand[1].lval.sdword; break; } } return result; }

इस प्रकार, security_ops पॉइंटर को पॉइंटर प्राप्त करने के बाद, आप इस पॉइंटर के मान को बदलकर सक्रिय सुरक्षा मॉडल को अपने स्वयं के कार्यान्वयन से बदल सकते हैं। एक उदाहरण के रूप में, मैं फेकेल्म प्रोजेक्ट का कोड देता inode_permission जो inode_permission फ़ंक्शन को बदलता है।

निष्कर्ष

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

इसके अलावा, यह महत्वपूर्ण है कि एलएसएम वास्तुकला की अवधारणा स्वयं, सरल और कुशल होने के कारण, सुरक्षित नहीं है, क्योंकि वास्तव में, संपूर्ण विस्तारित कर्नेल सुरक्षा मॉडल एक एकल पॉइंटर पर आधारित है - security_ops !

एलएसएम के उपयोग से लिनक्स कर्नेल के प्रमुख तंत्र में एम्बेड करने की विशेषताएं

एलएसएम के लिनक्स कर्नेल कार्यान्वयन के बारे में

LSM का उपयोग कर एम्बेड करने के बारे में

एम्बेड करने के व्यावहारिक पहलू

निष्कर्ष

पढ़ने के लिए

More articles: