SELinux को पसंद के मुताबिक बनाना

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

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

SELinux को पसंद के मुताबिक बनाते समय, इन बातों का ध्यान रखें:

• सभी नए डेमन के लिए SELinux नीति लिखना
• जहां भी ज़रूरी हो, पहले से तय डोमेन का इस्तेमाल करें
• init सेवा के तौर पर शुरू की गई किसी भी प्रोसेस को डोमेन असाइन करना
• नीति लिखने से पहले मैक्रो को अच्छी तरह समझ लें
• AOSP की मुख्य नीति में बदलाव सबमिट करना

साथ ही, इन बातों का ध्यान रखें:

• काम न करने वाली नीति बनाना
• असली उपयोगकर्ता के लिए नीति को पसंद के मुताबिक बनाने की अनुमति देना
• एमडीएम से जुड़ी नीतियां पसंद के मुताबिक बनाने की अनुमति दें
• नीति के उल्लंघन की वजह से, उपयोगकर्ताओं को डराना
• बैकडोर जोड़ें

खास ज़रूरी शर्तों के बारे में जानने के लिए, Android के साथ काम करने की जानकारी देने वाले दस्तावेज़ का कर्नल की सुरक्षा से जुड़ी सुविधाएं सेक्शन देखें.

SELinux, व्हाइटलिस्ट वाले तरीके का इस्तेमाल करता है. इसका मतलब है कि अनुमति देने के लिए, नीति में साफ़ तौर पर सभी ऐक्सेस की अनुमति होनी चाहिए. Android की डिफ़ॉल्ट SELinux नीति पहले से ही Android ओपन सोर्स प्रोजेक्ट का समर्थन करती है, इसलिए आपको किसी भी तरह से SELinux सेटिंग में बदलाव करने की ज़रूरत नहीं है. अगर आपको SELinux की सेटिंग में बदलाव करना है, तो ज़रूरी है कि आप मौजूदा ऐप्लिकेशन के काम करने में कोई रुकावट न डालें. शुरू करने के लिए:

1. Android के सबसे नए वर्शन का कोर इस्तेमाल करें.
2. कम से कम अधिकारों के सिद्धांत को अपनाएं.
3. Android में सिर्फ़ अपनी ओर से जोड़ी गई सुविधाओं पर ध्यान दें. डिफ़ॉल्ट नीति, Android Open Source Project के कोडबेस के साथ अपने-आप काम करती है.
4. सॉफ़्टवेयर कॉम्पोनेंट को ऐसे मॉड्यूल में बांटें जो अलग-अलग टास्क करते हों.
5. SELinux की ऐसी नीतियां बनाएं जो उन टास्क को अलग रखें जो काम के नहीं हैं.
6. उन नीतियों को /device/manufacturer/device-name/sepolicy डायरेक्ट्री में मौजूद *.te फ़ाइलों (SELinux नीति के सोर्स फ़ाइलों के लिए एक्सटेंशन) में डालें. साथ ही, उन्हें अपने बिल्ड में शामिल करने के लिए BOARD_SEPOLICY वैरिएबल का इस्तेमाल करें.
7. शुरुआत में नए डोमेन को अनुमति दें. ऐसा डोमेन की .te फ़ाइल में, अनुमति वाली घोषणा का इस्तेमाल करके किया जाता है.
8. नतीजों का विश्लेषण करें और डोमेन की परिभाषाओं को बेहतर बनाएं.
9. जब 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 से लिया गया है और इसके पास इसके साथ संपर्क करने की अनुमति है.

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

कभी भी अनुमति न दें

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 की ओर से दी गई एओएसपी सिस्टम इमेज के साथ काम करना चाहिए. साथ ही, इस इमेज पर सीटीएस पास करना ज़रूरी है. इन ज़रूरी शर्तों को पूरा करने पर, फ़्रेमवर्क और वेंडर कोड को बेहतर तरीके से अलग किया जा सकता है. ऐसे डिवाइसों पर ये काम किए जा सकते हैं.

सिर्फ़ वेंडर की इमेज के लिए एक्सटेंशन

उदाहरण: वेंडर इमेज से vndservicemanager में नई सेवा जोड़ना, जो वेंडर इमेज की प्रोसेस के साथ काम करती है.

Android के पिछले वर्शन के साथ लॉन्च होने वाले डिवाइसों की तरह ही, device/manufacturer/device-name/sepolicy में डिवाइस के हिसाब से पसंद के मुताबिक बनाने की सुविधा जोड़ें. वेंडर कॉम्पोनेंट, सिर्फ़ दूसरे वेंडर कॉम्पोनेंट के साथ कैसे इंटरैक्ट करते हैं, यह तय करने वाली नई नीति में सिर्फ़ device/manufacturer/device-name/sepolicy में मौजूद टाइप शामिल होने चाहिए. यहां दी गई नीति, वेंडर पर कोड को काम करने की अनुमति देती है. इसे सिर्फ़ फ़्रेमवर्क-ओनली ओटीए के हिस्से के तौर पर अपडेट नहीं किया जाएगा. साथ ही, यह एओएसपी सिस्टम इमेज वाले डिवाइस पर एक साथ लागू की गई नीति में मौजूद है.

AOSP के साथ काम करने के लिए, वेंडर-इमेज की सहायता

उदाहरण: वेंडर इमेज से hwservicemanager के साथ रजिस्टर की गई नई प्रोसेस जोड़ना, जो AOSP के तय किए गए एचएएल को लागू करती है.

Android के पिछले वर्शन वाले डिवाइसों की तरह ही, device/manufacturer/device-name/sepolicy में डिवाइस के हिसाब से कस्टमाइज़ेशन करें. system/sepolicy/public/ के हिस्से के तौर पर एक्सपोर्ट की गई नीति, इस्तेमाल के लिए उपलब्ध है. साथ ही, इसे वेंडर की नीति के हिस्से के तौर पर शिप किया जाता है. सार्वजनिक नीति के टाइप और एट्रिब्यूट का इस्तेमाल, नए नियमों में किया जा सकता है. इन नियमों से, वेंडर के हिसाब से नए बिट के साथ इंटरैक्शन तय होते हैं. हालांकि, इन नियमों के लिए neverallowसंबंधित पाबंदियां लागू होती हैं. सिर्फ़ वेंडर के मामले में, यहां दी गई नई नीति को सिर्फ़ फ़्रेमवर्क वाले ओटीए के हिस्से के तौर पर अपडेट नहीं किया जाएगा. साथ ही, यह एओएसपी सिस्टम इमेज वाले डिवाइस पर एक साथ लागू की गई नीति में मौजूद है.

सिर्फ़ सिस्टम इमेज वाले एक्सटेंशन

उदाहरण: ऐसी नई सेवा जोड़ना (servicemanager के साथ रजिस्टर की गई) जो सिर्फ़ सिस्टम इमेज की अन्य प्रोसेस से ऐक्सेस की जाती है.

इस नीति को system/sepolicy/private में जोड़ें. पार्टनर सिस्टम इमेज में फ़ंक्शन को चालू करने के लिए, अतिरिक्त प्रोसेस या ऑब्जेक्ट जोड़े जा सकते हैं. हालांकि, इसके लिए ज़रूरी है कि उन नए बिट को वेंडर इमेज के नए कॉम्पोनेंट के साथ इंटरैक्ट करने की ज़रूरत न पड़े. खास तौर पर, ऐसी प्रोसेस या ऑब्जेक्ट को वेंडर इमेज की नीति के बिना पूरी तरह से काम करना चाहिए. system/sepolicy/public से एक्सपोर्ट की गई नीति, यहां वैसे ही उपलब्ध है जैसे कि सिर्फ़ वेंडर-इमेज वाले एक्सटेंशन के लिए उपलब्ध है. यह नीति, सिस्टम इमेज का हिस्सा है और इसे सिर्फ़ फ़्रेमवर्क वाले ओटीए में अपडेट किया जा सकता है. हालांकि, रेफ़रंस AOSP सिस्टम इमेज का इस्तेमाल करने पर, यह नीति मौजूद नहीं होगी.

वेंडर-इमेज एक्सटेंशन, जो बड़े किए गए एओएसपी कॉम्पोनेंट के लिए सेवा देते हैं

उदाहरण: AOSP HAL के बजाय, नया HAL. इसका इस्तेमाल उन एक्सटेंडेड क्लाइंट के लिए किया जाता है जो AOSP सिस्टम इमेज में भी मौजूद होते हैं. जैसे, एक्सटेंडेड system_server.

सिस्टम और वेंडर के बीच इंटरैक्शन की नीति, वेंडर के पार्टीशन पर शिप की गई device/manufacturer/device-name/sepolicy डायरेक्ट्री में शामिल होनी चाहिए. यह ऊपर बताई गई उस स्थिति से मिलता-जुलता है जिसमें रेफ़रंस AOSP इमेज के साथ काम करने के लिए, वेंडर-इमेज के लिए सहायता जोड़ी जाती है. हालांकि, बदले गए AOSP कॉम्पोनेंट को सिस्टम के बाकी हिस्सों के साथ सही तरीके से काम करने के लिए, अतिरिक्त नीति की भी ज़रूरत पड़ सकती है. हालांकि, जब तक उनके पास सार्वजनिक AOSP टाइप के लेबल मौजूद हैं, तब तक यह ठीक है.

सिर्फ़ सिस्टम इमेज के एक्सटेंशन के साथ, सार्वजनिक AOSP कॉम्पोनेंट के इंटरैक्शन की नीति system/sepolicy/private में होनी चाहिए.

सिस्टम-इमेज एक्सटेंशन जो सिर्फ़ एओएसपी इंटरफ़ेस ऐक्सेस करते हैं

उदाहरण: एक नई, गैर-एओएसपी सिस्टम प्रोसेस के लिए ऐसे एचएएल को ऐक्सेस करना ज़रूरी है जिस पर एओएसपी निर्भर करता है.

यह सिर्फ़ सिस्टम इमेज वाले एक्सटेंशन के उदाहरण जैसा ही है. हालांकि, नए सिस्टम कॉम्पोनेंट, system/vendor इंटरफ़ेस में इंटरैक्ट कर सकते हैं. नए सिस्टम कॉम्पोनेंट के लिए बनी नीति, system/sepolicy/private में होनी चाहिए. हालांकि, यह स्वीकार तब ही किया जाएगा, जब वह system/sepolicy/public में AOSP के पहले से मौजूद इंटरफ़ेस के ज़रिए हो. इसका मतलब है कि उसमें फ़ंक्शन के लिए ज़रूरी टाइप और एट्रिब्यूट मौजूद होने चाहिए. नीति को डिवाइस के हिसाब से बनी नीति में शामिल किया जा सकता है. हालांकि, सिर्फ़ फ़्रेमवर्क में किए गए अपडेट की वजह से, यह अन्य system/sepolicy/private टाइप का इस्तेमाल नहीं कर पाएगा या नीति पर असर डालने वाले किसी भी तरीके से बदलाव नहीं कर पाएगा. नीति को सिर्फ़ फ़्रेमवर्क वाले ओटीए में बदला जा सकता है. हालांकि, AOSP सिस्टम इमेज का इस्तेमाल करने पर, यह नीति मौजूद नहीं होगी. इसमें नया सिस्टम कॉम्पोनेंट भी नहीं होगा.

वेंडर-इमेज एक्सटेंशन, जो नए सिस्टम कॉम्पोनेंट दिखाते हैं

उदाहरण: AOSP एनालॉग के बिना, क्लाइंट प्रोसेस के इस्तेमाल के लिए नया, नॉन-AOSP HAL जोड़ना. इसलिए, इसके लिए अपना डोमेन ज़रूरी है.

एओएसपी-एक्सटेंशन के उदाहरण की तरह, सिस्टम और वेंडर के बीच होने वाले इंटरैक्शन से जुड़ी नीति को 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 रिलीज़ में जोड़ा जाता है. साथ ही, उसे नए, बिना एओएसपी एचएएल का ऐक्सेस चाहिए होता है.

यह नए (नॉन-एओएसपी) सिस्टम और वेंडर कॉम्पोनेंट के इंटरैक्शन जैसा ही है. हालांकि, नए सिस्टम टाइप को सिर्फ़ फ़्रेमवर्क वाले ओटीए में पेश किया गया है. हालांकि, system/sepolicy/public में नीति में नया टाइप जोड़ा जा सकता है, लेकिन वेंडर की मौजूदा नीति में नए टाइप की जानकारी नहीं है. इसकी वजह यह है कि यह सिर्फ़ Android 8.0 सिस्टम की सार्वजनिक नीति को ट्रैक कर रही है. AOSP, एट्रिब्यूट (उदाहरण के लिए, hal_foo एट्रिब्यूट) के ज़रिए, वेंडर से मिले संसाधनों को दिखाकर इस समस्या को हल करता है. हालांकि, system/sepolicy/public में एट्रिब्यूट पार्टनर एक्सटेंशन काम नहीं करते. इसलिए, यह तरीका वेंडर नीति के लिए उपलब्ध नहीं है. ऐक्सेस, पहले से मौजूद सार्वजनिक टाइप से दिया जाना चाहिए.

उदाहरण: किसी सिस्टम प्रोसेस (AOSP या गैर-AOSP) में किए जाने वाले बदलाव के लिए, नए, गैर-AOSP वाले वेंडर कॉम्पोनेंट के साथ इंटरैक्ट करने के तरीके में बदलाव होना ज़रूरी है.

सिस्टम इमेज से जुड़ी नीति, किसी खास वेंडर कस्टमाइज़ेशन की जानकारी के बिना लिखी होनी चाहिए. इस तरह, एओएसपी में खास इंटरफ़ेस से जुड़ी नीति को सिस्टम/सेनीति/सार्वजनिक में एट्रिब्यूट के ज़रिए दिखाया जाता है. इससे वेंडर नीति को, आने वाले समय में सिस्टम की उस नीति के लिए ऑप्ट-इन करने में मदद मिलती है जो इन एट्रिब्यूट का इस्तेमाल करती है. हालांकि, system/sepolicy/public में एट्रिब्यूट एक्सटेंशन काम नहीं करते. इसलिए, सिस्टम कॉम्पोनेंट के नए वेंडर कॉम्पोनेंट के साथ इंटरैक्ट करने का तरीका बताने वाली सभी नीतियां device/manufacturer/device-name/sepolicy में होनी चाहिए. साथ ही, वे नीतियां AOSP system/sepolicy/public में पहले से मौजूद एट्रिब्यूट से मैनेज नहीं की जानी चाहिए. इसका मतलब है कि सिर्फ़ फ़्रेमवर्क वाले ओटीए के हिस्से के तौर पर, सिस्टम टाइप वेंडर टाइप के लिए अनुमति वाले ऐक्सेस को बदल नहीं सकते.