SELinux के कॉन्सेप्ट

SELinux के कॉन्सेप्ट के बारे में जानने के लिए, यह पेज पढ़ें.

ऐक्सेस कंट्रोल करना ज़रूरी है

बेहतर सुरक्षा वाला Linux (SELinux), Linux ऑपरेटिंग सिस्टम के लिए ज़रूरी ऐक्सेस कंट्रोल (MAC) सिस्टम है. यह एक MAC सिस्टम है, जो लिनक्स के डिस्क्रेशनरी ऐक्सेस कंट्रोल (डीएसी) सिस्टम से अलग है. डीएसी सिस्टम में, मालिकाना हक का एक सिद्धांत मौजूद होता है. इसके तहत, किसी खास संसाधन का मालिक, उससे जुड़ी ऐक्सेस अनुमतियों को कंट्रोल करता है. आम तौर पर, यह मोटे तौर पर होता है और अनजाने में ऐक्सेस लेवल बढ़ने की संभावना होती है. हालांकि, MAC सिस्टम, ऐक्सेस करने के सभी प्रयासों के बारे में फ़ैसला लेने के लिए, किसी केंद्रीय इकाई से सलाह लेता है.

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

Android की सुरक्षा से जुड़ी अन्य कार्रवाइयों के साथ-साथ, ऐक्सेस कंट्रोल की नीति की मदद से, हैक किए गए डिवाइसों और खातों से होने वाले नुकसान को काफ़ी हद तक कम किया जा सकता है. Android के ऐक्सेस कंट्रोल जैसे टूल का इस्तेमाल करके, यह पक्का किया जा सकता है कि आपका सॉफ़्टवेयर सिर्फ़ कम से कम अनुमति वाले लेवल पर काम करे. इससे हमलों के असर को कम किया जा सकता है. साथ ही, गड़बड़ी वाली प्रोसेस से डेटा को ओवरराइट करने या उसे ट्रांसफ़र करने की संभावना भी कम हो जाती है.

Android 4.3 और इसके बाद के वर्शन में, SELinux, डिसक्रेशनरी ऐक्सेस कंट्रोल (डीएसी) वाले पारंपरिक एनवायरमेंट के ऊपर, ज़रूरी ऐक्सेस कंट्रोल (एमएसी) वाला एक कवर उपलब्ध कराता है. उदाहरण के लिए, आम तौर पर रॉ ब्लॉक डिवाइसों में डेटा लिखने के लिए, सॉफ़्टवेयर को रूट उपयोगकर्ता खाते के तौर पर चलाना ज़रूरी होता है. डीएसी (डायरेक्ट एक्सेस कंट्रोल) पर आधारित पारंपरिक Linux एनवायरमेंट में, अगर रूट उपयोगकर्ता के खाते का ऐक्सेस किसी दूसरे व्यक्ति के पास चला जाता है, तो वह व्यक्ति हर रॉ ब्लॉक डिवाइस में डेटा लिख सकता है. हालांकि, इन डिवाइसों को लेबल करने के लिए 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 में मल्टी-लेवल सिक्योरिटी (एमएलएस) के साथ काम करते हैं. Android 12 और उसके बाद के वर्शन में, कैटगरी का इस्तेमाल इन कामों के लिए किया जाता है:

  • ऐप्लिकेशन के डेटा को किसी दूसरे ऐप्लिकेशन से ऐक्सेस होने से रोकना,
  • ऐप्लिकेशन का डेटा, एक उपयोगकर्ता से दूसरे उपयोगकर्ता के लिए अलग-अलग रखना.

विशेषता

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

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