SELinux फ़ंक्शन के बुनियादी लेवल को इंटिग्रेट करने के बाद और नतीजों का अच्छी तरह से विश्लेषण कर लिया है, तो कवर करने के लिए अपनी नीति की सेटिंग जोड़ी जा सकती हैं अपने हिसाब से बदलाव करें. इन नीतियों के लिए, आप Android के साथ काम करने के लिए बने प्रोग्राम की शर्तें पूरी करते हों की शर्तों को पूरा करते हैं और उन्हें डिफ़ॉल्ट SELinux सेटिंग को नहीं निकालना चाहिए.
मैन्युफ़ैक्चरर को SELinux की मौजूदा नीति नहीं हटानी चाहिए. नहीं तो, वे इससे Android SELinux को लागू करने और ऐप्लिकेशन को काम करने में मदद नियंत्रित करता है. इसमें तीसरे पक्ष के ऐसे ऐप्लिकेशन शामिल हैं जिन्हें पहले से बेहतर और काम करने लायक हुआ. ऐप्लिकेशन के लिए ज़रूरी नहीं है कि बदलाव करने की अनुमति दें.
SELinux को कस्टमाइज़ करते समय, इन बातों का ध्यान रखें:
- सभी नए डीमन के लिए, SELinux नीति लिखें
- जहां भी ज़रूरी हो, पहले से तय डोमेन का इस्तेमाल करें
initसेवा के तौर पर शुरू हुई किसी भी प्रोसेस के लिए डोमेन असाइन करें- नीति लिखने से पहले मैक्रो को अच्छी तरह समझ लें
- मुख्य नीति में किए गए बदलावों को एओएसपी में सबमिट करें
साथ ही, इन बातों का ध्यान रखें:
- असंगत नीति बनाएं
- असली उपयोगकर्ता की नीति को पसंद के मुताबिक बनाने की अनुमति दें
- एमडीएम से जुड़ी नीतियां पसंद के मुताबिक बनाने की अनुमति दें
- नीतियों का उल्लंघन करने वाले उपयोगकर्ताओं को डराना
- बैकडोर जोड़ें
Kernel Security Features सेक्शन Android खास शर्तों के लिए, कम्पैटिबिलिटी डेफ़िनिशन दस्तावेज़.
SELinux में व्हाइटलिस्ट अप्रोच इस्तेमाल की जाती है, जिसका मतलब है कि सभी ऐक्सेस साफ़ तौर पर दिए जाने चाहिए की अनुमति है. Android के डिफ़ॉल्ट SELinux से यह नीति पहले से ही Android ओपन सोर्स प्रोजेक्ट के साथ काम करती है, यानी कि आपको यह करने की ज़रूरत नहीं है में बदलाव करने की अनुमति दें. अगर SELinux की सेटिंग को पसंद के मुताबिक बनाया जाता है, इस बात का ध्यान रखें कि मौजूदा ऐप्लिकेशन को नुकसान न पहुंचे. शुरू करने के लिए:
- इसका इस्तेमाल करें नया Android कर्नेल के तौर पर दिखेगा.
- Ad Manager, सिद्धांत कम से कम अधिकारों के साथ आगे बढ़ना हो.
- Android में सिर्फ़ अपनी ओर से जोड़ी गई सुविधाओं पर ध्यान दें. डिफ़ॉल्ट नीति इनके साथ काम करती है Android ओपन सोर्स प्रोजेक्ट कोड बेस अपने-आप बन जाता है.
- सॉफ़्टवेयर के कॉम्पोनेंट को एक ही मॉड्यूल में बांटें टास्क.
- SELinux की ऐसी नीतियां बनाएं जो उन कामों को एक-दूसरे से कनेक्ट न करें फ़ंक्शन.
- उन नीतियों को
*.teफ़ाइलों में रखें (SELinux का एक्सटेंशन नीति की सोर्स फ़ाइलें)/device/manufacturer/device-name/sepolicyऔर उन्हें शामिल करने के लिएBOARD_SEPOLICYवैरिएबल का इस्तेमाल करें आपका बिल्ड. - शुरुआत में नए डोमेन को अनुमति दें. ऐसा करने के लिए, किसी अनुमति का इस्तेमाल करना होता है
एलान को डोमेन की
.teफ़ाइल में सबमिट किया जाएगा. - नतीजों का विश्लेषण करें और अपने डोमेन की परिभाषाओं को बेहतर बनाएं.
- जब उपयोगकर्ता डीबग में कोई और अनुरोध न दिखे, तो अनुमति देने वाले एलान को हटाएं बिल्ड.
अपनी SELinux नीति परिवर्तन को एकीकृत करने के बाद, अपने डेवलपमेंट वर्कफ़्लो के बारे में बताया गया है. एक आदर्श सॉफ़्टवेयर डेवलपमेंट प्रोसेस, SELinux नीति केवल तब बदलती है जब सॉफ़्टवेयर मॉडल में बदलाव होता है, न कि असल में लागू होता है.
SELinux को कस्टमाइज़ करना शुरू करते ही, पहले Android में जोड़े गए विकल्पों को ऑडिट करें. अगर आपने आपने एक ऐसा कॉम्पोनेंट जोड़ा है जो एक नया फ़ंक्शन चलाता है, इसलिए पक्का करें कि कॉम्पोनेंट Android की सुरक्षा नीति के साथ-साथ, Android की ओर से बनाई गई ओईएम को फिर से लागू करना मोड चालू करने से पहले.
गै़र-ज़रूरी समस्याओं से बचने के लिए, बेहतर है कि ज़्यादा से ज़्यादा पाठकों तक बहुत ज़्यादा पाबंदी वाली और काम नहीं करने की तुलना में बहुत ज़्यादा काम करती है, जिसकी वजह से डिवाइस के फ़ंक्शन. इसके ठीक उलट, अगर आपके बदलावों से दूसरों को फ़ायदा होगा, तो आपको डिफ़ॉल्ट SELinux नीति में किए गए बदलावों को पैच. अगर पैच डिफ़ॉल्ट सुरक्षा नीति पर लागू होती है, तो आपको Android के हर नए वर्शन के लिए.
नीति के स्टेटमेंट के उदाहरण
SELinux कैसे इन एम4 कंप्यूटर भाषा है और इसलिए समय बचाने के लिए कई तरह के मैक्रो का समर्थन करती है.
नीचे दिए गए उदाहरण में, सभी डोमेन को
/dev/null को लिखें और /dev/zero से पढ़ें.
# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};
# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };
यह वाक्य SELinux *_file_perms के साथ लिखा जा सकता है
मैक्रो (शॉर्टहैंड):
# Allow read / write access to /dev/null allow domain null_device:chr_file rw_file_perms; # Allow read-only access to /dev/zero allow domain zero_device:chr_file r_file_perms;
नीति का उदाहरण
यहां डीएचसीपी से जुड़ी नीति का पूरा उदाहरण दिया गया है. हम इसकी जांच यहां करेंगे:
type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;
init_daemon_domain(dhcp)
net_domain(dhcp)
allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)
type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;
allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };
आइए, इस उदाहरण को देखें:
पहली लाइन में, टाइप डिक्लेयरेशन के तहत, डीएचसीपी डीमन को
बुनियादी सुरक्षा नीति (domain). पिछले स्टेटमेंट से
उदाहरण के लिए, DHCP /dev/null से पढ़ सकता है और उसमें बदलाव कर सकता है.
दूसरी लाइन में, डीएचसीपी की पहचान अनुमति देने वाले डोमेन के तौर पर की गई है.
init_daemon_domain(dhcp) लाइन में, नीति के मुताबिक डीएचसीपी यह होता है
init से लिया गया है और यह इससे संपर्क कर सकता है.
net_domain(dhcp) लाइन में, यह नीति डीएचसीपी को इस्तेमाल करने की अनुमति देती है
net डोमेन की सामान्य नेटवर्क फ़ंक्शन, जैसे कि रीडिंग
टीसीपी पैकेट लिखना, सॉकेट पर कम्युनिकेट करना, और डीएनएस की सुविधा चालू करना
अनुरोध.
लाइन allow dhcp proc_net:file write; में, नीति में बताया गया है
डीएचसीपी, /proc में मौजूद कुछ खास फ़ाइलों पर डेटा लिख सकता है. यह लाइन दिखाती है
SELinux की सटीक फ़ाइल लेबलिंग. यह proc_net लेबल का इस्तेमाल करता है
ताकि सिर्फ़ /proc/sys/net से छोटी फ़ाइलों में लिखने का ऐक्सेस सीमित किया जा सके.
इससे शुरू होने वाले उदाहरण का आखिरी ब्लॉक
allow dhcp netd:fd use; में बताया गया है कि ऐप्लिकेशन को ये काम करने की अनुमति कैसे दी जा सकती है
एक-दूसरे के साथ बातचीत करें. नीति के मुताबिक डीएचसीपी और इंटरनेट सेवा देने वाली कंपनियां,
फ़ाइल डिस्क्रिप्टर, FIFO फ़ाइलें, डेटाग्राम सॉकेट, और UNIX स्ट्रीम के ज़रिए एक-दूसरे के साथ
सॉकेट. DHCP सिर्फ़ डेटाग्राम सॉकेट और UNIX से पढ़ और लिख सकता है
सॉकेट स्ट्रीम करना और उन्हें बनाना या खोलना नहीं.
उपलब्ध कंट्रोल
| कक्षा | अनुमति |
|---|---|
| फ़ाइल |
ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton |
| डायरेक्ट्री |
add_name remove_name reparent search rmdir open audit_access execmod |
| सॉकेट |
ioctl read write create getattr setattr lock relabelfrom relabelto append bind connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg name_bind |
| फ़ाइल सिस्टम |
mount remount unmount getattr relabelfrom relabelto transition associate quotamod quotaget |
| प्रोसेस |
fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched getsession getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem execstack execheap setkeycreate setsockcreate |
| सिक्योरिटी |
compute_av compute_create compute_member check_context load_policy compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot read_policy |
| क्षमता |
chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap |
|
ज़्यादा देखें |
और भी बहुत कुछ |
कभी भी अनुमति न दें
SELinux neverallow नियम ऐसे व्यवहार पर रोक लगाते हैं जो कभी नहीं होना चाहिए.
कंपैटबिलिटी टेस्टिंग की मदद से,
SELinux neverallow के नियम अब सभी डिवाइसों पर लागू किए जाते हैं.
इन दिशा-निर्देशों का मकसद, मैन्युफ़ैक्चरर को गड़बड़ियों से बचने में मदद करना है
कस्टमाइजे़शन के दौरान, neverallow नियम से जुड़े. नियम की संख्याएं
जो यहां Android 5.1 के मुताबिक हैं और रिलीज़ के हिसाब से इनमें बदलाव हो सकता है.
नियम 48: neverallow { domain -debuggerd -vold -dumpstate
-system_server } self:capability sys_ptrace;
ptrace का मैन पेज देखें. sys_ptrace
की मदद से किसी भी प्रोसेस को ptrace किया जा सकता है. इससे
का नियंत्रण अन्य प्रोसेस पर हो और जो सिर्फ़ तय किए गए सिस्टम के तहत हो
कॉम्पोनेंट, नियम में बताए गए हैं. इस क्षमता की आवश्यकता अक्सर बताती है कि
किसी ऐसी चीज़ का होना जो उपयोगकर्ताओं के लिए उपलब्ध न हो या
जिसकी ज़रूरत नहीं है. गै़र-ज़रूरी कॉम्पोनेंट हटाएं.
नियम 76: neverallow { domain -appdomain -dumpstate
-shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
इस नियम का मकसद, सिस्टम पर आर्बिट्रेरी कोड लागू होने से रोकना है.
खास तौर पर, यह दावा करता है कि सिर्फ़ /system पर मौजूद कोड काम करता है,
इस सुविधा की मदद से, वेरिफ़ाइड बूट जैसे तरीकों की मदद से सुरक्षा की गारंटी मिलती है.
अक्सर, इस समस्या का सबसे अच्छा हल यह होता है कि
neverallow नियम आपत्तिजनक कोड को
/system विभाजन.
Android 8.0 और उसके बाद के वर्शन में SEPolicy को पसंद के मुताबिक बनाना
यह सेक्शन Android 8.0 और Android 8.0 में वेंडर SELinux नीति के लिए दिशा-निर्देश देता है इसमें Android Open Source Project (AOSP) SEPolicy की जानकारी और SEPolicy एक्सटेंशन. SELinux नीति को बनाए रखने के बारे में ज़्यादा जानकारी के लिए सभी पार्टिशन और Android वर्शन के साथ काम करता है, तो यह किन सुविधाओं के साथ काम करती है.
नीति प्लेसमेंट
Android 7.0 और इससे पहले के वर्शन में, डिवाइस बनाने वाली कंपनियां, Android 7.0 और इससे पहले के वर्शन में,
BOARD_SEPOLICY_DIRS, इसमें एओएसपी नीति को बेहतर बनाने के लिए बनी नीति शामिल है
कर सकते हैं. Android 8.0 और उसके बाद के वर्शन में,
BOARD_SEPOLICY_DIRS, नीति को सिर्फ़ वेंडर के लिए सेट करता है
इमेज.
Android 8.0 और उसके बाद के वर्शन में, एओएसपी में इन जगहों पर नीति मौजूद होती है:
- system/sepolicy/public पर टैप करें. इसमें इस्तेमाल के लिए एक्सपोर्ट की गई नीति शामिल है
के हिसाब से नीति लागू होती है. सबकुछ Android 8.0 में चला जाता है
कंपैटबिलिटी इन्फ़्रास्ट्रक्चर.
सार्वजनिक नीति सभी रिलीज़ पर लागू रहती है. इसलिए, इसमें
आपकी पसंद के मुताबिक बनाई गई नीति में कुछ भी
/public. इस वजह से,/publicमें जिस तरह की नीति लागू की जा सकती है वह इस बारे में ज़्यादा है प्रतिबंधित. इसे प्लैटफ़ॉर्म की एक्सपोर्ट की गई नीति के एपीआई के बारे में सोचें: ऐसी कोई भी चीज़/systemऔर के बीच के इंटरफ़ेस पर काम करता है/vendorयहां का है. - system/sepolicy/private सबमिट करें. इसके लिए ज़रूरी नीति शामिल है सिस्टम इमेज काम कर रही है, लेकिन किस वेंडर इमेज नीति को कोई ज्ञान नहीं है.
- system/sepolicy/वेंडर सबमिट करें. इसमें ऐसे कॉम्पोनेंट के लिए नीति शामिल होती है जो
/vendorमें जाएंगे, लेकिन कोर प्लैटफ़ॉर्म ट्री में मौजूद होंगे (नहीं खास तौर पर डिवाइस के लिए बनी डायरेक्ट्री). यह बिल्ड सिस्टम के डिवाइस और ग्लोबल कॉम्पोनेंट के बीच अंतर; सैद्धांतिक तौर पर यह एक . - device/manufacturer/device-name/sepolicy. इसमें डिवाइस के लिए खास नीति शामिल है. इसमें, डिवाइस को पसंद के मुताबिक बनाने की सुविधा भी शामिल है यह नीति, Android 8.0 और उसके बाद के वर्शन में कॉम्पोनेंट के लिए बनी नीति के मुताबिक होती है पर क्लिक करें.
Android 11 और उसके बाद वाले वर्शन में, system_ext और प्रॉडक्ट विभाजनों में, विभाजन-विशिष्ट नीतियों का पालन करें. system_ext और प्रॉडक्ट की नीतियों को इनमें भी बांटा जाता है सार्वजनिक और निजी हैं, और वेंडर system_ext's और प्रॉडक्ट के सार्वजनिक's का इस्तेमाल कर सकते हैं जैसे कि सिस्टम की नीति.
SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS. इसमें एक्सपोर्ट की गई नीति शामिल है का इस्तेमाल वेंडर के लिए तय की गई नीति में किया जाएगा. सिस्टम_एक्स्ट पार्टिशन में इंस्टॉल किया गया.SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS. नीति ज़रूरी है सिस्टम_ext इमेज के काम करने के लिए, लेकिन इसमें से वेंडर इमेज नीति का ज्ञान नहीं होना चाहिए. सिस्टम_एक्स्ट पार्टिशन में इंस्टॉल किया गया.PRODUCT_PUBLIC_SEPOLICY_DIRS. इसमें एक्सपोर्ट की गई नीति शामिल है का इस्तेमाल वेंडर के लिए तय की गई नीति में किया जाएगा. प्रॉडक्ट विभाजन में इंस्टॉल किया गया.PRODUCT_PRIVATE_SEPOLICY_DIRS. इसके लिए ज़रूरी नीति शामिल है प्रॉडक्ट इमेज के काम करने का तरीका, लेकिन वेंडर इमेज नीति के हिसाब से उसे कोई ज्ञान नहीं होना चाहिए. प्रॉडक्ट विभाजन में इंस्टॉल किया गया.
इन नीतियों के साथ काम करने की स्थितियां
Android 8.0 और इसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों पर, वेंडर की इमेज काम करनी चाहिए इसके लिए, OEM सिस्टम की इमेज और Google की ओर से उपलब्ध कराई गई AOSP सिस्टम इमेज का इस्तेमाल करें (और इस रेफ़रंस इमेज पर सीटीएस पास करें). इन शर्तों से पक्का होता है कि फ़्रेमवर्क और वेंडर कोड को अलग-अलग किया जाता है. ऐसे डिवाइस इन स्थितियों में मदद मिल सकती है.
सिर्फ़ वेंडर की इमेज के लिए एक्सटेंशन
उदाहरण: vndservicemanager में नई सेवा जोड़ना
उस वेंडर इमेज से लिया जाएगा जो वेंडर इमेज से प्रोसेस को सपोर्ट करता है.
Android के पुराने वर्शन के साथ लॉन्च होने वाले डिवाइसों की तरह ही, डिवाइस के हिसाब से जोड़ें
कस्टमाइज़ेशन में
device/manufacturer/device-name/sepolicy.
नई नीति, जो यह तय करती है कि वेंडर के कॉम्पोनेंट (सिर्फ़) अन्य वेंडर के साथ कैसे इंटरैक्ट किया जाएगा
कॉम्पोनेंट में ऐसे टाइप शामिल होने चाहिए जो सिर्फ़
device/manufacturer/device-name/sepolicy.
यहां दी गई नीति, वेंडर पर कोड को काम करने की अनुमति देती है. इसे अपडेट नहीं किया जाएगा
एक फ़्रेमवर्क-ओनली ओटीए का इस्तेमाल करता है. साथ ही, यह डिवाइस पर एक साथ लागू की गई नीति में मौजूद होगा
जिसे एओएसपी सिस्टम इमेज की मदद से बनाया गया है.
वेंडर-इमेज सहायता से काम करने की सुविधा AOSP के साथ
उदाहरण: नई प्रोसेस जोड़ना (इसके साथ रजिस्टर किया गया हो
(वेंडर इमेज से hwservicemanager) जो किसी खास नियम को लागू करता है
AOSP-तय HAL.
Android के पुराने वर्शन के साथ लॉन्च होने वाले डिवाइसों की तरह ही,
डिवाइस के हिसाब से सेटिंग को अपनी पसंद के मुताबिक बनाने के लिए
device/manufacturer/device-name/sepolicy.
system/sepolicy/public/ के हिस्से के तौर पर एक्सपोर्ट की गई नीति उपलब्ध है
इसका इस्तेमाल किया जा सकता है और इसे वेंडर नीति के तहत शिप किया जाता है. यहां से टाइप और एट्रिब्यूट
सार्वजनिक नीति का इस्तेमाल, नए नियमों के साथ इंटरैक्शन
वेंडर के हिसाब से बिट, दी गई neverallow पर निर्भर करती हैं
प्रतिबंध. सिर्फ़ वेंडर के मामले में, यहां नई नीति अपडेट नहीं की जाएगी
एक फ़्रेमवर्क-ओनली ओटीए के हिस्से के तौर पर शामिल किया जाएगा और यह एक साथ लागू की गई नीति में
इस डिवाइस में मौजूद AOSP सिस्टम इमेज का रेफ़रंस दिया गया है.
सिर्फ़ सिस्टम इमेज के लिए एक्सटेंशन
उदाहरण: नई सेवा जोड़ना (सर्विसमैनेजर के साथ रजिस्टर किया गया) जिसे सिस्टम इमेज से सिर्फ़ दूसरी प्रोसेस से ऐक्सेस किया जा सकता है.
system/sepolicy/private में यह नीति जोड़ें. आप अतिरिक्त कार्ड जोड़ सकते हैं
में फ़ंक्शन चालू करने के लिए प्रोसेस या ऑब्जेक्ट की जानकारी, दिए गए हों
उन नए बिट को वेंडर इमेज पर नए कॉम्पोनेंट के साथ इंटरैक्ट करने की ज़रूरत नहीं है
(खास तौर पर, ऐसी प्रोसेस या ऑब्जेक्ट, हमारी नीतियों के बिना पूरी तरह से काम करने चाहिए
वेंडर की इमेज). system/sepolicy/public ने जिस नीति को एक्सपोर्ट किया है वह
जो ठीक उसी तरह उपलब्ध होंगे जैसे यह सिर्फ़ वेंडर-इमेज वाले एक्सटेंशन के लिए है. यह नीति
का हिस्सा है और उसे सिर्फ़ फ़्रेमवर्क-ओनली ओटीए में अपडेट किया जा सकता है,
जो पहचान एओएसपी सिस्टम इमेज का इस्तेमाल करते समय मौजूद नहीं होती है.
वेंडर की इमेज ऐसे एक्सटेंशन जो एक्सटेंडेट एओएसपी कॉम्पोनेंट के साथ काम करते हैं
उदाहरण: एक नया, बिना एओएसपी एचएएल का इस्तेमाल, जिसका इस्तेमाल एक्सटेंडेड क्लाइंट के लिए किया जाता है. एओएसपी सिस्टम इमेज (जैसे कि एक्सटेंडेड सिस्टम_सर्वर) में भी मौजूद होती है.
सिस्टम और वेंडर के बीच इंटरैक्शन से जुड़ी नीति को
device/manufacturer/device-name/sepolicy अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
डायरेक्ट्री, वेंडर पार्टीशन पर शिप की गई.
यह काम करने के लिए, वेंडर-इमेज सहायता को जोड़ने की ऊपर दी गई स्थिति से मिलता-जुलता है
रेफ़रंस एओएसपी इमेज के साथ, बदलाव किए गए एओएसपी कॉम्पोनेंट को छोड़कर
सिस्टम के साथ ठीक से काम करने के लिए, किसी अन्य नीति का पालन करना ज़रूरी है
विभाजन (यह तब तक ठीक है, जब तक कि उसमें सार्वजनिक एओएसपी प्रकार अब भी मौजूद हो
लेबल).
सिर्फ़ सिस्टम इमेज के साथ सार्वजनिक एओएसपी कॉम्पोनेंट के इंटरैक्शन के लिए नीति
एक्सटेंशन system/sepolicy/private में होने चाहिए.
सिस्टम-इमेज सिर्फ़ एओएसपी इंटरफ़ेस ऐक्सेस करने वाले एक्सटेंशन
उदाहरण: एक नई, गैर-एओएसपी सिस्टम प्रोसेस के लिए ज़रूरी है कि वह किस AOSP पर भरोसा करता है.
यह सिर्फ़ सिस्टम की इमेज के लिए बनी इमेज जैसी ही है
एक्सटेंशन का उदाहरण देख सकते हैं. हालांकि, सिस्टम के नए कॉम्पोनेंट पूरी स्क्रीन पर एक-दूसरे से इंटरैक्ट कर सकते हैं
system/vendor इंटरफ़ेस. नए सिस्टम कॉम्पोनेंट के लिए नीति
system/sepolicy/private में जाएं, जो मान्य है, बशर्ते यह हो
जो पहले से ही AOSP के दायरे में आने वाला है और
system/sepolicy/public (उदाहरण के लिए, किस टाइप और एट्रिब्यूट के लिए ज़रूरी है
और सुविधाएं मौजूद हैं). नीति को डिवाइस से जुड़े खास डिवाइसों में शामिल किया जा सकता है
नीति के हिसाब से, यह अन्य system/sepolicy/private का इस्तेमाल नहीं कर पाएगा
टाइप करने या बदलाव (किसी भी नीति का असर डालने वाले तरीके से) हो सकता है.
अपडेट. सिर्फ़ फ़्रेमवर्क वाले ओटीए में नीति को बदला जा सकता है. हालांकि,
जो AOSP सिस्टम इमेज का इस्तेमाल करते समय मौजूद होती है (जिसमें नया सिस्टम नहीं होगा
या कॉम्पोनेंट).
वेंडर की इमेज ऐसे एक्सटेंशन जो सिस्टम के नए कॉम्पोनेंट इस्तेमाल करते हैं
उदाहरण: क्लाइंट प्रोसेस के लिए इस्तेमाल किया जाने वाला नया गैर-AOSP HAL जोड़ना जिसमें एओएसपी एनालॉग मौजूद नहीं होता. इसलिए, इसके लिए अपना डोमेन होना ज़रूरी है.
AOSP-एक्सटेंशन' से मिलते-जुलते
उदाहरण के लिए, सिस्टम और वेंडर के बीच इंटरैक्शन की नीति
device/manufacturer/device-name/sepolicy
वेंडर पार्टीशन पर शिप की गई डायरेक्ट्री
(यह पक्का करने के लिए कि सिस्टम की नीति को वेंडर से जुड़ी खास जानकारी के बारे में जानकारी न हो). आपने लोगों तक पहुंचाया मुफ़्त में
में नीति का विस्तार करने वाले नए सार्वजनिक प्रकार जोड़ सकते हैं
system/sepolicy/public; ऐसा सिर्फ़
मौजूदा एओएसपी नीति, यानी एओएसपी सार्वजनिक नीति को न हटाएं. नए लोग
टाइप का इस्तेमाल, system/sepolicy/private में नीति के लिए किया जा सकता है. साथ ही,
device/manufacturer/device-name/sepolicy.
ध्यान रखें कि system/sepolicy/public में जोड़ी जाने वाली हर जानकारी,
साथ काम करने से जुड़ी नई गारंटी के बारे में बताती हैं, जिसे
मैपिंग फ़ाइल के तौर पर अपलोड कर सकते हैं. यह फ़ाइल अन्य पाबंदियों पर निर्भर करती है. सिर्फ़ नए टाइप और
इससे जुड़े, अनुमति वाले नियम system/sepolicy/public में जोड़े जा सकते हैं;
एट्रिब्यूट और अन्य नीति स्टेटमेंट का इस्तेमाल नहीं किया जा सकता. इसके अलावा, नए
सार्वजनिक प्रकारों का इस्तेमाल
/vendor नीति.
नीति से जुड़ी स्थितियां काम नहीं करतीं
Android 8.0 और उसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों पर, ये सुविधाएं काम नहीं करती हैं नीति से जुड़ी स्थितियां और उदाहरण.
अन्य जानकारी सिस्टम-इमेज के ऐसे एक्सटेंशन जिन्हें अनुमति की ज़रूरत है नए वेंडर-इमेज कॉम्पोनेंट के लिए एक फ़्रेमवर्क-ओटीए के बाद
उदाहरण: एक नई गैर-एओएसपी सिस्टम प्रोसेस, जिसकी अपनी खुद की प्रोसेस ज़रूरी है जिसे Android की अगली रिलीज़ में जोड़ा गया है और उसे नए, एओएसपी एचएएल से जुड़ा नहीं है.
इसके समान
नया
नए सिस्टम को छोड़कर, सिस्टम और वेंडर के कॉम्पोनेंट का इंटरैक्शन (नॉन-एओएसपी)
टाइप को
सिर्फ़ फ़्रेमवर्क के लिए ओटीए. हालांकि, नीति में नया टाइप जोड़ा जा सकता है
system/sepolicy/public, मौजूदा वेंडर नीति के बारे में कोई जानकारी नहीं है
को भी ट्रैक किया जाएगा, क्योंकि यह सिर्फ़ Android 8.0 सिस्टम की सार्वजनिक नीति को ट्रैक कर रहा है.
एओएसपी किसी एट्रिब्यूट (उदाहरण के लिए,
hal_foo एट्रिब्यूट) है, लेकिन एट्रिब्यूट पार्टनर एक्सटेंशन के तौर पर नहीं हैं
system/sepolicy/public में इस्तेमाल किया जा सकता है. यह तरीका इनके लिए उपलब्ध नहीं है:
की अनुमति नहीं है. यह ज़रूरी है कि ऐक्सेस, पहले से मौजूद सार्वजनिक तौर पर उपलब्ध हो.
उदाहरण: सिस्टम प्रोसेस (AOSP या गैर-AOSP) में बदलाव करने के लिए नए और नॉन-एओएसपी वेंडर कॉम्पोनेंट के साथ इंटरैक्ट करने के तरीके को बदलें.
सिस्टम इमेज पर यह नीति किसी खास विषय की जानकारी के बिना लिखी जानी चाहिए
वेंडर कस्टमाइज़ेशन. एओएसपी में कुछ खास इंटरफ़ेस से जुड़ी नीति
को सिस्टम/सेनीति/सार्वजनिक में एट्रिब्यूट के ज़रिए दिखाया जाता है, ताकि वेंडर नीति
इन एट्रिब्यूट का इस्तेमाल करने वाली आने वाली सिस्टम नीति में ऑप्ट-इन करें. हालांकि,
system/sepolicy/public में एट्रिब्यूट एक्सटेंशन नहीं हैं
काम नहीं करता है, इसलिए सभी नीति जो यह तय करती हैं कि सिस्टम के कॉम्पोनेंट कैसे इंटरैक्ट करते हैं
इसे नए वेंडर कॉम्पोनेंट से कनेक्ट किया गया हो. साथ ही, इसे एट्रिब्यूट की मदद से हैंडल न किया जा रहा हो
एओएसपी system/sepolicy/public में मौजूद है)
device/manufacturer/device-name/sepolicy.
इसका मतलब है कि सिस्टम के टाइप नहीं बदले जा सकते
सिर्फ़ फ़्रेमवर्क-ओनली ओटीए के हिस्से के तौर पर, वेंडर टाइप को ऐक्सेस दिया जाता है.