नीति संगतता

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

यह लेख बताता है कि एंड्रॉइड प्लेटफॉर्म ओटीए के साथ नीति संगतता मुद्दों को कैसे संभालता है, जहां नया प्लेटफॉर्म SELinux सेटिंग्स पुराने विक्रेता SELinux सेटिंग्स से भिन्न हो सकती हैं।

ट्रेबल-आधारित SELinux नीति डिज़ाइन प्लेटफ़ॉर्म और विक्रेता नीति के बीच एक द्विआधारी अंतर को मानता है; योजना और अधिक जटिल हो जाती है यदि विक्रेता विभाजन निर्भरता उत्पन्न करता है, जैसे कि platform < vendor < oem ।

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

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

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

वस्तु स्वामित्व और लेबलिंग

एंड्रॉइड 8.0 और उच्चतर में नीति को अनुकूलित करते समय, प्लेटफ़ॉर्म और विक्रेता नीति को अलग रखने के लिए प्रत्येक ऑब्जेक्ट के लिए स्वामित्व को स्पष्ट रूप से परिभाषित किया जाना चाहिए। उदाहरण के लिए, यदि विक्रेता /dev/foo और प्लेटफॉर्म को बाद के OTA में लेबल करता है /dev/foo , तो अपरिभाषित व्यवहार होगा। SELinux के लिए, यह एक लेबलिंग टकराव के रूप में प्रकट होता है। डिवाइस नोड में केवल एक ही लेबल हो सकता है जो अंतिम रूप से लागू किए गए किसी भी लेबल का समाधान करता है। नतीजतन:

  • जिन प्रक्रियाओं को असफल रूप से लागू किए गए लेबल तक पहुंच की आवश्यकता होती है, वे संसाधन तक पहुंच खो देंगे।
  • फ़ाइल तक पहुँच प्राप्त करने वाली प्रक्रियाएँ टूट सकती हैं क्योंकि गलत डिवाइस नोड बनाया गया था।

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

लेबल टकराव के अलावा, SELinux प्रकार/विशेषता नाम भी टकरा सकते हैं। एक प्रकार/विशेषता नाम टकराव का परिणाम हमेशा पॉलिसी कंपाइलर त्रुटि में होगा।

नेमस्पेसिंग टाइप/एट्रिब्यूट करें

SELinux एक ही प्रकार/विशेषता की एकाधिक घोषणाओं की अनुमति नहीं देता है। डुप्लिकेट घोषणाओं वाली नीति संकलन में विफल हो जाएगी। प्रकार और विशेषता नाम टकराव से बचने के लिए, सभी विक्रेता घोषणाओं को np_ से शुरू करके नामित किया जाना चाहिए।

type foo, domain; → type np_foo, domain;

सिस्टम संपत्ति और प्रक्रिया लेबलिंग स्वामित्व

प्रॉपर्टी नेमस्पेस का उपयोग करके लेबलिंग टकराव से बचना सबसे अच्छा है। प्लेटफ़ॉर्म गुणों की आसानी से पहचान करने और निर्यात-प्लेटफ़ॉर्म गुणों का नाम बदलने या जोड़ने पर नाम के विरोध से बचने के लिए, सुनिश्चित करें कि सभी विक्रेता गुणों के अपने उपसर्ग हैं:

सम्पत्ती के प्रकार स्वीकार्य उपसर्ग
नियंत्रण गुण ctl.vendor.
ctl.start$vendor.
ctl.stop$vendor.
init.svc.vendor.
पढ़ने लिखने योग्य vendor.
सिफ़ पढ़िये ro.vendor.
ro.boot.
ro.hardware.
ज़िद्दी persist.vendor.

विक्रेता ro.boot.* (जो कर्नेल cmdline से आता है) और ro.hardware.* (एक स्पष्ट हार्डवेयर-संबंधित गुण) का उपयोग करना जारी रख सकते हैं।

इनिट आरसी फाइलों में सभी विक्रेता सेवाओं में वेंडर होना चाहिए vendor. गैर-सिस्टम विभाजन की init आरसी फाइलों में सेवाओं के लिए। विक्रेता गुणों के लिए vendor_ लेबल पर समान नियम लागू होते हैं (विक्रेता गुणों के लिए विक्रेता_)।

फ़ाइल स्वामित्व

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

सिस्टम (/ सिस्टम)

केवल सिस्टम छवि को file_contexts , service_contexts , आदि के माध्यम से /system घटकों के लिए लेबल प्रदान करना चाहिए। यदि /system घटकों के लिए लेबल /vendor vendor नीति में जोड़े जाते हैं, तो केवल फ्रेमवर्क-ओटीए अपडेट संभव नहीं हो सकता है।

विक्रेता (/ विक्रेता)

AOSP SELinux नीति पहले से ही vendor विभाजन के उन हिस्सों को लेबल करती है जिनके साथ प्लेटफ़ॉर्म इंटरैक्ट करता है, जो प्लेटफ़ॉर्म प्रक्रियाओं के लिए SELinux नियम लिखने में सक्षम बनाता है ताकि वे vendor विभाजन के कुछ हिस्सों पर बात कर सकें और/या एक्सेस कर सकें। उदाहरण:

/vendor पथ प्लेटफ़ॉर्म-प्रदत्त लेबल लेबल के आधार पर प्लेटफ़ॉर्म प्रक्रियाएँ
/vendor(/. * )? vendor_file फ्रेमवर्क, ueventd आदि में सभी HAL क्लाइंट।
/vendor/framework(/. * )? vendor_framework_file dex2oat , appdomain , आदि।
/vendor/app(/. * )? vendor_app_file dex2oat , installd , idmap , आदि।
/vendor/overlay(/. * ) vendor_overlay_file system_server , zygote , idmap , आदि।

परिणामस्वरूप, vendor विभाजन में अतिरिक्त फ़ाइलों को लेबल करते समय विशिष्ट नियमों का पालन किया जाना चाहिए ( neverallows के माध्यम से लागू):

  • vendor विभाजन में सभी फाइलों के लिए विक्रेता_फाइल डिफ़ॉल्ट vendor_file होना चाहिए। प्लेटफ़ॉर्म नीति के लिए इसे पासथ्रू एचएएल कार्यान्वयन तक पहुँचने की आवश्यकता है।
  • विक्रेता vendor_file_type के माध्यम से vendor विभाजन में जोड़े गए सभी नए exec_types में विक्रेता_फाइल_टाइप विशेषता होनी चाहिए। यह कभी नहीं की अनुमति के माध्यम से लागू किया जाता है।
  • भविष्य के प्लेटफ़ॉर्म/फ्रेमवर्क अपडेट के साथ विरोध से बचने के लिए, vendor विभाजन में exec_types के अलावा अन्य फ़ाइलों को लेबल करने से बचें।
  • एओएसपी-पहचाने गए समान प्रक्रिया एचएएल के लिए सभी लाइब्रेरी निर्भरता को same_process_hal_file.

प्रॉफ़्स (/ प्रोक)

/proc में फ़ाइलें केवल genfscon लेबल का उपयोग करके लेबल की जा सकती हैं। Android 7.0 में, प्लेटफ़ॉर्म और विक्रेता नीति दोनों ने procfs में फ़ाइलों को लेबल करने के लिए genfscon का उपयोग किया।

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

डिबगफ़्स (/sys/कर्नेल/डीबग)

Debugfs को file_contexts और genfscon दोनों में लेबल किया जा सकता है। Android 7.0 से Android 10 में, प्लेटफ़ॉर्म और विक्रेता दोनों ही debugfs लेबल करते हैं।

Android 11 में, debugfs को उत्पादन उपकरणों पर एक्सेस या माउंट नहीं किया जा सकता है। डिवाइस निर्माताओं को debugfs को हटा देना चाहिए।

Tracefs (/sys/कर्नेल/डीबग/ट्रेसिंग)

Tracefs को file_contexts और genfscon दोनों में लेबल किया जा सकता है। एंड्रॉइड 7.0 में, केवल प्लेटफ़ॉर्म tracefs को लेबल करता है।

अनुशंसा: केवल प्लेटफ़ॉर्म tracefs को लेबल कर सकता है।

Sysfs (/ sys)

/sys में फ़ाइलें file_contexts और genfscon दोनों का उपयोग करके लेबल की जा सकती हैं। एंड्रॉइड 7.0 में, प्लेटफॉर्म और विक्रेता दोनों sysfs में फाइलों को लेबल करने के लिए file_contexts और genfscon का उपयोग करते हैं।

अनुशंसा: प्लेटफ़ॉर्म sysfs नोड्स को लेबल कर सकता है जो डिवाइस-विशिष्ट नहीं हैं। अन्यथा, केवल विक्रेता ही फाइलों को लेबल कर सकता है।

tmpfs (/ देव)

/dev में फ़ाइलें file_contexts में लेबल की जा सकती हैं। Android 7.0 में, प्लेटफ़ॉर्म और विक्रेता दोनों यहाँ लेबल फ़ाइलें करते हैं।

अनुशंसा: विक्रेता केवल फाइलों को /dev/vendor (जैसे, /dev/vendor/foo , /dev/vendor/socket/bar ) में लेबल कर सकता है।

रूटफ्स (/)

/ में फ़ाइलें file_contexts में लेबल की जा सकती हैं। Android 7.0 में, प्लेटफ़ॉर्म और विक्रेता दोनों यहाँ लेबल फ़ाइलें करते हैं।

अनुशंसा: केवल सिस्टम ही फाइलों को / में लेबल कर सकता है।

डेटा (/ डेटा)

डेटा को file_contexts और seapp_contexts के संयोजन के माध्यम से लेबल किया जाता है।

अनुशंसा: विक्रेता को /data/vendor के बाहर लेबल लगाने की अनुमति न दें। केवल प्लेटफ़ॉर्म /data के अन्य भागों को लेबल कर सकता है।

संगतता गुण

SELinux नीति विशिष्ट वस्तु वर्गों और अनुमतियों के लिए स्रोत और लक्ष्य प्रकारों के बीच की बातचीत है। SELinux नीति से प्रभावित प्रत्येक वस्तु (प्रक्रियाएँ, फ़ाइलें, आदि) में केवल एक प्रकार हो सकता है, लेकिन उस प्रकार में कई विशेषताएँ हो सकती हैं।

पॉलिसी ज्यादातर मौजूदा प्रकारों के संदर्भ में लिखी जाती है:

allow source_type target_type:target_class permission(s);

यह काम करता है क्योंकि नीति सभी प्रकार के ज्ञान के साथ लिखी गई थी। हालाँकि, यदि विक्रेता नीति और प्लेटफ़ॉर्म नीति विशिष्ट प्रकारों का उपयोग करती है, और किसी विशिष्ट वस्तु का लेबल उन नीतियों में से केवल एक में बदलता है, तो दूसरे में ऐसी नीति हो सकती है जो पहले प्राप्त की गई या खो गई हो। उदाहरण के लिए:

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

में बदला जा सकता है:

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

हालांकि विक्रेता नीति वही रहेगी, नए sysfs_A प्रकार के लिए नीति की कमी के कारण v_domain पहुंच खो देगा।

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

सार्वजनिक नीति को संस्करणबद्ध विशेषताओं के रूप में परिभाषित करना दो नीति संगतता लक्ष्यों को पूरा करता है:

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

नीति लेखन योग्यता

नीति विकास के लिए विशिष्ट संस्करण परिवर्तनों के ज्ञान की आवश्यकता नहीं होने के लक्ष्य को पूरा करने के लिए, एंड्रॉइड 8.0 में प्लेटफ़ॉर्म-सार्वजनिक नीति प्रकारों और उनकी विशेषताओं के बीच मैपिंग शामिल है। टाइप foo को foo_v N विशेषता के लिए मैप किया गया है, जहां N लक्षित संस्करण है। vN PLATFORM_SEPOLICY_VERSION बिल्ड वैरिएबल से मेल खाता है और MM.NN फॉर्म का है, जहां MM प्लेटफॉर्म SDK नंबर से मेल खाता है और NN एक प्लेटफॉर्म सेपॉलिसी विशिष्ट संस्करण है।

सार्वजनिक नीति में विशेषताएँ संस्करणबद्ध नहीं हैं, बल्कि एक एपीआई के रूप में मौजूद हैं, जिस पर दो विभाजनों के बीच इंटरफेस को स्थिर रखने के लिए मंच और विक्रेता नीति का निर्माण किया जा सकता है। मंच और विक्रेता नीति लेखक दोनों नीति लिखना जारी रख सकते हैं जैसा कि आज लिखा गया है।

प्लेटफार्म-सार्वजनिक नीति को allow source_foo target_bar: class perm ; विक्रेता नीति के हिस्से के रूप में शामिल है। संकलन के दौरान (जिसमें संबंधित संस्करण शामिल है) इसे उस नीति में बदल दिया जाता है जो डिवाइस के विक्रेता हिस्से में जाएगी (रूपांतरित सामान्य इंटरमीडिएट भाषा (सीआईएल) में दिखाया गया है):

 (allow source_foo_vN target_bar_vN (class (perm)))

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

नीति भिन्न होती है

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

(typeattributeset foo_vN (foo))

प्लेटफार्म उन्नयन

प्लेटफ़ॉर्म अपग्रेड के लिए निम्न अनुभाग विवरण परिदृश्य।

एक ही प्रकार

यह परिदृश्य तब होता है जब कोई ऑब्जेक्ट नीति संस्करणों में लेबल नहीं बदलता है। यह स्रोत और लक्ष्य प्रकारों के लिए समान है और इसे /dev/binder binder के साथ देखा जा सकता है, जिसे सभी रिलीज में binder_device लेबल किया गया है। इसे रूपांतरित नीति में इस प्रकार दर्शाया गया है:

binder_device_v1 … binder_device_vN

v1 → v2 से अपग्रेड करते समय, प्लेटफ़ॉर्म नीति में निम्न शामिल होना चाहिए:

type binder_device; -> (type binder_device) (in CIL)

V1 मैपिंग फ़ाइल (CIL) में:

(typeattributeset binder_device_v1 (binder_device))

V2 मैपिंग फ़ाइल (CIL) में:

(typeattributeset binder_device_v2 (binder_device))

v1 विक्रेता नीति (CIL) में:

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

v2 विक्रेता नीति (सीआईएल) में:

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
नए प्रकार

यह परिदृश्य तब होता है जब प्लेटफ़ॉर्म ने एक नया प्रकार जोड़ा है, जो नई सुविधाओं को जोड़ने या नीति सख्त होने के दौरान हो सकता है।

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

v1 → v2 से अपग्रेड करते समय, प्लेटफ़ॉर्म नीति में निम्न शामिल होना चाहिए:

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

V1 मैपिंग फ़ाइल (CIL) में:

(typeattributeset sysfs_v1 (sysfs sysfs_A))

V2 मैपिंग फ़ाइल (CIL) में:

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

v1 विक्रेता नीति (CIL) में:

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

v2 विक्रेता नीति (सीआईएल) में:

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
हटाए गए प्रकार

यह (दुर्लभ) परिदृश्य तब होता है जब एक प्रकार को हटा दिया जाता है, जो तब हो सकता है जब अंतर्निहित वस्तु:

  • रहता है लेकिन एक अलग लेबल मिलता है।
  • मंच से हटा दिया जाता है।

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

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

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

उदाहरण संस्करण 1: संक्षिप्त प्रकार (sysfs_A को हटा रहा है)

v1 → v2 से अपग्रेड करते समय, प्लेटफ़ॉर्म नीति में निम्न शामिल होना चाहिए:

type sysfs; (type sysfs) (in CIL)

V1 मैपिंग फ़ाइल (CIL) में:

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

V2 मैपिंग फ़ाइल (CIL) में:

(typeattributeset sysfs_v2 (sysfs))

v1 विक्रेता नीति (CIL) में:

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

v2 विक्रेता नीति (सीआईएल) में:

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

उदाहरण संस्करण 2: पूरी तरह से हटाना (फू प्रकार)

v1 → v2 से अपग्रेड करते समय, प्लेटफ़ॉर्म नीति में निम्न शामिल होना चाहिए:

# nothing - we got rid of the type

V1 मैपिंग फ़ाइल (CIL) में:

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

V2 मैपिंग फ़ाइल (CIL) में:

# nothing - get rid of it

v1 विक्रेता नीति (CIL) में:

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

v2 विक्रेता नीति (सीआईएल) में:

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
नई कक्षा / अनुमतियाँ

यह परिदृश्य तब होता है जब कोई प्लेटफ़ॉर्म नवीनीकरण नए नीति घटकों का परिचय देता है जो पिछले संस्करणों में मौजूद नहीं हैं। उदाहरण के लिए, जब एंड्रॉइड ने servicemanager ऑब्जेक्ट मैनेजर को जोड़ा, जिसने ऐड, फाइंड और लिस्ट की अनुमतियां बनाईं, तो वेंडर डेमॉन को servicemanager के साथ रजिस्टर करने के लिए उन अनुमतियों की आवश्यकता थी जो उपलब्ध नहीं थीं। Android 8.0 में, केवल प्लेटफ़ॉर्म नीति ही नई कक्षाएं और अनुमतियाँ जोड़ सकती है।

बिना किसी रुकावट के नए वर्ग का उपयोग करने के लिए विक्रेता नीति द्वारा बनाए या विस्तारित किए जा सकने वाले सभी डोमेन को अनुमति देने के लिए, प्लेटफ़ॉर्म नीति में निम्न के समान नियम शामिल करने की आवश्यकता है:

allow {domain -coredomain} *:new_class perm;

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

हटाई गई कक्षा/अनुमतियाँ

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

नए/पुनः लेबल किए गए प्रकारों के लिए विक्रेता अनुकूलन

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

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

Android 9 . के लिए विशेषता परिवर्तन

Android 9 में अपग्रेड करने वाले डिवाइस निम्न विशेषताओं का उपयोग कर सकते हैं, लेकिन Android 9 के साथ लॉन्च होने वाले डिवाइस को ऐसा नहीं करना चाहिए।

उल्लंघन करने वाले गुण

Android 9 में ये डोमेन-संबंधी विशेषताएँ शामिल हैं:

  • data_between_core_and_vendor_violators । vendor और coredomains के बीच पथ द्वारा फ़ाइलें साझा न करने की आवश्यकता का उल्लंघन करने वाले सभी डोमेन के लिए विशेषता। प्लेटफ़ॉर्म और विक्रेता प्रक्रियाओं को संचार (अस्थिर ABI) के लिए ऑन-डिस्क फ़ाइलों का उपयोग नहीं करना चाहिए। अनुशंसा:
    • विक्रेता कोड /data/vendor का उपयोग करना चाहिए।
    • सिस्टम को /data/vendor का उपयोग नहीं करना चाहिए।
  • system_executes_vendor_violators । सभी सिस्टम डोमेन के लिए विशेषता ( init और shell domains को छोड़कर) जो विक्रेता बायनेरिज़ को निष्पादित नहीं करने की आवश्यकता का उल्लंघन करते हैं। विक्रेता बायनेरिज़ के निष्पादन में अस्थिर एपीआई है। प्लेटफ़ॉर्म को विक्रेता बायनेरिज़ को सीधे निष्पादित नहीं करना चाहिए। अनुशंसा:
    • वेंडर बायनेरिज़ पर ऐसी प्लेटफ़ॉर्म निर्भरता HIDL HALs के पीछे होनी चाहिए।

      या

    • coredomains जिन्हें विक्रेता बायनेरिज़ तक पहुंच की आवश्यकता होती है, उन्हें विक्रेता विभाजन में ले जाया जाना चाहिए और इस प्रकार, coredomain बंद कर देना चाहिए।

अविश्वसनीय गुण

अविश्वसनीय ऐप्स जो मनमाने कोड को होस्ट करते हैं, उनके पास HwBinder सेवाओं तक पहुंच नहीं होनी चाहिए, सिवाय उन ऐप्स के जो ऐसे ऐप्स से एक्सेस के लिए पर्याप्त रूप से सुरक्षित माने जाते हैं (नीचे सुरक्षित सेवाएं देखें)। इसके दो मुख्य कारण हैं:

  1. HwBinder सर्वर क्लाइंट प्रमाणीकरण नहीं करते हैं क्योंकि HIDL वर्तमान में कॉलर UID जानकारी को उजागर नहीं करता है। भले ही HIDL ने इस तरह के डेटा को उजागर किया हो, कई HwBinder सेवाएं या तो ऐप (जैसे, HAL) से नीचे के स्तर पर काम करती हैं या प्राधिकरण के लिए ऐप पहचान पर निर्भर नहीं होनी चाहिए। इस प्रकार, सुरक्षित होने के लिए, डिफ़ॉल्ट धारणा यह है कि प्रत्येक HwBinder सेवा अपने सभी ग्राहकों को सेवा द्वारा प्रस्तावित संचालन करने के लिए समान रूप से अधिकृत मानती है।
  2. HAL सर्वर (HwBinder सेवाओं का एक सबसेट) में system/core घटकों की तुलना में सुरक्षा मुद्दों की उच्च घटना दर वाला कोड होता है और स्टैक की निचली परतों तक पहुंच होती है (हार्डवेयर तक सभी तरह से) इस प्रकार Android सुरक्षा मॉडल को दरकिनार करने के अवसर बढ़ते हैं .

सुरक्षित सेवाएं

सुरक्षित सेवाओं में शामिल हैं:

  • same_process_hwservice । ये सेवाएं (परिभाषा के अनुसार) क्लाइंट की प्रक्रिया में चलती हैं और इस प्रकार क्लाइंट डोमेन के समान पहुंच होती है जिसमें प्रक्रिया चलती है।
  • coredomain_hwservice . ये सेवाएं #2 कारण से जुड़े जोखिम नहीं उठाती हैं।
  • hal_configstore_ISurfaceFlingerConfigs । यह सेवा विशेष रूप से किसी भी डोमेन द्वारा उपयोग के लिए डिज़ाइन की गई है।
  • hal_graphics_allocator_hwservice . ये ऑपरेशन surfaceflinger बाइंडर सेवा द्वारा भी पेश किए जाते हैं, जिन ऐप्स को एक्सेस करने की अनुमति है।
  • hal_omx_hwservice . यह mediacodec बाइंडर सेवा का HwBinder संस्करण है, जिसमें ऐप्स को एक्सेस करने की अनुमति है।
  • hal_codec2_hwservice . यह hal_omx_hwservice का नया संस्करण है।

प्रयोग करने योग्य गुण

सुरक्षित नहीं मानी जाने वाली सभी hwservices में untrusted_app_visible_hwservice विशेषता होती है। संबंधित एचएएल सर्वर में untrusted_app_visible_halserver विशेषता होती है। Android 9 के साथ लॉन्च होने वाले डिवाइस को या तो untrusted विशेषता का उपयोग नहीं करना चाहिए।

अनुशंसा:

  • अविश्वसनीय ऐप्स को इसके बजाय एक सिस्टम सेवा से बात करनी चाहिए जो विक्रेता HIDL HAL से बात करती है। उदाहरण के लिए, ऐप्स binderservicedomain से बात कर सकते हैं, फिर mediaserver (जो कि binderservicedomain है) बदले में hal_graphics_allocator से बात करता है।

    या

  • जिन ऐप्स को vendor एचएएल तक सीधी पहुंच की आवश्यकता होती है, उनके पास अपना स्वयं का विक्रेता-परिभाषित सेपॉलिसी डोमेन होना चाहिए।

फ़ाइल विशेषता परीक्षण

एंड्रॉइड 9 में बिल्ड टाइम टेस्ट शामिल हैं जो सुनिश्चित करते हैं कि विशिष्ट स्थानों की सभी फाइलों में उपयुक्त विशेषताएं हैं (जैसे, sysfs की सभी फाइलों में आवश्यक sysfs_type विशेषता है)।

मंच-सार्वजनिक नीति

प्लेटफ़ॉर्म-सार्वजनिक नीति केवल v1 और v2 से प्लेटफ़ॉर्म नीतियों के मिलन को बनाए बिना Android 8.0 आर्किटेक्चर मॉडल के अनुरूप होने का मूल है। विक्रेताओं को प्लेटफ़ॉर्म नीति के एक सबसेट के संपर्क में लाया जाता है जिसमें उन प्रकारों और विशेषताओं पर उपयोग करने योग्य प्रकार और विशेषताएँ और नियम होते हैं जो तब विक्रेता नीति का हिस्सा बन जाते हैं (अर्थात vendor_sepolicy.cil )।

प्रकार और नियम स्वचालित रूप से विक्रेता-जनित नीति में विशेषता_v attribute_v N में अनुवादित होते हैं, जैसे कि सभी प्लेटफ़ॉर्म-प्रदत्त प्रकार संस्करणित विशेषताएँ हैं (हालाँकि विशेषताएँ संस्करणित नहीं हैं)। प्लेटफ़ॉर्म यह सुनिश्चित करने के लिए कि विक्रेता नीति कार्य करना जारी रखे और किसी विशेष संस्करण के लिए प्रदान किए गए नियम शामिल हैं, यह सुनिश्चित करने के लिए उपयुक्त विशेषताओं में प्रदान किए गए ठोस प्रकारों की मैपिंग के लिए ज़िम्मेदार है। प्लेटफ़ॉर्म-सार्वजनिक नीति और विक्रेता नीति का संयोजन स्वतंत्र प्लेटफ़ॉर्म और विक्रेता निर्माण की अनुमति देने के Android 8.0 आर्किटेक्चर मॉडल लक्ष्य को संतुष्ट करता है।

विशेषता श्रृंखलाओं के लिए मानचित्रण

नीति संस्करणों में मैप करने के लिए विशेषताओं का उपयोग करते समय, एक प्रकार एक विशेषता या कई विशेषताओं के लिए मैप करता है, यह सुनिश्चित करता है कि प्रकार के साथ लेबल की गई वस्तुएं उनके पिछले प्रकारों से संबंधित विशेषताओं के माध्यम से पहुंच योग्य हैं।

नीति लेखक से संस्करण जानकारी छिपाने के लक्ष्य को बनाए रखने का अर्थ है स्वचालित रूप से संस्करणित विशेषताओं को उत्पन्न करना और उन्हें उपयुक्त प्रकारों को निर्दिष्ट करना। स्थिर प्रकारों के सामान्य मामले में, यह सीधा है: type_foo मानचित्र से type_foo_v1 ।

ऑब्जेक्ट लेबल परिवर्तन जैसे sysfs → sysfs_A या mediaserver → audioserver के लिए, इस मैपिंग को बनाना गैर-तुच्छ है (और ऊपर के उदाहरणों में वर्णित है)। प्लेटफ़ॉर्म नीति अनुरक्षकों को यह निर्धारित करना चाहिए कि ऑब्जेक्ट्स के लिए ट्रांज़िशन पॉइंट्स पर मैपिंग कैसे बनाई जाए, जिसके लिए ऑब्जेक्ट्स और उनके असाइन किए गए लेबल के बीच संबंध को समझने और यह निर्धारित करने की आवश्यकता होती है कि ऐसा कब होता है। पश्चगामी संगतता के लिए, इस जटिलता को प्लेटफ़ॉर्म की ओर से प्रबंधित करने की आवश्यकता है, जो कि एकमात्र विभाजन है जो ऊपर जा सकता है।

संस्करण uprevs

सरलता के लिए, जब कोई नई रिलीज़ शाखा काट दी जाती है, तो Android प्लेटफ़ॉर्म एक सेपॉलिसी संस्करण जारी करता है। जैसा कि ऊपर वर्णित है, संस्करण संख्या PLATFORM_SEPOLICY_VERSION में निहित है और MM.nn के रूप में है, जहां MM SDK मान से मेल खाती है और nn एक निजी मान है जिसे /platform/system/sepolicy. उदाहरण के लिए, किटकैट के लिए 19.0 , लॉलीपॉप के लिए 21.0 , मार्शमैलो के लिए लॉलीपॉप-एमआर1 23.0 के लिए 22.0 , नूगट के लिए 24.0 , नूगट-एमआर1 के लिए 25.0 , ओरियो के लिए 26.0 , ओरियो-एमआर1 के लिए 27.0 और एंड्रॉइड 9 के लिए 28.0 अपग्रेड नहीं हैं। हमेशा पूर्ण संख्याएँ। उदाहरण के लिए, यदि किसी संस्करण में MR टक्कर के लिए system/sepolicy/public में असंगत परिवर्तन की आवश्यकता होती है, लेकिन API बंप नहीं, तो वह sepolicy संस्करण हो सकता है: vN.1 । एक विकास शाखा में मौजूद संस्करण एक कभी न इस्तेमाल होने वाला-इन-शिपिंग-डिवाइस 10000.0 है।

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

कई विशेषताओं का प्रदर्शन प्रभाव

जैसा कि https://github.com/SELinuxProject/cil/issues/9 में वर्णित है, एक प्रकार के लिए असाइन की गई विशेषताओं की एक बड़ी संख्या पॉलिसी कैश मिस होने की स्थिति में प्रदर्शन के मुद्दों में परिणाम देती है।

यह एंड्रॉइड में एक समस्या होने की पुष्टि की गई थी, इसलिए पॉलिसी कंपाइलर द्वारा पॉलिसी में जोड़े गए विशेषताओं को हटाने के साथ-साथ अप्रयुक्त विशेषताओं को हटाने के लिए एंड्रॉइड 8.0 में बदलाव किए गए थे । इन परिवर्तनों ने प्रदर्शन प्रतिगमन को हल किया।

System_ext सार्वजनिक और उत्पाद सार्वजनिक नीति

एंड्रॉइड 11 से शुरू होकर, system_ext और उत्पाद विभाजन को उनके निर्दिष्ट सार्वजनिक प्रकारों को विक्रेता विभाजन में निर्यात करने की अनुमति है। प्लेटफ़ॉर्म सार्वजनिक नीति की तरह, विक्रेता स्वचालित रूप से संस्करणित विशेषताओं में अनुवादित प्रकारों और नियमों का उपयोग करता है, उदाहरण के लिए type से type_ N में, जहां N प्लेटफ़ॉर्म का संस्करण है जिसके विरुद्ध विक्रेता विभाजन बनाया गया है।

जब system_ext और उत्पाद विभाजन एक ही प्लेटफ़ॉर्म संस्करण N पर आधारित होते हैं, तो बिल्ड सिस्टम system_ext/etc/selinux/mapping/ N .cil और product/etc/selinux/mapping/ N .cil के लिए आधार मानचित्रण फ़ाइलें उत्पन्न करता है, जिसमें पहचान होती है type से type_ N में मैपिंग। वेंडर वर्जनेड एट्रिब्यूट type_ N के साथ type एक्सेस कर सकता है।

यदि केवल system_ext और उत्पाद विभाजन अद्यतन किए जाते हैं, तो N से N+1 (या बाद में) कहें, जबकि विक्रेता N पर रहता है, विक्रेता system_ext और उत्पाद विभाजन के प्रकारों तक पहुंच खो सकता है। टूट-फूट को रोकने के लिए, system_ext और उत्पाद विभाजन को विशिष्ट प्रकारों से type_ N विशेषताओं में मैपिंग फ़ाइलें प्रदान करनी चाहिए। यदि वे N+1 (या बाद में) system_ext और उत्पाद विभाजन के साथ N विक्रेता का समर्थन करने जा रहे हैं, तो मैपिंग फ़ाइलों को बनाए रखने के लिए प्रत्येक भागीदार जिम्मेदार है।

ऐसा करने के लिए, भागीदारों से अपेक्षा की जाती है:

  1. N system_ext और उत्पाद विभाजन से उत्पन्न आधार मैपिंग फ़ाइलों को उनके स्रोत ट्री में कॉपी करें।
  2. आवश्यकतानुसार मैपिंग फाइलों में संशोधन करें।
  3. मैपिंग फ़ाइलों को N+1 (या बाद में) system_ext और उत्पाद विभाजन में स्थापित करें।

उदाहरण के लिए, मान लें कि N system_ext में एक सार्वजनिक प्रकार है जिसका नाम foo_type है। तब system_ext/etc/selinux/mapping/ N .cil N system_ext विभाजन में ऐसा दिखेगा:

(typeattributeset foo_type_N (foo_type))
(expandtypeattribute foo_type_N true)
(typeattribute foo_type_N)

यदि bar_type को N+1 system_ext में जोड़ा जाता है, और यदि bar_type को N विक्रेता के लिए foo_type में मैप किया जाना चाहिए, तो N .cil से अपडेट किया जा सकता है

(typeattributeset foo_type_N (foo_type))

को

(typeattributeset foo_type_N (foo_type bar_type))

और उसके बाद N+1 system_ext के विभाजन में संस्थापित किया गया। N विक्रेता N+1 system_ext के foo_type और bar_type तक पहुंच जारी रख सकता है।

SELinux संदर्भ लेबलिंग

प्लेटफ़ॉर्म और विक्रेता सेपॉलिसी के बीच अंतर का समर्थन करने के लिए, सिस्टम SELinux संदर्भ फ़ाइलों को अलग-अलग रखने के लिए अलग-अलग बनाता है।

फ़ाइल संदर्भ

Android 8.0 ने file_contexts के लिए निम्नलिखित परिवर्तन प्रस्तुत किए:

  • बूट के दौरान डिवाइस पर अतिरिक्त संकलन ओवरहेड से बचने के लिए, बाइनरी रूप में file_contexts का अस्तित्व समाप्त हो जाता है। इसके बजाय, वे पठनीय, रेगुलर एक्सप्रेशन टेक्स्ट फ़ाइल हैं जैसे {property, service}_contexts (क्योंकि वे पूर्व-7.0 थे)।
  • file_contexts दो फाइलों के बीच विभाजित हैं:
    • plat_file_contexts
      • एंड्रॉइड प्लेटफॉर्म file_context जिसमें कोई उपकरण-विशिष्ट लेबल नहीं है, सिवाय /vendor विभाजन के उन हिस्सों को लेबल करने के लिए जिन्हें सेपॉलिसी फाइलों के उचित कामकाज को सुनिश्चित करने के लिए सटीक रूप से लेबल किया जाना चाहिए।
      • डिवाइस पर /system/etc/selinux/plat_file_contexts पर system विभाजन में रहना चाहिए और शुरुआत में विक्रेता file_context के साथ init द्वारा लोड किया जाना चाहिए।
    • vendor_file_contexts
      • डिवाइस-विशिष्ट file_context को डिवाइस की Boardconfig.mk फ़ाइलों में BOARD_SEPOLICY_DIRS द्वारा इंगित निर्देशिका में पाए गए file_contexts के संयोजन से बनाया गया है।
      • vendor विभाजन में /vendor/etc/selinux/vendor_file_contexts पर स्थापित होना चाहिए और शुरुआत में प्लेटफॉर्म file_context के साथ init द्वारा लोड किया जाना चाहिए।

संपत्ति संदर्भ

एंड्रॉइड 8.0 में, property_contexts दो फाइलों के बीच विभाजित है:

  • plat_property_contexts
    • Android प्लेटफ़ॉर्म property_context जिसमें कोई उपकरण-विशिष्ट लेबल नहीं है।
    • system विभाजन में /system/etc/selinux/plat_property_contexts पर रहना चाहिए और प्रारंभ में विक्रेता property_contexts के साथ init द्वारा लोड किया जाना चाहिए।
  • vendor_property_contexts
    • डिवाइस-विशिष्ट property_context को डिवाइस की Boardconfig.mk फाइलों में property_contexts द्वारा इंगित निर्देशिकाओं में पाए जाने वाले BOARD_SEPOLICY_DIRS के संयोजन से बनाया गया है।
    • vendor विभाजन में /vendor/etc/selinux/vendor_property_contexts पर रहना चाहिए और प्रारंभ में प्लेटफॉर्म property_context के साथ init द्वारा लोड किया जाना चाहिए

सेवा संदर्भ

Android 8.0 में service_contexts को निम्न फ़ाइलों के बीच विभाजित किया गया है:

  • plat_service_contexts
    • servicemanager के लिए एंड्रॉइड प्लेटफॉर्म-विशिष्ट service_context । service_context में कोई उपकरण-विशिष्ट लेबल नहीं है।
    • system विभाजन में /system/etc/selinux/plat_service_contexts पर रहना चाहिए और servicemanager प्रबंधक द्वारा शुरू में विक्रेता service_contexts के साथ लोड किया जाना चाहिए।
  • vendor_service_contexts
    • डिवाइस-विशिष्ट service_context को डिवाइस की Boardconfig.mk फ़ाइलों में BOARD_SEPOLICY_DIRS द्वारा इंगित निर्देशिकाओं में पाए गए service_contexts के संयोजन से बनाया गया है।
    • vendor विभाजन में /vendor/etc/selinux/vendor_service_contexts पर रहना चाहिए और servicemanager द्वारा शुरू में प्लेटफॉर्म service_contexts के साथ लोड किया जाना चाहिए।
    • हालांकि servicemanager इस फाइल को बूट समय पर ढूंढता है, एक पूरी तरह से आज्ञाकारी TREBLE डिवाइस के लिए, vendor_service_contexts मौजूद नहीं होना चाहिए। ऐसा इसलिए है क्योंकि vendor और system प्रक्रियाओं के बीच सभी बातचीत hwservicemanager / hwbinder के माध्यम से होनी चाहिए।
  • plat_hwservice_contexts
    • hwservicemanager के लिए Android प्लेटफ़ॉर्म hwservice_context जिसमें कोई डिवाइस-विशिष्ट लेबल नहीं है।
    • system विभाजन में /system/etc/selinux/plat_hwservice_contexts पर रहना चाहिए और hwservicemanager द्वारा शुरू में vendor_hwservice_contexts के साथ लोड किया जाना चाहिए।
  • vendor_hwservice_contexts
    • डिवाइस-विशिष्ट hwservice_context डिवाइस की Boardconfig.mk फ़ाइलों में BOARD_SEPOLICY_DIRS द्वारा इंगित निर्देशिकाओं में पाए गए hwservice_contexts को मिलाकर बनाया गया है।
    • /vendor/etc/selinux/vendor_hwservice_contexts पर vendor विभाजन में रहना चाहिए और plat_service_contexts के साथ शुरुआत में hwservicemanager द्वारा लोड किया जाना plat_service_contexts ।
  • vndservice_contexts
    • डिवाइस के BOARD_SEPOLICY_DIRS में Boardconfig.mk द्वारा इंगित निर्देशिकाओं में पाए गए vndservice_contexts के संयोजन द्वारा निर्मित vndservicemanager के लिए डिवाइस-विशिष्ट service_context ।
    • यह फ़ाइल /vendor/etc/selinux/vndservice_contexts पर vendor विभाजन में होनी चाहिए और शुरुआत में इसे vndservicemanager द्वारा लोड किया जाना चाहिए।

सीप संदर्भ

एंड्रॉइड 8.0 में, seapp_contexts दो फाइलों के बीच विभाजित है:

  • plat_seapp_contexts
    • एंड्रॉइड प्लेटफॉर्म seapp_context जिसमें कोई डिवाइस-विशिष्ट परिवर्तन नहीं है।
    • system विभाजन में /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • डिवाइस की Boardconfig.mk फ़ाइलों में BOARD_SEPOLICY_DIRS द्वारा इंगित निर्देशिकाओं में पाए गए seapp_contexts के संयोजन द्वारा निर्मित प्लेटफ़ॉर्म seapp_context के लिए डिवाइस-विशिष्ट एक्सटेंशन।
    • vendor विभाजन में /vendor/etc/selinux/vendor_seapp_contexts पर रहना चाहिए।

मैक अनुमतियां

एंड्रॉइड 8.0 में, mac_permissions.xml दो फाइलों के बीच विभाजित है:

  • प्लेटफार्म mac_permissions.xml
    • Android प्लेटफ़ॉर्म mac_permissions.xml जिसमें कोई डिवाइस-विशिष्ट परिवर्तन नहीं है।
    • system विभाजन में /system/etc/selinux/.
  • गैर-प्लेटफ़ॉर्म mac_permissions.xml
    • mac_permissions.xml से निर्मित प्लेटफ़ॉर्म mac_permissions.xml के लिए डिवाइस-विशिष्ट एक्सटेंशन डिवाइस की Boardconfig.mk फ़ाइलों में BOARD_SEPOLICY_DIRS द्वारा इंगित निर्देशिकाओं में पाया गया।
    • vendor विभाजन में /vendor/etc/selinux/.