सुरक्षा-उन्नत लिनक्स

From Vigyanwiki
Original author(s)NSA and Red Hat
Developer(s)Red Hat
Initial releaseDecember 22, 2000; 24 years ago (2000-12-22)[1]
Stable release
3.3 / 22 October 2021; 3 years ago (2021-10-22)[2]
Written inC
Operating systemLinux
TypeSecurity, Linux Security Modules (LSM)
LicenseGNU GPL
Websiteselinuxproject.org, https://www.nsa.gov/what-we-do/research/selinux/

सुरक्षा-संवर्धित लिनक्स (एसईलिनक्स) एक लिनक्स कर्नेल सुरक्षा मॉड्यूल है। जो अनिवार्य अभिगम नियंत्रण (मैक) सहित अभिगम नियंत्रण सुरक्षा नीतियों का समर्थन करने के लिए एक तंत्र प्रदान करता है।

एसईलिनक्स कर्नेल संशोधनों और उपयोक्ता-अंतरिक्ष उपकरणों का एक समुच्चय है। जिसे विभिन्न वितरणों में जोड़ा गया है। इसका सॉफ़्टवेयर वास्तुशिल्प सुरक्षा नीति से सुरक्षा निर्णयों के प्रवर्तन को अलग करने का प्रयास करता है और सुरक्षा नीति प्रवर्तन में सम्मिलित सॉफ़्टवेयर की मात्रा को सुव्यवस्थित करता है।[3][4] संयुक्त राज्य अमेरिका की राष्ट्रीय सुरक्षा एजेंसी (एनएसए) द्वारा में अंतर्निहित प्रमुख अवधारणाओं को पहले की कई परियोजनाओं में खोजा जा सकता है।

अवलोकन

एनएसए सुरक्षा-वर्धित लिनक्स टीम एनएसए एसई लिनक्स को इस रूप में वर्णित करती है-[5]

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

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

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

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

इतिहास

यूनिक्स (अधिक स्पष्ट रूप से, पोसिक्स) कंप्यूटिंग वातावरण के अन्दर अनिवार्य और विवेकाधीन अभिगम नियंत्रण (मैक और डैक) प्रदान करने वाले दृष्टिकोण को मानकीकृत करने के लिए निर्देशित सबसे पहला कार्य राष्ट्रीय सुरक्षा एजेंसी के विश्वसनीय यूनिक्स (ट्रूसिक्स) वर्किंग ग्रुप को दिया जा सकता है। जो 1987 से प्राप्त था। 1991 तक और एक इंद्रधनुष श्रृंखला (020A) प्रकाशित की और एक औपचारिक मॉडल और संबद्ध मूल्यांकन साक्ष्य प्रोटोटाइप (020B) तैयार किया जो अंततः अप्रकाशित था।

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

एसई-लिनक्स के मूल प्राथमिक डेवलपर एनएसए ने 22 दिसंबर, 2000 को जीएनयू जीपीएल के अनुसार विवृत स्रोत सॉफ्टवेयर डेवलपमेंट कम्युनिटी के लिए पहला संस्करण जारी किया।[6] सॉफ्टवेयर को 8 अगस्त 2003 को जारी मेनलाइन लिनक्स कर्नेल 2.6.0-test3 में सम्मिलित कर दिया गया था। अन्य महत्वपूर्ण योगदानकर्ताओं में रेड हैट, नेटवर्क एसोसिएट, एसई-कोर कम्प्यूटर डिजाइन, टीरिसि्स टेक्नालॉजि और विश्वसनीय कंप्यूटर समाधान सम्मिलित हैं। फ्लास्क/टीई कार्यान्वयन के प्रायोगिक पोर्ट फ्रीबीएसडी और डार्विन (ऑपरेटिंग प्रणाली) ऑपरेटिंग प्रणाली के लिए विश्वसनीय बीएसडी प्रोजेक्ट के माध्यम से उपलब्ध कराए गए हैं।

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

मूल और बाहरी योगदानकर्ता

2009 में देखरेख बंद होने तक एसई-लिनक्स के मूल और बाहरी योगदानकर्ताओं की एक व्यापक सूची एनएसए वेबसाइट पर होस्ट की गई थी। इसकी निम्नलिखित सूची मूल को www.nsa.gov/SELinux/info/contrib.cfm संरक्षित वेबसाइट के द्वारा इंटरनेट आर्काइव वेबैक मशीन द्वारा प्राप्त की गयी। उनके योगदान की सीमा पृष्ठ में सूचीबद्ध की गयी थी और संक्षिप्तता के लिए त्याग दिया गया है। किन्तु इसे संग्रहीत प्रति के माध्यम से संचालित किया जा सकता है।[7]

  • राष्ट्रीय सुरक्षा एजेंसी (एनएसए)
  • नेटवर्क एसोसिएट्स लेबोरेटरीज (एनएआई लैब्स)
  • द मिटर कॉर्पोरेशन
  • सिक्योर कंप्यूटिंग कॉर्पोरेशन (एससीसी)
  • मैट एंडरसन
  • रयान बर्गौएर
  • बैस्टियन ब्लैंक
  • थॉमस ब्लेहर
  • जोशुआ ब्रिंडल
  • रसेल कोकर
  • जॉन डेनिस
  • जनक देसाई
  • उलरिच ड्रेपर
  • लोरेंजो हर्नांडेज़ गार्सिया-हिएरो
  • डारेल गोएडडेल
  • कार्स्टन ग्रोहमैन
  • स्टीव ग्रब
  • इवान ग्युर्डिएव
  • सर्ज हॉलिन
  • चाड हैनसन
  • जोर्ज होह
  • ट्रेंट जैगर
  • डस्टिन किर्कलैंड
  • कैगई कोहि
  • पॉल क्रुमवीडे
  • जॉय लैटन
  • टॉम लंदन
  • कार्ल मैकमिलन
  • ब्रायन मे
  • फ्रैंक मेयर
  • टॉड मिलर
  • रोलैंड मैकग्राथ
  • पॉल मूर
  • जेम्स मॉरिस
  • युइची नाकामुरा
  • ग्रेग नॉरिस
  • एरिक पेरिस
  • क्रिस पेबेनिटो
  • रेड हैट
  • पेट्रे रोडन
  • शॉन सैवेज
  • चाड सेलर्स
  • रोगेलियो सेरानो जूनियर
  • जस्टिन स्मिथ
  • मनोज श्रीवास्तव
  • ट्रेसिस टेक्नोलॉजी
  • माइकल थॉम्पसन
  • विश्वसनीय कंप्यूटर समाधान
  • टॉम वोग्ट
  • रेनो वैलिन
  • डैन वॉल्श
  • कॉलिन वाल्टर्स
  • मार्क वेस्टमैन
  • डेविड ए व्हीलर
  • वेंकट येकिराला
  • कैथरीन झांग

उपयोगकर्ता, नीतियां और सुरक्षा संदर्भ

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

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

सेलिनक्स -Z शेल कमांड ls, ps और कुछ अन्य में जोड़ता है। जिससे फ़ाइलों या प्रक्रिया के सुरक्षा संदर्भ को देखने की अनुमति प्रदान होती हैं।

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

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

विशेषताएं

एसई-लिनक्स सुविधाओं में सम्मिलित हैं:

  • नीति को प्रवर्तन से स्पष्ट रूप से अलग करना
  • अच्छी प्रकार से परिभाषित नीति इंटरफेस
  • नीति को क्वेरी करने और अभिगम नियंत्रण को संचालित करने वाले अनुप्रयोगों के लिए समर्थन (उदाहरण के लिए सही संदर्भ में क्रॉन्ड रनिंग जॉब्स)
  • विशिष्ट नीतियों और नीति भाषाओं की स्वतंत्रता
  • विशिष्ट सुरक्षा-लेबल स्वरूपों और सामग्री की स्वतंत्रता
  • कर्नेल वस्तुओं और सेवाओं के लिए विभिन्न लेबल और नियंत्रण
  • नीति परिवर्तन के लिए समर्थन
  • प्रणाली अखंडता (डोमेन-प्रकार) और डेटा गोपनीयता (बहुस्तरीय सुरक्षा) की सुरक्षा के लिए विभिन्न उपाय
  • लचीली प्रणाली
  • प्रक्रिया आरंभीकरण और वंशानुक्रम और कार्यक्रम निष्पादन पर नियंत्रण
  • फाइल प्रणाली, डायरेक्टरी, फाइल और ओपन फाइल डिस्क्रिप्टर पर नियंत्रण
  • सॉकेट्स, संदेशों और नेटवर्क इंटरफेस पर नियंत्रण
  • क्षमताओं के उपयोग पर नियंत्रण
  • एक्सेस वेक्टर कैश (एवीसी) के माध्यम से एक्सेस-निर्णयों पर कैश्ड जानकारी[8]
  • डिफ़ॉल्ट-अस्वीकार नीति (पॉलिसी में स्पष्ट रूप से निर्दिष्ट नहीं की गई कोई भी चीज़ की अनुमति नहीं है।)[9][10][11]


एडॉप्टेशन

एसई-स्टेटस प्रणाली में एसई-लिनक्स की स्थिति दिखा रहा है।

एसई-लिनक्स को Android (ऑपरेटिंग प्रणाली) में संस्करण 4.3 के बाद से संचालित किया गया है।[12]

मुफ़्त समुदाय-समर्थित लिनक्स वितरणों में, फेडोरा (ऑपरेटिंग प्रणाली) सबसे पहले अपनाने वालों में से एक था। जिसमें फेडोरा कोर 2 के बाद से डिफ़ॉल्ट रूप से इसके लिए समर्थन सम्मिलित है। अन्य वितरणों में इसके लिए समर्थन सम्मिलित है। जैसे संस्करण 9 स्ट्रेच रिलीज़ के रूप में डेबियन[13] और उबंटू (ऑपरेटिंग प्रणाली) 8.04 हार्डी हेरॉन के रूप में इनका प्रयोग किया गया था।[14] इसके संस्करण 11.1 के अनुसार एसयूएसई- लाइनेक्स में एसई-लिनक्स मूलभूत सक्षमता सम्मिलित है।[15] एसयूएसई-लिनक्स इन्टरप्राइज 11 एसई-लिनक्स को विधि पूर्वावलोकन के रूप में प्रस्तुत करता है।[16]

एसई-लिनक्स, लिनक्स कंटेनरों पर आधारित प्रणालियों में लोकप्रिय है। जैसे कि कोर-ओएस द्वारा कंटेनर लिनक्स और आरकेटी।[17] उपस्थित कंटेनरों और उनके मेजबान के बीच विरोध को और अधिक संचालित करने में सहायता के लिए यह एक अतिरिक्त सुरक्षा नियंत्रण के रूप में उपयोगी सिद्ध होता है।

एसई-लिनक्स 2005 से रेड हैट इनटरप्राइज-लिनक्स (आरएचईएल) संस्करण 4 और भविष्य के सभी रिलीज के भाग के रूप में उपलब्ध है। यह उपस्थिति सेन्टोस और वैज्ञानिक लिनक्स के संबंधित संस्करणों में भी परिलक्षित होती है। आरएचईएल4 में समर्थित नीति लक्षित नीति है। जिसका उद्देश्य उपयोग में अधिकतम सरल है और इस प्रकार यह उतना प्रतिबंधात्मक नहीं है. जितना हो सकता है। आरएचईएल के भविष्य के संस्करणों को लक्षित नीति में और अधिक लक्ष्य रखने की योजना है। जिसका अर्थ अधिक प्रतिबंधात्मक नीतियां होगा।

परिदृश्यों का प्रयोग करें

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

कमांड-लाइन उपयोगिताओं में सम्मिलित हैं:[18]chcon,[19]restorecon,[20]restorecond,[21]runcon,[22]se-con,[23]fixfiles,[24]se-tfiles,[25]load_policy,[26]booleans,[27]getse-bool,[28]se-tse-bool,[29]togglese-bool[30]se-tenforce,se-module,postfix-nochroot,check-se--linux-installation, se-module_package,checkmodule,selinux-config-enforcing,[31]selinuxenabled,[32] और selinux-policy-upgrade[33]


उदाहरण

एसई-लिनक्स को एन्फोर्सिंग मोड में डालने के लिए:

एसई-tenforce 1

एसई-लिनक्स स्थिति को क्वेरी करने के लिए:

getenforce


एपआर्मर के साथ तुलना-

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

कई प्रमुख अंतर हैं:

  • एक महत्वपूर्ण अंतर यह है कि एपआर्मर फ़ाइल प्रणाली ऑब्जेक्ट को इनोड के अतिरिक्त पथ नाम से पहचानता है। इसका अर्थ यह है कि उदाहरण के लिए एक फ़ाइल जो अप्राप्य है। एपआर्मर के अनुसार तब पहुँच योग्य हो सकती है। जब इसके लिए एक हार्ड लिंक बनाया जाता है। जबकि एसई-लिनक्स नए बनाए गए हार्ड लिंक के माध्यम से पहुँच से अस्वीकृत करेगा।
    • परिणामस्वरूप एपआर्मर को एक प्रकार की प्रवर्तन प्रणाली नहीं कहा जा सकता है क्योंकि फाइलों को एक प्रकार नहीं सौंपा गया है। इसके अतिरिक्त उन्हें केवल कॉन्फ़िगरेशन फ़ाइल में संदर्भित किया जाता है।
  • एसई-लिनक्स और एपआर्मर भी इस बात में अधिक भिन्न हैं कि उन्हें कैसे प्रशासित किया जाता है और वे प्रणाली में कैसे एकीकृत होते हैं।[34]
  • चूँकि यह मैक-स्तर के प्रवर्तन के साथ पारंपरिक डीएसी नियंत्रणों को फिर से बनाने का प्रयास करता है। एपआर्मर के संचालन का समुच्च भी अधिकांश एसई-लिनक्स कार्यान्वयन के अनुसार उपलब्ध की तुलना में अधिक छोटा है। उदाहरण के लिए एपआर्मर के संचालन के समुच्चय में सम्मिलित हैं। जो निम्न है: पढ़ना, लिखना, जोड़ना, निष्पादित करना, लॉक करना और लिंक करना।[35] अधिकांशतः एसई-लिनक्स कार्यान्वयन इससे अधिक परिमाण के संचालन आदेशों की संख्या का समर्थन करेंगे। उदाहरण के लिए एसई-लिनक्स सामान्यतः उन्हीं अनुमतियों का समर्थन करेगा। किन्तु इसमें एमकेनोड के लिए नियंत्रण, नेटवर्क सॉकेट्स के लिए बाइंडिंग, पोसिक्स क्षमताओं का निहित उपयोग, कर्नेल मॉड्यूल को लोड करना और उतारना, सम्मिलित मेमोरी तक पहुँचने के विभिन्न साधन आदि सम्मिलित हैं।
  • स्पष्ट रूप से पोसिक्स क्षमताओं को सीमित करने के लिए एपआर्मर में कोई नियंत्रण नहीं है। चूंकि क्षमताओं के वर्तमान कार्यान्वयन में ऑपरेशन (केवल अभिनेता और ऑपरेशन) के लिए किसी विषय की कोई धारणा नहीं है। यह सामान्यतः मैक पर्त का कार्य करता है। जो अभिनेता के नियंत्रण की सीमा (अर्थात् सैंडबॉक्स) के बाहर फाइलों पर विशेषाधिकार प्राप्त संचालन को रोकता है। एपआर्मर अपनी स्वयं की नीति को बदलने से रोक सकता है और फ़ाइल प्रणाली को माउंट/अनमाउंट होने से रोक सकता है। किन्तु उपयोगकर्ताओं को उनके नियंत्रण के स्वीकृत सीमा से बाहर जाने से रोकने के लिए कुछ भी नहीं करता है।
    • उदाहरण के लिए, हेल्प डेस्क के कर्मचारियों के लिए कुछ फाइलों पर स्वामित्व या अनुमतियों को बदलना लाभप्रद माना जा सकता है, तथापि वे उनके ओनर न हों (उदाहरण के लिए विभागीय फ़ाइल शेयर पर)। व्यवस्थापक उपयोगकर्ताओं को बॉक्स पर रूट एक्सेस नहीं देना चाहता है। इसलिए वे उन्हें CAP_FOWNER या CAP_DAC_OVERRIDE प्रदान करते हैं। एसई-लाइनेक्स के अंतर्गत व्यवस्थापक (या प्लेटफ़ॉर्म विक्रेता) एसई-लिनक्स को अन्यथा अपुष्ट उपयोगकर्ताओं के लिए सभी क्षमताओं से अस्वीकृत करने के लिए कॉन्फ़िगर कर सकता है। इसके पश्चात कर्मचारी के लिए लॉग इन करने के बाद संक्रमण करने में सक्षम होने के लिए सीमित डोमेन बना सकता है। एक जो उन क्षमताओं का प्रयोग कर सकता है। किन्तु केवल उपयुक्त प्रकार की फाइलों पर प्रयोग कर सकता है। [[[Category:All articles with unsourced statements]][citation needed]
  • एपआर्मर के साथ बहुस्तरीय सुरक्षा की कोई धारणा नहीं है। इस प्रकार कोई कठिन बेल-लापादुला मॉडल या बीबा मॉडल प्रवर्तन उपलब्ध नहीं है।[citation needed].
  • एपआर्मर कॉन्फ़िगरेशन केवल नियमित फ्लैट फ़ाइलों का उपयोग करके किया जाता है। एसई-लिनक्स (अधिकांश कार्यान्वयन में डिफ़ॉल्ट रूप से) समतल फ़ाइलों के संयोजन का उपयोग करता है। (प्रशासकों और डेवलपर्स द्वारा इसे संकलित करने से पहले मानव पठनीय नीति लिखने के लिए उपयोग किया जाता है) और विस्तारित विशेषताएँ।
  • एसई-लिनक्स एक दूरस्थ नीति सर्वर की अवधारणा का समर्थन करता है (configurable via /etc/selinux/semanage.conf के माध्यम से विन्यास योग्य) नीति विन्यास के लिए एक वैकल्पिक स्रोत के रूप में। एपआर्मर का केंद्रीय प्रबंधन सामान्यतः अधिक जटिल होता है क्योंकि प्रशासकों को कॉन्फ़िगरेशन परिनियोजन टूल को रूट के रूप में चलाने (पॉलिसी अपडेट की अनुमति देने के लिए) या प्रत्येक सर्वर पर मैन्युअल रूप से कॉन्फ़िगर करने के बीच निर्णय लेना चाहिए।

समान प्रणाली और संवर्द्धन

ऑपरेटिंग प्रणाली-स्तरीय वर्चुअलाइजेशन जैसे तंत्रों द्वारा प्रक्रियाओं का परिवर्तन भी पूरा किया जा सकता है। जैसे कि ओएलपीसी परियोजना। उदाहरण के लिए इसके पहले कार्यान्वयन में[36] सैंडबॉक्स (कंप्यूटर सुरक्षा) हल्के वीसर्वर में व्यक्तिगत अनुप्रयोग साथ ही एनएसए ने सुरक्षा-वर्धित एनडॉइड (ऑपरेटिंग प्रणाली) में कुछ एसई-लिनक्स अवधारणाओं को अपनाया है।[37]

सामान्य गतिशीलता पिटबुल ट्रस्टेड ऑपरेटिंग प्रणाली का निर्माण और वितरण करता है।[38] रेड हैट इन्टरप्राइज-लिनक्स के लिए एक बहुस्तरीय सुरक्षा (एमएलएस) संवर्द्धन।

बहु-श्रेणी सुरक्षा (एमसीएस) रेड हैट इन्टरप्राइज-लिनक्स के लिए एसई-लिनक्स का एक संवर्द्धन है। जो उपयोगकर्ताओं को विवेकाधीन अभिगम नियंत्रण और प्रकार प्रवर्तन के माध्यम से पहुँच को अधिक प्रतिबंधित करने के लिए श्रेणियों के साथ फाइलों को लेबल करने की अनुमति देता है। श्रेणियाँ बहुस्तरीय सुरक्षा (एमएलएस) द्वारा उपयोग किए जाने वाले संवेदनशीलता स्तरों के अन्तर्गत अतिरिक्त कम्पार्टमेंट प्रदान करती हैं।[39]


यह भी देखें

संदर्भ

  1. "Security-enhanced Linux available at NSA site - MARC". MARC. Retrieved 24 December 2018.
  2. "SELinux userspace release 20211022 / 3.3". SELinux Project. 2022-04-04. Retrieved 2022-04-04.
  3. "SELinux Frequently Asked Questions (FAQ) - NSA/CSS". National Security Agency. Archived from the original on 2018-09-18. Retrieved 2013-02-06.
  4. Loscocco, Peter; Smalley, Stephen (February 2001). "Linux ऑपरेटिंग सिस्टम में सुरक्षा नीतियों के लिए लचीले समर्थन को एकीकृत करना" (PDF).
  5. "Security-Enhanced Linux - NSA/CSS". National Security Agency. 2009-01-15. Archived from the original on 2020-10-22. Retrieved 2021-04-21.
  6. Compare "National Security Agency Shares Security Enhancements to Linux". NSA Press Release. Fort George G. Meade, Maryland: National Security Agency Central Security Service. 2001-01-02. Archived from the original on 2018-09-18. Retrieved 2021-04-21. The NSA is pleased to announce that it has developed, and is making available to the public, a prototype version of a security-enhanced Linux operating system.
  7. "SELinux के योगदानकर्ता". Archived from the original on 2008-10-18.
  8. Fedora Documentation Project (2010). Fedora 13 Security-Enhanced Linux User Guide. Fultus Corporation. p. 18. ISBN 978-1-59682-215-3. Retrieved 2012-02-22. SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). Caching decisions decreases how often SELinux rules need to checked, which increases performance.
  9. "SELinux/Quick introduction - Gentoo Wiki". wiki.gentoo.org.
  10. "SELinux के साथ आरंभ करना". Linode Guides & Tutorials (in English).
  11. "एनबी सिंहावलोकन - सेलिनक्स विकी". selinuxproject.org.
  12. "Android में सुरक्षा-उन्नत Linux". Android Open Source Project. Retrieved 2016-01-31.
  13. "सेलिनक्स". debian.org.
  14. "How To Install SELinux on Ubuntu 8.04 "Hardy Heron"". Ubuntu Tutorials.
  15. "ओपनएसयूएसई समाचार". 20 August 2008.
  16. "एसयूएसई लिनक्स एंटरप्राइज डेस्कटॉप 11 के लिए रिलीज नोट्स". Novell. Retrieved 2013-02-06.
  17. "कोरोस पर सेलिनक्स". CoreOS Docs.
  18. "SELinux/Commands - FedoraProject". Retrieved 2015-11-25.
  19. "chcon". Linuxcommand.org. Archived from the original on 2004-10-24. Retrieved 2013-02-06.
  20. "restorecon(8) - Linux man page". Linux.die.net. Retrieved 2013-02-06.
  21. "restorecond(8) - Linux man page". Linux.die.net. Retrieved 2013-02-06.
  22. "रनकॉन (1) - लिनक्स मैन पेज". Linux.die.net. Retrieved 2013-02-06.
  23. "दूसरा (1) - लिनक्स मैन पेज". Linux.die.net. Retrieved 2013-02-06.
  24. "fixfiles(8): fix file SELinux security contexts - Linux man page". Linux.die.net. Retrieved 2013-02-06.
  25. "setfiles(8): set file SELinux security contexts - Linux man page". Linux.die.net. Retrieved 2013-02-06.
  26. "load_policy(8) - Linux man page". Linux.die.net. Retrieved 2013-02-06.
  27. "booleans(8) - Linux man page". Linux.die.net. Retrieved 2013-02-06.
  28. "getsebool(8): SELinux boolean value - Linux man page". Linux.die.net. Retrieved 2013-02-06.
  29. "setsebool(8): set SELinux boolean value - Linux man page". Linux.die.net. Retrieved 2013-02-06.
  30. "togglesebool(8) - Linux man page". Linux.die.net. Retrieved 2013-02-06.
  31. "Ubuntu Manpage: selinux-config-enforcing - change /etc/selinux/config to set enforcing". Canonical Ltd. Archived from the original on 2012-12-20. Retrieved 2013-02-06.
  32. "Ubuntu Manpage: selinuxenabled - tool to be used within shell scripts to determine if". Canonical Ltd. Archived from the original on 2013-02-09. Retrieved 2013-02-06.
  33. "Ubuntu Manpage: selinux-policy-upgrade - upgrade the modules in the SE Linux policy". Canonical Ltd. Archived from the original on 2012-04-04. Retrieved 2013-02-06.
  34. "SELinux backgrounds". SELinux. Security Guide. SUSE.
  35. "apparmor.d - AppArmor के लिए सुरक्षा प्रोफाइल का सिंटैक्स". Archived from the original on 2013-10-17.
  36. "इंद्रधनुष". laptop.org.
  37. "SELinux संबंधित कार्य". NSA.gov. Archived from the original on 2018-02-20. Retrieved 2016-08-23.
  38. General Dynamics. "पिटबुल विश्वसनीय ऑपरेटिंग सिस्टम".
  39. Red Hat, Inc. "49.4. Multi-Category Security (MCS)".


बाहरी संबंध