नीति अनुकूलता

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

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

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

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

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

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

एंड्रॉइड 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.* (एक स्पष्ट हार्डवेयर-संबंधित संपत्ति) का उपयोग करना जारी रख सकते हैं।

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

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

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

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

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

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

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

/vendor पथ प्लेटफ़ॉर्म-प्रदत्त लेबल लेबल के आधार पर प्लेटफ़ॉर्म प्रक्रियाएं
/vendor(/. * )? vendor_file फ्रेमवर्क, ueventd आदि में सभी एचएएल ग्राहक।
/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_file vendor विभाजन में सभी फ़ाइलों के लिए डिफ़ॉल्ट लेबल होना चाहिए। प्लेटफ़ॉर्म नीति को पासथ्रू एचएएल कार्यान्वयन तक पहुंचने के लिए इसकी आवश्यकता होती है।
  • विक्रेता SEPolicy के माध्यम से vendor विभाजन में जोड़े गए सभी नए exec_types में vendor_file_type विशेषता होनी चाहिए। इसे नेवरअलाउज़ के माध्यम से लागू किया जाता है।
  • भविष्य के प्लेटफ़ॉर्म/फ़्रेमवर्क अपडेट के साथ टकराव से बचने के लिए, vendor विभाजन में exec_types के अलावा अन्य फ़ाइलों को लेबल करने से बचें।
  • AOSP द्वारा पहचानी गई समान प्रक्रिया HAL के लिए सभी लाइब्रेरी निर्भरताओं को same_process_hal_file.

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

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

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

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

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

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

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

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

सिफ़ारिश: केवल प्लेटफ़ॉर्म ही tracefs लेबल कर सकता है।

Sysfs (/sys)

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

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

tmpfs (/dev)

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

सिफ़ारिश: विक्रेता केवल /dev/vendor में फ़ाइलों को लेबल कर सकता है (उदाहरण के लिए, /dev/vendor/foo , /dev/vendor/socket/bar )।

रूटफ़्स (/)

/ में फ़ाइलें file_contexts में लेबल की जा सकती हैं। एंड्रॉइड 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_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 विक्रेता नीति (सीआईएल) में:

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

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

(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 विक्रेता नीति (सीआईएल) में:

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

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

(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 विक्रेता नीति (सीआईएल) में:

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

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

(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 विक्रेता नीति (सीआईएल) में:

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

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

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

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

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

allow {domain -coredomain} *:new_class perm;

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

वर्ग/अनुमतियाँ हटा दी गईं

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

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

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

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

एंड्रॉइड 9 के लिए विशेषता परिवर्तन

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

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

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

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

      या

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

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

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

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

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

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

  • 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 विशेषता होती है। संबंधित HAL सर्वर में untrusted_app_visible_halserver विशेषता होती है। एंड्रॉइड 9 के साथ लॉन्च होने वाले उपकरणों को किसी भी untrusted विशेषता का उपयोग नहीं करना चाहिए।

सिफारिश:

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

    या

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

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

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

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

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

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

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

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

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

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

संस्करण uprevs

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

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

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

जैसा कि https://github.com/SELinuxProject/sil/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 विक्रेता को N+1 (या बाद में) सिस्टम_एक्स्ट और उत्पाद विभाजन के साथ समर्थन देने जा रहे हैं।

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

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

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

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

सेवा प्रसंग

एंड्रॉइड 8.0 में, service_contexts निम्नलिखित फ़ाइलों के बीच विभाजित किया गया है:

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

सीप संदर्भ

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

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

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

Android 8.0 में, mac_permissions.xml दो फ़ाइलों के बीच विभाजित किया गया है:

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