SELinux अवधारणाएँ

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

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

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

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

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

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

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

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

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

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

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

प्रकार, विशेषताएँ और नियम

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

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

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

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

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

allow untrusted_app app_data_file:file { read write };

इसका कहना है कि ऐप्स को app_data_file लेबल वाली फ़ाइलों को पढ़ने और लिखने की अनुमति है। ऐप्स के लिए अन्य प्रकार मौजूद हैं। उदाहरण के लिए, isolated_app उपयोग उन ऐप सेवाओं के लिए किया जाता है जिनके मेनिफ़ेस्ट में isolatedProcess=true । दोनों प्रकारों के लिए नियम को दोहराने के बजाय, एंड्रॉइड उन सभी प्रकारों के लिए 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 अनुमति पर्याप्त नहीं है। नियम की परिभाषा को सरल बनाने के लिए, एंड्रॉइड सबसे सामान्य मामलों को संभालने के लिए मैक्रोज़ का एक सेट प्रदान करता है। उदाहरण के लिए, लापता अनुमतियों जैसे कि open को शामिल करने के लिए, उपरोक्त नियम को इस प्रकार फिर से लिखा जा सकता है:

allow appdomain app_data_file:file rw_file_perms;

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

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

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

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

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

विशेषता

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

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