SELinux के कॉन्सेप्ट के बारे में जानने के लिए, यह पेज पढ़ें.
अनिवार्य ऐक्सेस कंट्रोल
Security Enhanced Linux (SELinux), Linux ऑपरेटिंग सिस्टम के लिए ज़रूरी ऐक्सेस कंट्रोल (एमएसी) सिस्टम है. MAC सिस्टम होने की वजह से, यह Linux के जाने-पहचाने डिसक्रिशनरी ऐक्सेस कंट्रोल (डीएसी) सिस्टम से अलग है. डीएसी सिस्टम में, मालिकाना हक का सिद्धांत लागू होता है. इसके तहत, किसी संसाधन का मालिक उससे जुड़े ऐक्सेस के अधिकारों को कंट्रोल करता है. आम तौर पर, यह ज़्यादा जानकारी नहीं देता है. साथ ही, इससे अनचाहे तरीके से विशेषाधिकारों में बढ़ोतरी हो सकती है. हालांकि, एमएसी सिस्टम में, ऐक्सेस करने के सभी अनुरोधों पर फ़ैसला लेने के लिए, एक केंद्रीय संस्था से सलाह ली जाती है.
SELinux को Linux Security Module (LSM) फ़्रेमवर्क के हिस्से के तौर पर लागू किया गया है. यह फ़्रेमवर्क, अलग-अलग कर्नल ऑब्जेक्ट और उन पर की गई संवेदनशील कार्रवाइयों की पहचान करता है. इनमें से हर कार्रवाई के दौरान, एक एलएसएम हुक फ़ंक्शन को कॉल किया जाता है. इससे यह तय किया जाता है कि कार्रवाई की अनुमति दी जानी चाहिए या नहीं. यह फ़ंक्शन, ओपेक सुरक्षा ऑब्जेक्ट में सेव की गई जानकारी के आधार पर फ़ैसला लेता है. SELinux, इन हुक को लागू करने और इन सुरक्षा ऑब्जेक्ट को मैनेज करने की सुविधा देता है. ये ऑब्जेक्ट, SELinux की अपनी नीति के साथ मिलकर, ऐक्सेस से जुड़े फ़ैसले लेते हैं.
Android के ऐक्सेस कंट्रोल की नीति, Android की सुरक्षा से जुड़े अन्य उपायों के साथ मिलकर, हैक किए गए डिवाइसों और खातों से होने वाले नुकसान को काफ़ी हद तक कम करती है. Android के विवेकपूर्ण और ज़रूरी ऐक्सेस कंट्रोल जैसे टूल का इस्तेमाल करके, यह पक्का किया जा सकता है कि आपका सॉफ़्टवेयर सिर्फ़ कम से कम ज़रूरी लेवल पर काम करे. इससे हमलों का असर कम हो जाता है. साथ ही, गलत प्रोसेस के डेटा को बदलने या उसे ट्रांसमिट करने की संभावना कम हो जाती है.
Android 4.3 और इसके बाद के वर्शन में, SELinux, पारंपरिक डिसक्रिशनरी ऐक्सेस कंट्रोल (डीएसी) एनवायरमेंट के लिए, ज़रूरी ऐक्सेस कंट्रोल (एमएसी) की सुविधा देता है. उदाहरण के लिए, सॉफ़्टवेयर को आम तौर पर रूट उपयोगकर्ता खाते के तौर पर चलाना होता है, ताकि वह रॉ ब्लॉक डिवाइसों पर लिख सके. डीएसी पर आधारित Linux एनवायरमेंट में, अगर रूट उपयोगकर्ता से समझौता किया जाता है, तो वह उपयोगकर्ता हर रॉ ब्लॉक डिवाइस पर लिख सकता है. हालांकि, SELinux का इस्तेमाल इन डिवाइसों को लेबल करने के लिए किया जा सकता है. इससे रूट विशेषाधिकार वाली प्रोसेस, सिर्फ़ उन डिवाइसों पर लिख सकती है जिनके बारे में संबंधित नीति में बताया गया है. इस तरह, प्रोसेस किसी खास रॉ ब्लॉक डिवाइस के बाहर मौजूद डेटा और सिस्टम सेटिंग को नहीं बदल सकती.
धोखाधड़ी के ज़्यादा उदाहरण और SELinux की मदद से उनसे निपटने के तरीके जानने के लिए, इस्तेमाल के उदाहरण देखें.
नीति उल्लंघन ठीक करने के तरीके
SELinux को अलग-अलग मोड में लागू किया जा सकता है:
- अनुमति वाला मोड - SELinux की सुरक्षा नीति लागू नहीं की जाती है. इसे सिर्फ़ लॉग किया जाता है.
- लागू करना - सुरक्षा नीति लागू की जाती है और लॉग की जाती है. ये गड़बड़ियां, EPERM गड़बड़ियों के तौर पर दिखती हैं.
यह विकल्प बाइनरी होता है. इससे यह तय होता है कि आपकी नीति के तहत कार्रवाई की जाएगी या सिर्फ़ संभावित गड़बड़ियों की जानकारी इकट्ठा की जाएगी. सहमति लेने के लिए उपलब्ध विकल्पों में से किसी एक को चुनने की सुविधा, खास तौर पर लागू करने के दौरान काम आती है.
टाइप, एट्रिब्यूट, और नियम
Android, अपनी नीति के लिए SELinux के टाइप एनफ़ोर्समेंट (टीई) कॉम्पोनेंट पर निर्भर करता है. इसका मतलब है कि सभी ऑब्जेक्ट (जैसे, फ़ाइल, प्रोसेस या सॉकेट) से एक टाइप जुड़ा होता है. उदाहरण के लिए, डिफ़ॉल्ट रूप से किसी ऐप्लिकेशन का टाइप 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 Notebook देखें.
सुरक्षा कॉन्टेक्स्ट और कैटगरी
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 में ज़्यादातर नीतियां, कर्नल पॉलिसी लैंग्वेज का इस्तेमाल करके तय की जाती हैं. कॉमन इंटरमीडिएट लैंग्वेज (सीआईएल) का इस्तेमाल करने के लिए, कुछ अपवाद हैं.
- SELinux users का इस्तेमाल नहीं किया जाता. उपयोगकर्ता के लिए सिर्फ़
uतय किया गया है. ज़रूरत पड़ने पर, असली उपयोगकर्ताओं को सुरक्षा कॉन्टेक्स्ट के कैटगरी फ़ील्ड का इस्तेमाल करके दिखाया जाता है. - SELinux भूमिकाओं और भूमिका के हिसाब से ऐक्सेस कंट्रोल (आरबीएसी) का इस्तेमाल नहीं किया जाता है. दो डिफ़ॉल्ट भूमिकाएं तय की गई हैं और उनका इस्तेमाल किया गया है:
rविषयों के लिए औरobject_rऑब्जेक्ट के लिए. - SELinux की संवेदनशीलताओं का इस्तेमाल नहीं किया जाता.
s0की संवेदनशीलता हमेशा डिफ़ॉल्ट रूप से सेट होती है. - SELinux बूलियन का इस्तेमाल नहीं किया जाता. किसी डिवाइस के लिए नीति बनाते समय, यह डिवाइस की स्थिति पर निर्भर नहीं करती है. इससे नीतियों की ऑडिटिंग और डीबग करना आसान हो जाता है.