SELinux की बुनियादी सुविधा को इंटिग्रेट करने और नतीजों का अच्छी तरह से विश्लेषण करने के बाद, Android ऑपरेटिंग सिस्टम में अपनी पसंद के मुताबिक बदलाव करने के लिए, अपनी नीति सेटिंग जोड़ी जा सकती हैं. इन नीतियों को अब भी Android के साथ काम करने वाले डिवाइसों के लिए बने कार्यक्रम की ज़रूरी शर्तों को पूरा करना होगा. साथ ही, इन नीतियों में डिफ़ॉल्ट SELinux सेटिंग को नहीं हटाया जाना चाहिए.
मैन्युफ़ैक्चरर को SELinux की मौजूदा नीति नहीं हटानी चाहिए. ऐसा न करने पर, Android SELinux के लागू होने और उन ऐप्लिकेशन के काम करने में समस्या आ सकती है जिन पर यह लागू होता है. इसमें तीसरे पक्ष के ऐसे ऐप्लिकेशन शामिल हैं जिन्हें नीति का पालन करने और काम करने के लिए, बेहतर बनाने की ज़रूरत होगी. SELinux की सुविधा वाले डिवाइसों पर काम करना जारी रखने के लिए, ऐप्लिकेशन में कोई बदलाव नहीं करना चाहिए.
SELinux को पसंद के मुताबिक बनाते समय, इन बातों का ध्यान रखें:
- सभी नए डेमन के लिए SELinux नीति लिखना
- ज़रूरत पड़ने पर, पहले से तय किए गए डोमेन का इस्तेमाल करें
initसेवा के तौर पर शुरू की गई किसी भी प्रोसेस को डोमेन असाइन करना- नीति लिखने से पहले, मैक्रो के बारे में जानें
- AOSP में मुख्य नीति में बदलाव सबमिट करना
साथ ही, इन बातों का ध्यान रखें:
- काम न करने वाली नीति बनाना
- असली उपयोगकर्ता के लिए नीति को पसंद के मुताबिक बनाने की अनुमति देना
- MDM नीति में पसंद के मुताबिक बदलाव करने की अनुमति देना
- नीति के उल्लंघन की वजह से, उपयोगकर्ताओं को डराना
- बैकडोर जोड़ना
खास ज़रूरी शर्तों के बारे में जानने के लिए, Android के साथ काम करने की जानकारी देने वाले दस्तावेज़ का कर्नल की सुरक्षा से जुड़ी सुविधाएं सेक्शन देखें.
SELinux, व्हाइटलिस्ट वाले तरीके का इस्तेमाल करता है. इसका मतलब है कि अनुमति देने के लिए, नीति में साफ़ तौर पर सभी ऐक्सेस की अनुमति दी जानी चाहिए. Android की डिफ़ॉल्ट SELinux नीति, पहले से ही Android Open Source Project के साथ काम करती है. इसलिए, आपको SELinux की सेटिंग में किसी भी तरह का बदलाव करने की ज़रूरत नहीं है. अगर आपको SELinux की सेटिंग में बदलाव करना है, तो ज़रूरी है कि आप मौजूदा ऐप्लिकेशन के काम करने में कोई रुकावट न डालें. शुरू करने के लिए:
- Android के सबसे नए वर्शन का कोर इस्तेमाल करें.
- कम से कम अधिकारों के सिद्धांत को अपनाएं.
- Android में सिर्फ़ अपने जोड़े गए आइटम की जानकारी दें. डिफ़ॉल्ट नीति, Android Open Source Project के कोडबेस के साथ अपने-आप काम करती है.
- सॉफ़्टवेयर कॉम्पोनेंट को ऐसे मॉड्यूल में बांटें जो अलग-अलग टास्क करते हों.
- SELinux की ऐसी नीतियां बनाएं जो उन टास्क को अलग रखें जो काम के नहीं हैं.
- उन नीतियों को
/device/manufacturer/device-name/sepolicyडायरेक्ट्री में मौजूद*.teफ़ाइलों (SELinux नीति के सोर्स फ़ाइलों के लिए एक्सटेंशन) में डालें. साथ ही, उन्हें अपने बिल्ड में शामिल करने के लिएBOARD_SEPOLICYवैरिएबल का इस्तेमाल करें. - शुरुआत में, नए डोमेन के लिए अनुमति दें. ऐसा करने के लिए, डोमेन की
.teफ़ाइल में अनुमति देने वाले एलान का इस्तेमाल किया जाता है. - नतीजों का विश्लेषण करें और डोमेन की परिभाषाओं को बेहतर बनाएं.
- जब userdebug के बिल्ड में कोई और अनुमति न दिखे, तो अनुमति देने वाला एलान हटाएं.
SELinux नीति में किए गए बदलाव को इंटिग्रेट करने के बाद, अपने डेवलपमेंट वर्कफ़्लो में एक चरण जोड़ें. इससे यह पक्का किया जा सकेगा कि आने वाले समय में SELinux के साथ काम किया जा सके. सॉफ़्टवेयर डेवलपमेंट की सही प्रोसेस में, SELinux की नीति सिर्फ़ तब बदलती है, जब सॉफ़्टवेयर मॉडल में बदलाव होता है, न कि नीति को लागू करने के तरीके में.
SELinux को पसंद के मुताबिक बनाने के लिए, सबसे पहले Android में जोड़े गए बदलावों की जांच करें. अगर आपने कोई ऐसा कॉम्पोनेंट जोड़ा है जो नया फ़ंक्शन करता है, तो पक्का करें कि वह कॉम्पोनेंट, Android की सुरक्षा नीति के साथ-साथ OEM की बनाई गई उससे जुड़ी नीति का पालन करता हो. इसके बाद ही, नीति लागू करने वाले मोड को चालू करें.
ग़ैर-ज़रूरी समस्याओं से बचने के लिए, ऐप्लिकेशन को ज़्यादा से ज़्यादा डिवाइसों के साथ काम करने लायक और ज़्यादा से ज़्यादा सुविधाओं के साथ काम करने लायक बनाना बेहतर होता है. ऐसा न करने पर, डिवाइस के फ़ंक्शन काम नहीं करते. इसके उलट, अगर आपके बदलावों से दूसरों को फ़ायदा होगा, तो आपको डिफ़ॉल्ट SELinux नीति में किए गए बदलावों को पैच के तौर पर सबमिट करना चाहिए. अगर पैच को डिफ़ॉल्ट सुरक्षा नीति पर लागू किया जाता है, तो आपको Android के हर नए वर्शन के साथ यह बदलाव करने की ज़रूरत नहीं होगी.
नीति के स्टेटमेंट के उदाहरण
SELinux, M4 कंप्यूटर भाषा पर आधारित है. इसलिए, यह समय बचाने के लिए कई तरह के मैक्रो को सपोर्ट करता है.
नीचे दिए गए उदाहरण में, सभी डोमेन को /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) से इनहेरिट करता है. पिछले स्टेटमेंट के उदाहरणों से, डीएचसीपी /dev/null से पढ़ सकता है और उसमें लिख सकता है.
दूसरी लाइन में, DHCP को अनुमति वाले डोमेन के तौर पर पहचाना गया है.
init_daemon_domain(dhcp) लाइन में, नीति के मुताबिक डीएचसीपी को init से जनरेट किया जाता है और उसे init से संपर्क करने की अनुमति होती है.
net_domain(dhcp) लाइन में, नीति डीएचसीपी को net डोमेन की सामान्य नेटवर्क सुविधाओं का इस्तेमाल करने की अनुमति देती है. जैसे, टीसीपी पैकेट पढ़ना और लिखना, सॉकेट के ज़रिए कम्यूनिकेट करना, और डीएनएस अनुरोध करना.
allow dhcp proc_net:file write; लाइन में, नीति के मुताबिक
DHCP, /proc में मौजूद कुछ फ़ाइलों में डेटा सेव कर सकता है. इस लाइन में, SELinux की फ़ाइल लेबल करने की बेहतर सुविधा के बारे में बताया गया है. यह proc_net लेबल का इस्तेमाल करता है, ताकि सिर्फ़ /proc/sys/net में मौजूद फ़ाइलों को लिखने का ऐक्सेस सीमित किया जा सके.
उदाहरण के आखिरी ब्लॉक में, allow dhcp netd:fd use; से शुरू होने वाले उदाहरण में दिखाया गया है कि ऐप्लिकेशन को एक-दूसरे के साथ कैसे इंटरैक्ट करने की अनुमति दी जा सकती है. नीति के मुताबिक, DHCP और netd, फ़ाइल डिस्क्रिप्टर, FIFO फ़ाइलों, डेटाग्राम सॉकेट, और यूनिक्स स्ट्रीम सॉकेट के ज़रिए एक-दूसरे से कम्यूनिकेट कर सकते हैं. DHCP, सिर्फ़ डेटाग्राम सॉकेट और यूनिक्स स्ट्रीम सॉकेट को पढ़ सकता है और उनमें डेटा लिख सकता है. हालांकि, वह उन्हें न तो बना सकता है और न ही खोल सकता है.
उपलब्ध कंट्रोल
| कक्षा | अनुमति |
|---|---|
| फ़ाइल |
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 |
|
ज़्यादा देखें |
और भी बहुत कुछ |
neverallow नियम
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 और इसके बाद के वर्शन में, वेंडर की SELinux नीति के लिए दिशा-निर्देश दिए गए हैं. इसमें, Android Open Source Project (AOSP) SEPolicy और SEPolicy एक्सटेंशन के बारे में जानकारी भी शामिल है. SELinux की नीति को सभी पार्टिशन और Android वर्शन के साथ काम करने लायक बनाने के तरीके के बारे में ज़्यादा जानने के लिए, काम करने की सुविधा देखें.
नीति का प्लेसमेंट
Android 7.0 और इससे पहले के वर्शन में, डिवाइस बनाने वाली कंपनियां BOARD_SEPOLICY_DIRS में नीति जोड़ सकती थीं. इसमें, अलग-अलग तरह के डिवाइसों पर AOSP की नीति को बेहतर बनाने के लिए बनाई गई नीति भी शामिल थी. Android 8.0 और इसके बाद के वर्शन में, BOARD_SEPOLICY_DIRS में नीति जोड़ने पर, वह नीति सिर्फ़ वेंडर की इमेज में दिखती है.
Android 8.0 और इसके बाद के वर्शन में, AOSP में नीति इन जगहों पर मौजूद होती है:
- system/sepolicy/public. इसमें वह नीति शामिल होती है जिसे वेंडर के हिसाब से बनी नीति में इस्तेमाल करने के लिए, एक्सपोर्ट किया गया है. यह जानकारी, Android 8.0 के काम करने के इन्फ़्रास्ट्रक्चर में सेव हो जाती है.
सार्वजनिक नीति सभी रिलीज़ में बनी रहती है, ताकि आप अपनी पसंद के मुताबिक बनाई गई नीति में
/publicकुछ भी शामिल कर सकें. इस वजह से,/publicमें जो नीतियां लागू की जा सकती हैं उन पर ज़्यादा पाबंदियां होती हैं. इसे प्लैटफ़ॉर्म का एक्सपोर्ट किया गया नीति एपीआई मानें:/systemऔर/vendorके बीच के इंटरफ़ेस से जुड़ी कोई भी चीज़ यहां आती है. - system/sepolicy/private. इसमें सिस्टम इमेज के काम करने के लिए ज़रूरी नीति शामिल होती है. हालांकि, वेंडर इमेज की नीति में इसकी जानकारी नहीं होनी चाहिए.
- system/sepolicy/vendor. इसमें उन कॉम्पोनेंट के लिए नीति शामिल होती है जो
/vendorमें शामिल होते हैं, लेकिन कोर प्लैटफ़ॉर्म ट्री में मौजूद होते हैं. ये डिवाइस के हिसाब से बनी डायरेक्ट्री में मौजूद नहीं होते. यह डिवाइसों और ग्लोबल कॉम्पोनेंट के बीच, बिल्ड सिस्टम के अंतर का एक आर्टफ़ैक्ट है. यह डिवाइस के हिसाब से बनी नीति का हिस्सा है. इस नीति के बारे में नीचे बताया गया है. - device/manufacturer/device-name/sepolicy. इसमें डिवाइस के हिसाब से बनी नीति शामिल है. इसमें डिवाइस के हिसाब से नीति में किए गए बदलाव भी शामिल हैं. Android 8.0 और उसके बाद के वर्शन में, ये बदलाव वेंडर इमेज पर मौजूद कॉम्पोनेंट के लिए बनी नीति से मेल खाते हैं.
Android 11 और उसके बाद के वर्शन में, system_ext और प्रॉडक्ट के partition में, partition के हिसाब से बनी नीतियां भी शामिल हो सकती हैं. system_ext और प्रॉडक्ट की नीतियां, सार्वजनिक और निजी में भी बांटी जाती हैं. वेंडर, system_ext और प्रॉडक्ट की सार्वजनिक नीतियों का इस्तेमाल कर सकते हैं, जैसे कि सिस्टम की नीति.
SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS. इसमें वेंडर के हिसाब से बनी नीति में इस्तेमाल करने के लिए, एक्सपोर्ट की गई नीति शामिल होती है. system_ext पार्टीशन में इंस्टॉल किया गया.SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS. इसमें system_ext इमेज के काम करने के लिए ज़रूरी नीति शामिल होती है. हालांकि, वेंडर इमेज की नीति को इसकी जानकारी नहीं होनी चाहिए. system_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 सिस्टम इमेज के साथ, डिवाइस की नीति में मौजूद होती है.
AOSP के साथ काम करने के लिए, वेंडर-इमेज की सहायता
उदाहरण: वेंडर इमेज से hwservicemanager के साथ रजिस्टर की गई नई प्रोसेस जोड़ना, जो AOSP के तय किए गए एचएएल को लागू करती है.
Android के पिछले वर्शन वाले डिवाइसों की तरह ही, device/manufacturer/device-name/sepolicy में डिवाइस के हिसाब से कस्टमाइज़ेशन करें.
system/sepolicy/public/ के हिस्से के तौर पर एक्सपोर्ट की गई नीति, इस्तेमाल के लिए उपलब्ध है. साथ ही, इसे वेंडर की नीति के हिस्से के तौर पर शिप किया जाता है. सार्वजनिक नीति के टाइप और एट्रिब्यूट का इस्तेमाल, नए नियमों में किया जा सकता है. इन नियमों से, वेंडर के हिसाब से नए बिट के साथ इंटरैक्शन तय किए जाते हैं. हालांकि, इन नियमों के लिए neverallowसंबंधित पाबंदियां लागू होती हैं. सिर्फ़ वेंडर के मामले की तरह, यहां नई नीति को सिर्फ़ फ़्रेमवर्क वाले ओटीए के हिस्से के तौर पर अपडेट नहीं किया जाएगा. यह नीति, रेफ़रंस AOSP सिस्टम इमेज वाले डिवाइस पर, नीति के साथ मौजूद है.
सिर्फ़ सिस्टम इमेज वाले एक्सटेंशन
उदाहरण: ऐसी नई सेवा जोड़ना (servicemanager के साथ रजिस्टर की गई) जो सिर्फ़ सिस्टम इमेज की अन्य प्रोसेस से ऐक्सेस की जाती है.
इस नीति को system/sepolicy/private में जोड़ें. पार्टनर सिस्टम इमेज में फ़ंक्शन को चालू करने के लिए, अतिरिक्त प्रोसेस या ऑब्जेक्ट जोड़े जा सकते हैं. हालांकि, इसके लिए ज़रूरी है कि उन नए बिट को वेंडर इमेज के नए कॉम्पोनेंट के साथ इंटरैक्ट करने की ज़रूरत न पड़े. खास तौर पर, ऐसी प्रोसेस या ऑब्जेक्ट को वेंडर इमेज की नीति के बिना पूरी तरह से काम करना चाहिए. system/sepolicy/public से एक्सपोर्ट की गई नीति, यहां वैसे ही उपलब्ध है जैसे कि सिर्फ़ वेंडर-इमेज वाले एक्सटेंशन के लिए उपलब्ध है. यह नीति, सिस्टम इमेज का हिस्सा है और इसे सिर्फ़ फ़्रेमवर्क वाले ओटीए में अपडेट किया जा सकता है. हालांकि, रेफ़रंस AOSP सिस्टम इमेज का इस्तेमाल करने पर, यह नीति मौजूद नहीं होगी.
वेंडर-इमेज एक्सटेंशन, जो एक्सटेंडेड AOSP कॉम्पोनेंट दिखाते हैं
उदाहरण: AOSP HAL के बजाय, नया HAL. इसका इस्तेमाल उन एक्सटेंडेड क्लाइंट के लिए किया जाता है जो AOSP सिस्टम इमेज में भी मौजूद होते हैं. जैसे, एक्सटेंडेड system_server.
सिस्टम और वेंडर के बीच इंटरैक्शन की नीति, वेंडर के पार्टीशन पर शिप की गई device/manufacturer/device-name/sepolicy डायरेक्ट्री में शामिल होनी चाहिए.
यह ऊपर बताई गई उस स्थिति से मिलता-जुलता है जिसमें रेफ़रंस AOSP इमेज के साथ काम करने के लिए, वेंडर-इमेज के लिए सहायता जोड़ी जाती है. हालांकि, बदले गए AOSP कॉम्पोनेंट को सिस्टम के बाकी हिस्सों के साथ सही तरीके से काम करने के लिए, अतिरिक्त नीति की भी ज़रूरत पड़ सकती है. हालांकि, जब तक उनके पास सार्वजनिक AOSP टाइप के लेबल मौजूद हैं, तब तक यह ठीक है.
सिर्फ़ सिस्टम इमेज के लिए बने एक्सटेंशन के साथ, सार्वजनिक AOSP कॉम्पोनेंट के इंटरैक्शन की नीति system/sepolicy/private में होनी चाहिए.
सिस्टम-इमेज एक्सटेंशन, जो सिर्फ़ AOSP इंटरफ़ेस को ऐक्सेस करते हैं
उदाहरण: AOSP सिस्टम प्रोसेस के अलावा, किसी नई प्रोसेस को उस एचएएल को ऐक्सेस करना होगा जिस पर AOSP निर्भर करता है.
यह सिर्फ़ सिस्टम-इमेज वाले एक्सटेंशन के उदाहरण जैसा ही है. हालांकि, नए सिस्टम कॉम्पोनेंट, system/vendor इंटरफ़ेस में इंटरैक्ट कर सकते हैं. नए सिस्टम कॉम्पोनेंट के लिए बनी नीति, system/sepolicy/private में होनी चाहिए. हालांकि, यह स्वीकार तब ही किया जाएगा, जब वह system/sepolicy/public में AOSP के पहले से मौजूद इंटरफ़ेस के ज़रिए हो. इसका मतलब है कि उसमें फ़ंक्शन के लिए ज़रूरी टाइप और एट्रिब्यूट मौजूद होने चाहिए. नीति को डिवाइस के हिसाब से बनी नीति में शामिल किया जा सकता है. हालांकि, सिर्फ़ फ़्रेमवर्क में किए गए अपडेट की वजह से, system/sepolicy/private के अन्य टाइप का इस्तेमाल नहीं किया जा सकेगा या नीति पर असर डालने वाले किसी भी तरीके से बदलाव नहीं किया जा सकेगा. नीति को सिर्फ़ फ़्रेमवर्क वाले ओटीए में बदला जा सकता है. हालांकि, AOSP सिस्टम इमेज का इस्तेमाल करने पर, यह नीति मौजूद नहीं होगी. इसमें नया सिस्टम कॉम्पोनेंट भी नहीं होगा.
वेंडर-इमेज एक्सटेंशन, जो नए सिस्टम कॉम्पोनेंट दिखाते हैं
उदाहरण: AOSP एनालॉग के बिना, क्लाइंट प्रोसेस के इस्तेमाल के लिए नया, नॉन-AOSP HAL जोड़ना. इसलिए, इसके लिए अपना डोमेन ज़रूरी है.
AOSP-एक्सटेंशन के उदाहरण की तरह ही, सिस्टम और वेंडर के बीच इंटरैक्शन के लिए बनी नीति, वेंडर के पार्टीशन में शिप की गई device/manufacturer/device-name/sepolicy डायरेक्ट्री में होनी चाहिए. इससे यह पक्का किया जा सकेगा कि सिस्टम की नीति में वेंडर से जुड़ी जानकारी शामिल न हो. system/sepolicy/public में नीति को बढ़ाने वाले नए सार्वजनिक टाइप जोड़े जा सकते हैं. ऐसा सिर्फ़ मौजूदा AOSP नीति के साथ किया जाना चाहिए. इसका मतलब है कि AOSP की सार्वजनिक नीति को न हटाएं. इसके बाद, system/sepolicy/private और device/manufacturer/device-name/sepolicy में नीति के लिए, नए सार्वजनिक टाइप का इस्तेमाल किया जा सकता है.
ध्यान रखें कि system/sepolicy/public में हर बदलाव, काम करने की नई गारंटी को ज़ाहिर करके जटिलता बढ़ाता है. इस गारंटी को मैपिंग फ़ाइल में ट्रैक किया जाना चाहिए. साथ ही, इस पर अन्य पाबंदियां भी लागू होती हैं. system/sepolicy/public में सिर्फ़ नए टाइप और उनसे जुड़े अनुमति वाले नियम जोड़े जा सकते हैं. इसमें एट्रिब्यूट और नीति के अन्य स्टेटमेंट नहीं जोड़े जा सकते. इसके अलावा, /vendor नीति में, नए सार्वजनिक टाइप का इस्तेमाल करके, ऑब्जेक्ट को सीधे लेबल नहीं किया जा सकता.
नीति से जुड़ी ऐसी स्थितियां जिनमें यह सुविधा काम नहीं करती
Android 8.0 और उसके बाद के वर्शन वाले डिवाइसों पर, नीति से जुड़ी इस स्थिति और उदाहरणों का इस्तेमाल नहीं किया जा सकता.
सिस्टम-इमेज के अतिरिक्त एक्सटेंशन, जिन्हें सिर्फ़ फ़्रेमवर्क के लिए ओटीए के बाद, नए वेंडर-इमेज कॉम्पोनेंट की अनुमति की ज़रूरत होती है
उदाहरण: Android के अगले वर्शन में, AOSP से बाहर की एक नई सिस्टम प्रोसेस जोड़ी गई है. इसके लिए, अपने डोमेन की ज़रूरत होती है. साथ ही, इसे AOSP से बाहर के नए एचएएल का ऐक्सेस चाहिए.
यह नए (नॉन-AOSP) सिस्टम और वेंडर कॉम्पोनेंट के इंटरैक्शन जैसा ही है. हालांकि, नए सिस्टम टाइप को सिर्फ़ फ़्रेमवर्क वाले ओटीए में पेश किया गया है. हालांकि, system/sepolicy/public में नीति में नया टाइप जोड़ा जा सकता है, लेकिन वेंडर की मौजूदा नीति में नए टाइप की जानकारी नहीं है. इसकी वजह यह है कि यह सिर्फ़ Android 8.0 सिस्टम की सार्वजनिक नीति को ट्रैक कर रही है.
AOSP, एट्रिब्यूट (उदाहरण के लिए, hal_foo एट्रिब्यूट) के ज़रिए, वेंडर से मिले संसाधनों को दिखाकर इस समस्या को हल करता है. हालांकि, system/sepolicy/public में एट्रिब्यूट पार्टनर एक्सटेंशन काम नहीं करते, इसलिए यह तरीका वेंडर नीति के लिए उपलब्ध नहीं है. ऐक्सेस, पहले से मौजूद सार्वजनिक टाइप से दिया जाना चाहिए.
उदाहरण: किसी सिस्टम प्रोसेस (AOSP या नॉन-AOSP) में बदलाव करने पर, यह ज़रूरी है कि वह नॉन-AOSP वेंडर के नए कॉम्पोनेंट के साथ इंटरैक्ट करने का तरीका बदल दे.
सिस्टम इमेज की नीति, वेंडर के कस्टमाइज़ेशन के बारे में जानकारी के बिना लिखी जानी चाहिए. इसलिए, AOSP में खास इंटरफ़ेस से जुड़ी नीति, system/sepolicy/public में मौजूद एट्रिब्यूट के ज़रिए दिखाई जाती है, ताकि वेंडर की नीति, आने वाले समय में इन एट्रिब्यूट का इस्तेमाल करने वाली सिस्टम नीति में ऑप्ट-इन कर सके. हालांकि, system/sepolicy/public में एट्रिब्यूट एक्सटेंशन काम नहीं करते. इसलिए, सिस्टम कॉम्पोनेंट के नए वेंडर कॉम्पोनेंट के साथ इंटरैक्ट करने का तरीका बताने वाली सभी नीतियां device/manufacturer/device-name/sepolicy में होनी चाहिए. साथ ही, वे नीतियां AOSP system/sepolicy/public में पहले से मौजूद एट्रिब्यूट से मैनेज नहीं की जानी चाहिए.
इसका मतलब है कि सिर्फ़ फ़्रेमवर्क वाले ओटीए के हिस्से के तौर पर, सिस्टम टाइप वेंडर टाइप के लिए अनुमति वाले ऐक्सेस में बदलाव नहीं कर सकते.