नीति के साथ काम करने की सुविधा

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

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

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

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

Android, एक्सपोर्ट किए गए कॉन्क्रीट टाइप को प्लैटफ़ॉर्म में मैप करता है हर प्लैटफ़ॉर्म के लिए नीति और उससे जुड़े वर्शन वाले एट्रिब्यूट वर्शन है. इससे यह पक्का होता है कि जब ऑब्जेक्ट को किसी टाइप के साथ लेबल किया जाए, तो वह इससे पिछले हफ़्ते में प्लैटफ़ॉर्म और सार्वजनिक नीति के तहत तय किए गए व्यवहार का उल्लंघन नहीं होता वर्शन है. इस मैपिंग का रखरखाव मैप करने वाली फ़ाइल को हर प्लैटफ़ॉर्म वर्शन में, जिसमें हर वर्शन के लिए एट्रिब्यूट की सदस्यता की जानकारी होती है सार्वजनिक नीति में एक्सपोर्ट किया गया टाइप.

ऑब्जेक्ट का मालिकाना हक और लेबलिंग

Android 8.0 और इसके बाद के वर्शन में नीति को पसंद के मुताबिक बनाते समय, मालिकाना हक की जानकारी साफ़ तौर पर दी जानी चाहिए हर ऑब्जेक्ट के लिए, प्लैटफ़ॉर्म और वेंडर नीति को अलग-अलग रखा जा सकता है. उदाहरण के लिए, अगर वेंडर लेबल /dev/foo और प्लैटफ़ॉर्म के बाद, लेबल करता है /dev/foo के बाद के ओटीए में, व्यवहार के बारे में कोई जानकारी नहीं मिलेगी. इसके लिए SELinux, यह लेबलिंग टकराव के रूप में बताता है. डिवाइस नोड में सिर्फ़ एक एक लेबल जोड़ें, जो आखिरी बार लागू किए गए लेबल पर लागू होता हो. इसकी वजह से:

  • ऐसी प्रक्रियाएं जिन्हें लागू नहीं हुए लेबल को ऐक्सेस करने की ज़रूरत होगी संसाधन का ऐक्सेस खो देता है.
  • फ़ाइल का ऐक्सेस पाने वाली प्रक्रियाएं काम करना बंद कर सकती हैं, क्योंकि गलत डिवाइस नोड बनाया गया.

सिस्टम की प्रॉपर्टी में, ऐसी टकराव का नाम रखने की संभावना भी होती है जिनकी वजह से, के बारे में नहीं बताया गया है. साथ ही, SELinux लेबलिंग के लिए. टकराव SELinux वाले किसी भी ऑब्जेक्ट के लिए, प्लैटफ़ॉर्म और वेंडर लेबल के बीच आ सकता है लेबल के साथ-साथ प्रॉपर्टी, सेवाएं, प्रोसेस, फ़ाइलें और सॉकेट शामिल हैं. इससे बचने के लिए इन समस्याओं के लिए, इन ऑब्जेक्ट के मालिकाना हक को साफ़ तौर पर परिभाषित किया जा सकता है.

लेबल टकरावों के अलावा, SELinux टाइप/एट्रिब्यूट के नाम भी आपस में टकरा सकते हैं. टाइप/एट्रिब्यूट के नाम को अलग-अलग करने पर, हमेशा पॉलिसी कंपाइलर की गड़बड़ी दिखेगी.

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

SELinux एक ही टाइप/एट्रिब्यूट के लिए कई बार जानकारी देने की अनुमति नहीं देता है. नीति डुप्लीकेट एलानों के साथ होने वाली वैल्यू को कंपाइल नहीं किया जा सकेगा. टाइप और विशेषता नाम टकराव, सभी वेंडर घोषणाएं नेमस्पेस की जानी चाहिए vendor_ से शुरू होते हैं. 

type foo, domain; → type vendor_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_ के लिए फ़िल्टर लगा है).

फ़ाइल का मालिकाना हक

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

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

/system कॉम्पोनेंट के लिए, सिर्फ़ सिस्टम इमेज में लेबल देने चाहिए file_contexts, service_contexts वगैरह के ज़रिए. अगर लेबल /system कॉम्पोनेंट के लिए, /vendor नीति में जोड़े गए हैं, ऐसा हो सकता है कि सिर्फ़ फ़्रेमवर्क के लिए ओटीए अपडेट न किया जा सके.

वेंडर (/वेंडर)

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 वगैरह

नतीजतन, कुछ खास नियमों का पालन करना ज़रूरी है. neverallows) vendor में अतिरिक्त फ़ाइलों को लेबल करते समय विभाजन:

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

Procfs (/proc)

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

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

Debugfs (/sys/kernel/debug)

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

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

ट्रेसफ़ (/sys/kernel/debug/tracing)

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

सुझाव: सिर्फ़ प्लैटफ़ॉर्म पर tracefs लेबल किया जा सकता है.

Sysfs (/sys)

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

सुझाव: प्लैटफ़ॉर्म के लिए लेबल sysfs हो सकता है ऐसे नोड जो अलग-अलग डिवाइस के लिए नहीं हैं. ऐसा न होने पर, फ़ाइलों को सिर्फ़ वेंडर लेबल कर सकता है.

tmpfs (/dev)

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

सुझाव: वेंडर सिर्फ़ /dev/vendor (उदाहरण के लिए, /dev/vendor/foo, /dev/vendor/socket/bar).

रूटफ़्स (/)

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

सुझाव: / में मौजूद फ़ाइलों को सिर्फ़ सिस्टम लेबल कर सकता है.

डेटा (/data)

डेटा को 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

हालांकि, वेंडर नीति में कोई बदलाव नहीं होगा, लेकिन v_domain नीति की कमी की वजह से, नए sysfs_A के लिए नीति का ऐक्सेस नहीं रहेगा टाइप करें.

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

सार्वजनिक नीति को अलग-अलग एट्रिब्यूट के तौर पर तय करने पर, दो नीतियों का पालन होता है साथ काम करने से जुड़े लक्ष्य:

  • पक्का करें कि प्लैटफ़ॉर्म अपडेट होने के बाद भी वेंडर कोड काम करता रहे. इससे जुड़े ऑब्जेक्ट के लिए, कंक्रीट टाइप में एट्रिब्यूट जोड़कर हासिल किया गया वे सिर्फ़ जिन पर वेंडर कोड निर्भर करता था और उनका ऐक्सेस बरकरार रहता है.
  • नीति का इस्तेमाल बंद करने की सुविधा. साफ़ तौर पर हासिल किया गया एट्रिब्यूट में दी गई नीति के बारे में साफ़ तौर पर जानकारी दें, जिन्हें जिनका वे वर्शन अब उपलब्ध नहीं है. डेवलपमेंट कैन यह जानते हुए कि पुरानी नीति अब भी YouTube में और अपग्रेड किए जाने पर अपने-आप हट जाएगी.

नीति की सही जानकारी

उस लक्ष्य को पूरा करने के लिए जिसके लिए, वर्शन में बदलाव के बारे में जानकारी होना ज़रूरी नहीं है नीति विकास, Android 8.0 में प्लेटफ़ॉर्म-सार्वजनिक के बीच मैपिंग शामिल है नीति के टाइप और उनके एट्रिब्यूट. टाइप foo मैप किया गया foo_vN को एट्रिब्यूट करने के लिए, जहां 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)))

वेंडर नीति को प्लैटफ़ॉर्म से आगे नहीं बढ़ाया जा सकता. इसलिए, इसे प्लैटफ़ॉर्म पर मौजूद . हालांकि, प्लैटफ़ॉर्म नीति के लिए यह जानने की ज़रूरत होगी कि वेंडर के लिए कितने पुराने नीति, उसके टाइप के हिसाब से एट्रिब्यूट शामिल करें, और एट्रिब्यूट के अलग-अलग वर्शन होने चाहिए.

नीति में अंतर

आखिर में _vN जोड़कर, एट्रिब्यूट अपने-आप बनाए जा रहे हैं हर एक टाइप, सभी वर्शन में टाइप पर एट्रिब्यूट को मैप किए बिना कुछ नहीं करता फ़र्क़. Android, एट्रिब्यूट के लिए वर्शन को मैप करता है और मैपिंग की प्रक्रिया पूरी करें. यह ऊपर बताए गए मैपिंग में किया जाता है स्टेटमेंट वाली फ़ाइलें, जैसे कि (CIL): 

(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 मैपिंग फ़ाइल (सीआईएल) में: 

(typeattributeset binder_device_v1 (binder_device))

v2 मैपिंग फ़ाइल (सीआईएल) में: 

(typeattributeset binder_device_v2 (binder_device))

v1 वेंडर नीति (सीआईएल) में: 

(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 मैपिंग फ़ाइल (सीआईएल) में: 

(typeattributeset sysfs_v1 (sysfs sysfs_A))

v2 मैपिंग फ़ाइल (सीआईएल) में: 

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

v1 वेंडर नीति (सीआईएल) में: 

(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 मैपिंग फ़ाइल (सीआईएल) में: 

(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 मैपिंग फ़ाइल (सीआईएल) में: 

(typeattributeset sysfs_v2 (sysfs))

v1 वेंडर नीति (सीआईएल) में: 

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

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

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

उदाहरण वर्शन 2: पूरी तरह से हटाना (foo type)

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

# nothing - we got rid of the type

v1 मैपिंग फ़ाइल (सीआईएल) में: 

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

v2 मैपिंग फ़ाइल (सीआईएल) में: 

# nothing - get rid of it

v1 वेंडर नीति (सीआईएल) में: 

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

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

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
नई क्लास/अनुमतियां

यह स्थिति तब आती है, जब प्लैटफ़ॉर्म अपग्रेड के दौरान, नीति से जुड़े नए कॉम्पोनेंट शामिल होते हैं जो पिछले वर्शन में मौजूद नहीं हैं. उदाहरण के लिए, जब Android ने 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 के बीच का पाथ. प्लैटफ़ॉर्म और वेंडर प्रोसेस में बातचीत करने के लिए, ऑन-डिस्क फ़ाइलों का इस्तेमाल नहीं किया जाना चाहिए (अनियमित एबीआई). सुझाव:
    • वेंडर कोड में /data/vendor का इस्तेमाल किया जाना चाहिए.
    • सिस्टम को /data/vendor का इस्तेमाल नहीं करना चाहिए.
  • system_executes_vendor_violators. एट्रिब्यूट सभी सिस्टम डोमेन के लिए (init और shell domains को छोड़कर) जो वेंडर बाइनरी का इस्तेमाल न करने की शर्त का उल्लंघन करते हैं. इसका निष्पादन वेंडर बाइनरी में एपीआई की गड़बड़ी है. प्लैटफ़ॉर्म को वेंडर बाइनरी चलाने की अनुमति नहीं है सकता है. सुझाव:
    • वेंडर बाइनरी पर ऐसी प्लैटफ़ॉर्म डिपेंडेंसी, HIDL HAL के पीछे होनी चाहिए.

      या

    • जिस coredomains को वेंडर बाइनरी का ऐक्सेस चाहिए वह यह होना चाहिए वेंडर पार्टीशन में चला गया है. इसलिए, coredomain होना बंद कर देगा.

गैर-भरोसेमंद एट्रिब्यूट

आर्बिट्रेरी कोड होस्ट करने वाले गैर-भरोसेमंद ऐप्लिकेशन के पास HwBinder का ऐक्सेस नहीं होना चाहिए इसमें वे सेवाएं शामिल नहीं होती हैं जिन्हें ऐसे ऐप्लिकेशन से ऐक्सेस करने के लिए काफ़ी सुरक्षित माना जाता है (सुरक्षित सेवाएं नीचे देखें). इसकी दो मुख्य वजहें हैं:

  1. HwBinder सर्वर, क्लाइंट की पुष्टि नहीं करते, क्योंकि फ़िलहाल HIDL कॉलर की यूआईडी जानकारी नहीं दिखाता है. भले ही HIDL ने ऐसा डेटा सार्वजनिक किया हो, लेकिन HwBinder सेवाएं, ऐप्लिकेशन के लेवल (जैसे कि एचएएल) पर काम करती हैं या अनुमति देने के लिए, ऐप्लिकेशन की पहचान पर निर्भर नहीं होना चाहिए. इस प्रकार, सुरक्षित रहने के लिए, डिफ़ॉल्ट यह माना जाता है कि हर 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 बाइंडर सेवा, जिसे ऐप्लिकेशन ऐक्सेस कर सकते हैं.
  • 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 एचएएल का सीधा ऐक्सेस चाहिए उनके पास खुद का वेंडर तय करने वाला सेपॉलिसी डोमेन होना चाहिए.

फ़ाइल एट्रिब्यूट की जांच

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

प्लैटफ़ॉर्म-सार्वजनिक नीति

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

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

एट्रिब्यूट चेन के लिए मैप करना

नीति के वर्शन से मैप करने के लिए एट्रिब्यूट का इस्तेमाल करते समय, एक टाइप किसी एट्रिब्यूट को मैप करता है या एक से ज़्यादा एट्रिब्यूट का इस्तेमाल करते हैं. साथ ही, यह पक्का करते हैं कि टाइप के साथ लेबल किए गए ऑब्जेक्ट को ऐक्सेस किया जा सके एट्रिब्यूट की वैल्यू सबमिट करें.

पॉलिसी राइटर से वर्शन की जानकारी छिपाने का मतलब है वर्शन वाले एट्रिब्यूट अपने-आप जनरेट होते हैं और उन्हें उचित प्रकार. स्टैटिक टाइप के मामले में, यह तरीका आसान है: type_foo_v1 पर type_foo मैप करता है.

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

वर्शन में बदलाव

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

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

का परफ़ॉर्मेंस एक से ज़्यादा एट्रिब्यूट

जैसा कि https://github.com/SELinuxProject/cil/issues/9 में बताया गया है, किसी टाइप को बड़ी संख्या में एट्रिब्यूट असाइन करने की वजह से, परफ़ॉर्मेंस से जुड़ी समस्याएं होती हैं नीति की कैश मेमोरी छूट जाने का इवेंट.

इस बात की पुष्टि की गई थी कि यह समस्या Android में है, इसलिए बदलाव को Android 8.0 में बनाया गया था, ताकि नीति में जोड़े गए एट्रिब्यूट को हटाया जा सके पॉलिसी कंपाइलर और इस्तेमाल न किए गए एट्रिब्यूट हटाने का अनुरोध करता है. इन बदलावों का समाधान हो गया कम से कम एक बार इस्तेमाल किया जा सकता है.

System_ext सार्वजनिक और प्रॉडक्ट की सार्वजनिक नीति

Android 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 या इसके बाद वाला वर्शन है सिस्टम_ext और प्रॉडक्ट के बंटवारे के लिए उपलब्ध हैं.

इसके लिए, पार्टनर से यह उम्मीद की जाती है कि:

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

उदाहरण के लिए, मान लें कि N system_ext में एक सार्वजनिक है foo_type नाम का टाइप. इसके बाद, system_ext/etc/selinux/mapping/N.cil चुकाएं N के सिस्टम_एक्स्ट पार्टीशन में ये ऐसे दिखेंगे: 

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

अगर bar_type को N+1 system_ext में जोड़ा जाता है, और अगर bar_type को foo_type पर मैप किया जाना चाहिए N वेंडर, 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
      • ऐसा Android प्लैटफ़ॉर्म file_context जिसमें कोई डिवाइस के लिए खास लेबल, इनके कुछ हिस्से लेबल करने को छोड़कर /vendor विभाजन, जिसे सटीक रूप से लेबल किया जाना चाहिए यह भी पक्का किया जा सकेगा कि सिनीति फ़ाइलें सही तरीके से काम कर रही हैं या नहीं.
      • यहां पर system विभाजन में होना चाहिए: डिवाइस पर /system/etc/selinux/plat_file_contexts और init के साथ शुरुआत में लोड होगी. वेंडर file_context.
    • vendor_file_contexts
      • इन्हें जोड़कर बनाया गया, डिवाइस के हिसाब से file_context इनके ज़रिए भेजी गई डायरेक्ट्री में file_contexts मिला डिवाइस के BOARD_SEPOLICY_DIRS Boardconfig.mk फ़ाइलें.
      • यहां पर इंस्टॉल किया जाना चाहिए /vendor/etc/selinux/vendor_file_contexts इंच यह vendor पार्टीशन और init के ज़रिए लोड किया जाता है हम file_context प्लैटफ़ॉर्म के साथ शुरुआत करते हैं.

प्रॉपर्टी के कॉन्टेक्स्ट

Android 8.0 में, property_contexts को दो फ़ाइलों में बांट दिया जाता है:

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

सेवा से जुड़े कॉन्टेक्स्ट

Android 8.0 में, service_contexts को इनके बीच बांटा जाता है फ़ाइलें:

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

Seapp कॉन्टेक्स्ट

Android 8.0 में, seapp_contexts को दो फ़ाइलों में बांट दिया जाता है:

  • plat_seapp_contexts
    • Android प्लैटफ़ॉर्म seapp_context, जो डिवाइस के लिए खास तौर पर उपलब्ध नहीं है बदलाव.
    • यहां पर system विभाजन में होना चाहिए: /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • प्लैटफ़ॉर्म seapp_context के लिए डिवाइस के हिसाब से एक्सटेंशन बनाया गया डायरेक्ट्री में मिले seapp_contexts को एक साथ इस्तेमाल करके डिवाइस में BOARD_SEPOLICY_DIRS के ज़रिए दिखाया गया Boardconfig.mk फ़ाइलें.
    • यहां पर vendor विभाजन में होना चाहिए: /vendor/etc/selinux/vendor_seapp_contexts.

MAC की अनुमतियां

Android 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 मिला है जिन पर कर्सर ले जाया गया है डिवाइस में मौजूद BOARD_SEPOLICY_DIRS Boardconfig.mk फ़ाइलें.
    • यहां पर vendor विभाजन में होना चाहिए: /vendor/etc/selinux/.