SELinux अवधारणाएं

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

SELinux अवधारणाओं से परिचित होने के लिए इस पृष्ठ की समीक्षा करें।

अनिवार्य अभिगम नियंत्रण

सिक्योरिटी एन्हांस्ड लिनक्स (SELinux), Linux ऑपरेटिंग सिस्टम के लिए एक अनिवार्य एक्सेस कंट्रोल (MAC) सिस्टम है। मैक सिस्टम के रूप में, यह लिनक्स के परिचित विवेकाधीन एक्सेस कंट्रोल (डीएसी) सिस्टम से अलग है। एक डीएसी प्रणाली में, स्वामित्व की एक अवधारणा मौजूद होती है, जिसके तहत किसी विशेष संसाधन का मालिक इससे जुड़ी पहुंच अनुमतियों को नियंत्रित करता है। यह आम तौर पर मोटे अनाज वाला होता है और अनपेक्षित विशेषाधिकार वृद्धि के अधीन होता है। एक मैक प्रणाली, हालांकि, सभी एक्सेस प्रयासों पर निर्णय के लिए एक केंद्रीय प्राधिकरण से परामर्श करती है।

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

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

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

खतरों के अधिक उदाहरणों और SELinux के साथ उन्हें संबोधित करने के तरीकों के लिए मामलों का उपयोग करें देखें।

प्रवर्तन स्तर

SELinux को अलग-अलग मोड में लागू किया जा सकता है:

  • अनुमेय - SELinux सुरक्षा नीति लागू नहीं है, केवल लॉग की गई है।
  • लागू करना - सुरक्षा नीति लागू और लॉग की जाती है। विफलताएं EPERM त्रुटियों के रूप में प्रकट होती हैं।

यह विकल्प द्विआधारी है और यह निर्धारित करता है कि आपकी नीति कार्रवाई करती है या केवल आपको संभावित विफलताओं को इकट्ठा करने की अनुमति देती है। अनुमेय कार्यान्वयन के दौरान विशेष रूप से उपयोगी है।

प्रकार, गुण और नियम

Android अपनी नीति के लिए SELinux के प्रकार प्रवर्तन (TE) घटक पर निर्भर करता है। इसका मतलब है कि सभी ऑब्जेक्ट्स (जैसे, फ़ाइल, प्रोसेस या सॉकेट) के साथ एक प्रकार जुड़ा होता है। उदाहरण के लिए, डिफ़ॉल्ट रूप से, एक ऐप में untrusted_app प्रकार होगा। एक प्रक्रिया के लिए, इसके प्रकार को इसके डोमेन के रूप में भी जाना जाता है। एक या कई विशेषताओं वाले प्रकार को एनोटेट करना संभव है। विशेषताएँ एक ही समय में कई प्रकारों को संदर्भित करने के लिए उपयोगी होती हैं।

वस्तुओं को कक्षाओं में मैप किया जाता है (उदाहरण के लिए, एक फ़ाइल, एक निर्देशिका, एक प्रतीकात्मक लिंक, एक सॉकेट) और प्रत्येक वर्ग के लिए विभिन्न प्रकार की पहुंच अनुमतियों द्वारा दर्शायी जाती है। उदाहरण के लिए, क्लास file के लिए open की अनुमति मौजूद है। जबकि प्रकार और विशेषताओं को नियमित रूप से Android SELinux नीति के भाग के रूप में अद्यतन किया जाता है, अनुमतियों और वर्गों को सांख्यिकीय रूप से परिभाषित किया जाता है और शायद ही कभी किसी नए Linux रिलीज़ के भाग के रूप में अद्यतन किया जाता है।

एक नीति नियम इस रूप में आता है: allow source target : class permissions ; कहाँ पे:

  • स्रोत - नियम के विषय का प्रकार (या विशेषता)। प्रवेश का अनुरोध कौन कर रहा है?
  • लक्ष्य - वस्तु का प्रकार (या विशेषता)। किस तक पहुंच का अनुरोध किया गया है?
  • कक्षा - जिस प्रकार की वस्तु (जैसे फ़ाइल, सॉकेट) तक पहुँचा जा रहा है।
  • अनुमतियाँ - संचालन (या संचालन का सेट) (जैसे पढ़ना, लिखना) किया जा रहा है।

नियम का एक उदाहरण है:

allow untrusted_app app_data_file:file { read write };

यह कहता है कि ऐप्स को app_data_file लेबल वाली फ़ाइलों को पढ़ने और लिखने की अनुमति है। ऐप्स के लिए अन्य प्रकार मौजूद हैं। उदाहरण के लिए, isolated_app का उपयोग ऐप सेवाओं के लिए किया जाता है, जिसमें उनके मैनिफेस्ट में isolatedProcess=true होती है। दोनों प्रकार के लिए नियम दोहराने के बजाय, Android उन सभी प्रकारों के लिए appdomain नामक एक विशेषता का उपयोग करता है जो ऐप्स को कवर करता है:

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app, appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app, appdomain;

allow appdomain app_data_file:file { read write };

जब एक नियम लिखा जाता है जो एक विशेषता नाम निर्दिष्ट करता है, तो वह नाम स्वचालित रूप से डोमेन या विशेषता से जुड़े प्रकारों की सूची में विस्तारित हो जाता है। कुछ उल्लेखनीय विशेषताएं हैं:

  • domain - सभी प्रक्रिया प्रकारों से जुड़ी विशेषता,
  • file_type - सभी फ़ाइल प्रकारों से जुड़ी विशेषता।

मैक्रो

विशेष रूप से फ़ाइल पहुँच के लिए, विचार करने के लिए कई प्रकार की अनुमतियाँ हैं। उदाहरण के लिए, फ़ाइल को खोलने या stat पर कॉल करने के लिए read की अनुमति पर्याप्त नहीं है। नियम परिभाषा को सरल बनाने के लिए, Android सबसे सामान्य मामलों को संभालने के लिए मैक्रोज़ का एक सेट प्रदान करता है। उदाहरण के लिए, अनुपलब्ध अनुमतियों जैसे open को शामिल करने के लिए, ऊपर दिए गए नियम को इस प्रकार फिर से लिखा जा सकता है:

allow appdomain app_data_file:file rw_file_perms;

उपयोगी मैक्रो के अधिक उदाहरण के लिए global_macros और te_macros फ़ाइलें देखें। संबंधित अनुमतियों पर इनकार के कारण विफलताओं की संभावना को कम करने में मदद करने के लिए मैक्रोज़ का उपयोग जब भी संभव हो, किया जाना चाहिए।

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

सुरक्षा संदर्भ और श्रेणियाँ

SELinux नीतियों या लेबलिंग फ़ाइलों को डीबग करते समय ( file_contexts के माध्यम से या ls -Z चलाते समय), आप एक सुरक्षा संदर्भ (जिसे लेबल के रूप में भी जाना जाता है) में आ सकते हैं। उदाहरण के लिए: u:r:untrusted_app:s0:c15,c256,c513,c768 । सुरक्षा संदर्भ का प्रारूप है: user:role:type:sensitivity[:categories] । आप आमतौर पर किसी संदर्भ के user , role और sensitivity क्षेत्रों को अनदेखा कर सकते हैं ( विशिष्टता देखें)। type फ़ील्ड को पिछले अनुभाग में समझाया गया है। categories SELinux में बहु-स्तरीय सुरक्षा (MLS) समर्थन का हिस्सा हैं। Android S के बाद से, श्रेणियों का उपयोग किया जाता है:

  • ऐप डेटा को किसी अन्य ऐप द्वारा एक्सेस से अलग करें,
  • ऐप डेटा को एक भौतिक उपयोगकर्ता से दूसरे में अलग करें।

विशेषता

Android SELinux द्वारा प्रदान की गई सभी सुविधाओं का उपयोग नहीं करता है। बाहरी दस्तावेज़ पढ़ते समय, इन बातों का ध्यान रखें:

  • AOSP में अधिकांश नीतियों को कर्नेल नीति भाषा का उपयोग करके परिभाषित किया गया है। कॉमन इंटरमीडिएट लैंग्वेज (सीआईएल) का उपयोग करने के लिए कुछ अपवाद हैं।
  • SELinux उपयोगकर्ताओं का उपयोग नहीं किया जाता है। परिभाषित एकमात्र उपयोगकर्ता u है। जब आवश्यक हो, भौतिक उपयोगकर्ताओं को सुरक्षा संदर्भ के श्रेणियों के क्षेत्र का उपयोग करके दर्शाया जाता है।
  • SELinux भूमिकाएँ और भूमिका-आधारित अभिगम नियंत्रण (RBAC) का उपयोग नहीं किया जाता है। दो डिफ़ॉल्ट भूमिकाएँ परिभाषित और उपयोग की जाती हैं: विषयों के लिए r और वस्तुओं के लिए object_r
  • SELinux संवेदनशीलता का उपयोग नहीं किया जाता है। डिफ़ॉल्ट s0 संवेदनशीलता हमेशा सेट होती है।
  • SELinux बूलियन का उपयोग नहीं किया जाता है। एक बार डिवाइस के लिए पॉलिसी बन जाने के बाद, यह डिवाइस की स्थिति पर निर्भर नहीं करता है। यह नीतियों की ऑडिटिंग और डिबगिंग को सरल करता है।