SELinux को अनुकूलित करना

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

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

SELinux को अनुकूलित करते समय, याद रखें:

• सभी नए डेमॉन के लिए SELinux नीति लिखें
• जब भी उपयुक्त हो पूर्वनिर्धारित डोमेन का उपयोग करें
• init सेवा के रूप में उत्पन्न किसी भी प्रक्रिया के लिए एक डोमेन निर्दिष्ट करें
• नीति लिखने से पहले मैक्रोज़ से परिचित हो जाएं
• मुख्य नीति में परिवर्तन AOSP को सबमिट करें

और याद रखें कि ऐसा न करें:

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

विशिष्ट आवश्यकताओं के लिए एंड्रॉइड संगतता परिभाषा दस्तावेज़ का कर्नेल सुरक्षा सुविधाएँ अनुभाग देखें।

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

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

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

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

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

उदाहरण नीति वक्तव्य

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 से पढ़ और लिख सकता है।

दूसरी पंक्ति में, डीएचसीपी को एक अनुमेय डोमेन के रूप में पहचाना जाता है।

init_daemon_domain(dhcp) लाइन में, नीति बताती है कि DHCP init से उत्पन्न हुआ है और उसे इसके साथ संचार करने की अनुमति है।

net_domain(dhcp) लाइन में, नीति डीएचसीपी को net डोमेन से सामान्य नेटवर्क कार्यक्षमता का उपयोग करने की अनुमति देती है जैसे कि टीसीपी पैकेट पढ़ना और लिखना, सॉकेट पर संचार करना और डीएनएस अनुरोधों का संचालन करना।

पंक्ति में allow dhcp proc_net:file write; नीति में कहा गया है कि डीएचसीपी /proc में विशिष्ट फाइलों को लिख सकता है। यह पंक्ति SELinux की बारीक फ़ाइल लेबलिंग को प्रदर्शित करती है। यह केवल /proc/sys/net के अंतर्गत फ़ाइलों तक लेखन पहुंच को सीमित करने के लिए proc_net लेबल का उपयोग करता है।

उदाहरण का अंतिम ब्लॉक allow dhcp netd:fd use; दर्शाता है कि कैसे अनुप्रयोगों को एक दूसरे के साथ इंटरैक्ट करने की अनुमति दी जा सकती है। नीति कहती है कि डीएचसीपी और नेट फ़ाइल डिस्क्रिप्टर, फीफो फाइलें, डेटाग्राम सॉकेट और यूनिक्स स्ट्रीम सॉकेट के माध्यम से एक दूसरे के साथ संवाद कर सकते हैं। डीएचसीपी केवल डेटाग्राम सॉकेट और यूनिक्स स्ट्रीम सॉकेट से पढ़ और लिख सकता है और उन्हें बना या खोल नहीं सकता है।

उपलब्ध नियंत्रण

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 नियमों से संबंधित त्रुटियों से बचने में मदद करना है। यहां उपयोग किए गए नियम नंबर एंड्रॉइड 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 को कस्टमाइज़ करना

यह अनुभाग एंड्रॉइड 8.0 और उच्चतर में विक्रेता SELinux नीति के लिए दिशानिर्देश प्रदान करता है, जिसमें एंड्रॉइड ओपन सोर्स प्रोजेक्ट (AOSP) SEPolicy और SEPolicy एक्सटेंशन पर विवरण शामिल है। SELinux नीति को सभी विभाजनों और Android संस्करणों में कैसे संगत रखा जाता है, इसके बारे में अधिक जानकारी के लिए, संगतता देखें।

नीति प्लेसमेंट

एंड्रॉइड 7.0 और इससे पहले के संस्करण में, डिवाइस निर्माता BOARD_SEPOLICY_DIRS में नीति जोड़ सकते हैं, जिसमें विभिन्न डिवाइस प्रकारों में AOSP नीति को बढ़ाने के लिए बनाई गई नीति भी शामिल है। Android 8.0 और उच्चतर में, BOARD_SEPOLICY_DIRS में एक नीति जोड़ने से नीति केवल विक्रेता छवि में आ जाती है।

Android 8.0 और उच्चतर में, नीति AOSP में निम्नलिखित स्थानों पर मौजूद है:

• सिस्टम/सेपॉलिसी/सार्वजनिक । विक्रेता-विशिष्ट नीति में उपयोग के लिए निर्यात की गई नीति शामिल है। सब कुछ एंड्रॉइड 8.0 संगतता बुनियादी ढांचे में चला जाता है। सार्वजनिक नीति का उद्देश्य सभी रिलीज़ों को जारी रखना है ताकि आप अपनी अनुकूलित नीति में कुछ भी /public शामिल कर सकें। इस वजह से, जिस प्रकार की पॉलिसी को /public में रखा जा सकता है वह अधिक प्रतिबंधित है। इस प्लेटफ़ॉर्म की निर्यातित नीति API पर विचार करें: जो कुछ भी /system और /vendor के बीच इंटरफ़ेस से संबंधित है वह यहां से संबंधित है।
• सिस्टम/सेपॉलिसी/निजी । इसमें सिस्टम छवि के कामकाज के लिए आवश्यक नीति शामिल है, लेकिन विक्रेता छवि नीति के बारे में कोई जानकारी नहीं होनी चाहिए।
• सिस्टम/सेपॉलिसी/विक्रेता । उन घटकों के लिए नीति शामिल है जो /vendor में जाते हैं लेकिन कोर प्लेटफ़ॉर्म ट्री में मौजूद हैं (डिवाइस-विशिष्ट निर्देशिका नहीं)। यह उपकरणों और वैश्विक घटकों के बीच बिल्ड सिस्टम के अंतर की एक कलाकृति है; वैचारिक रूप से यह नीचे वर्णित डिवाइस-विशिष्ट नीति का एक हिस्सा है।
• डिवाइस/ manufacturer / device-name /सेपॉलिसी । डिवाइस-विशिष्ट नीति शामिल है। नीति में डिवाइस अनुकूलन भी शामिल है, जो एंड्रॉइड 8.0 और उच्चतर में विक्रेता छवि पर घटकों के लिए नीति से मेल खाता है।

एंड्रॉइड 11 और उच्चतर में, system_ext और उत्पाद विभाजन में विभाजन-विशिष्ट नीतियां भी शामिल हो सकती हैं। 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 . इसमें उत्पाद छवि के कामकाज के लिए आवश्यक नीति शामिल है, लेकिन विक्रेता छवि नीति के बारे में कोई जानकारी नहीं होनी चाहिए। उत्पाद विभाजन पर स्थापित.

समर्थित नीति परिदृश्य

एंड्रॉइड 8.0 और उच्चतर के साथ लॉन्च होने वाले उपकरणों पर, विक्रेता छवि को OEM सिस्टम छवि और Google द्वारा प्रदान की गई संदर्भ AOSP सिस्टम छवि के साथ काम करना चाहिए (और इस संदर्भ छवि पर CTS पास करना चाहिए)। ये आवश्यकताएं फ्रेमवर्क और विक्रेता कोड के बीच स्पष्ट अलगाव सुनिश्चित करती हैं। ऐसे उपकरण निम्नलिखित परिदृश्यों का समर्थन करते हैं।

विक्रेता-छवि-केवल एक्सटेंशन

उदाहरण : विक्रेता छवि से vndservicemanager में एक नई सेवा जोड़ना जो विक्रेता छवि से प्रक्रियाओं का समर्थन करता है।

पिछले एंड्रॉइड संस्करणों के साथ लॉन्च होने वाले उपकरणों की तरह, device/ manufacturer / device-name /sepolicy में डिवाइस-विशिष्ट अनुकूलन जोड़ें। विक्रेता घटक (केवल) अन्य विक्रेता घटकों के साथ कैसे इंटरैक्ट करते हैं, इसे नियंत्रित करने वाली नई नीति में केवल device/ manufacturer / device-name /sepolicy में मौजूद प्रकार शामिल होने चाहिए। यहां लिखी गई नीति विक्रेता पर कोड को काम करने की अनुमति देती है, केवल फ्रेमवर्क ओटीए के हिस्से के रूप में अपडेट नहीं की जाएगी, और संदर्भ एओएसपी सिस्टम छवि के साथ एक डिवाइस पर संयुक्त नीति में मौजूद होगी।

AOSP के साथ काम करने के लिए विक्रेता-छवि समर्थन

उदाहरण : एक नई प्रक्रिया जोड़ना (विक्रेता छवि से hwservicemanager के साथ पंजीकृत) जो AOSP-परिभाषित HAL को लागू करता है।

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

सिस्टम-छवि-केवल एक्सटेंशन

उदाहरण : एक नई सेवा जोड़ना (सर्विसमैनेजर के साथ पंजीकृत) जिसे केवल सिस्टम छवि से अन्य प्रक्रियाओं द्वारा एक्सेस किया जाता है।

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

विक्रेता-छवि एक्सटेंशन जो विस्तारित AOSP घटकों की सेवा करते हैं

उदाहरण: विस्तारित क्लाइंट द्वारा उपयोग के लिए एक नया, गैर-एओएसपी एचएएल जो एओएसपी सिस्टम छवि (जैसे एक विस्तारित सिस्टम_सर्वर) में भी मौजूद है।

सिस्टम और विक्रेता के बीच बातचीत की नीति को विक्रेता विभाजन पर भेजे गए device/ manufacturer / device-name /sepolicy निर्देशिका में शामिल किया जाना चाहिए। यह संदर्भ AOSP छवि के साथ काम करने के लिए विक्रेता-छवि समर्थन को जोड़ने के उपरोक्त परिदृश्य के समान है, संशोधित AOSP घटकों को छोड़कर बाकी सिस्टम विभाजन के साथ ठीक से काम करने के लिए अतिरिक्त नीति की भी आवश्यकता हो सकती है (जो तब तक ठीक है जब तक वे अभी भी हैं) सार्वजनिक AOSP प्रकार के लेबल हैं)।

सिस्टम-इमेज-ओनली एक्सटेंशन के साथ सार्वजनिक एओएसपी घटकों की सहभागिता की नीति system/sepolicy/private में होनी चाहिए।

सिस्टम-इमेज एक्सटेंशन जो केवल AOSP इंटरफेस तक पहुंचते हैं

उदाहरण: एक नई, गैर-एओएसपी सिस्टम प्रक्रिया को एचएएल तक पहुंचना चाहिए जिस पर एओएसपी निर्भर करता है।

यह सिस्टम-इमेज-ओनली एक्सटेंशन उदाहरण के समान है, सिवाय इसके कि नए सिस्टम घटक system/vendor इंटरफ़ेस पर इंटरैक्ट कर सकते हैं। नए सिस्टम घटक के लिए नीति को system/sepolicy/private में जाना चाहिए, जो स्वीकार्य है बशर्ते कि यह system/sepolicy/public में AOSP द्वारा पहले से स्थापित इंटरफ़ेस के माध्यम से हो (यानी कार्यक्षमता के लिए आवश्यक प्रकार और विशेषताएँ मौजूद हों)। हालाँकि नीति को डिवाइस-विशिष्ट नीति में शामिल किया जा सकता है, यह केवल-फ़्रेमवर्क अपडेट के परिणामस्वरूप अन्य system/sepolicy/private प्रकारों का उपयोग करने या परिवर्तन (किसी भी नीति-प्रभावित तरीके से) में असमर्थ होगा। नीति को केवल फ्रेमवर्क ओटीए में बदला जा सकता है, लेकिन एओएसपी सिस्टम छवि का उपयोग करते समय यह मौजूद नहीं होगा (जिसमें नया सिस्टम घटक भी नहीं होगा)।

विक्रेता-छवि एक्सटेंशन जो नए सिस्टम घटकों की सेवा करते हैं

उदाहरण: 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 नीति में वस्तुओं को सीधे लेबल करने के लिए नहीं किया जा सकता है।

असमर्थित नीति परिदृश्य

एंड्रॉइड 8.0 और उच्चतर के साथ लॉन्च होने वाले डिवाइस निम्नलिखित नीति परिदृश्य और उदाहरणों का समर्थन नहीं करते हैं।

सिस्टम-इमेज के लिए अतिरिक्त एक्सटेंशन जिन्हें केवल-फ्रेमवर्क ओटीए के बाद नए विक्रेता-छवि घटकों की अनुमति की आवश्यकता होती है

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

नए (गैर-एओएसपी) सिस्टम और विक्रेता घटकों के इंटरैक्शन के समान, नए सिस्टम प्रकार को छोड़कर केवल फ्रेमवर्क ओटीए में पेश किया गया है। हालाँकि नए प्रकार को system/sepolicy/public में नीति में जोड़ा जा सकता है, मौजूदा विक्रेता नीति को नए प्रकार का कोई ज्ञान नहीं है क्योंकि यह केवल Android 8.0 सिस्टम सार्वजनिक नीति को ट्रैक कर रहा है। एओएसपी एक विशेषता (उदाहरण के लिए hal_foo विशेषता) के माध्यम से विक्रेता द्वारा प्रदत्त संसाधनों को उजागर करके इसे संभालता है, लेकिन चूंकि विशेषता भागीदार एक्सटेंशन system/sepolicy/public में समर्थित नहीं हैं, इसलिए यह विधि विक्रेता नीति के लिए उपलब्ध नहीं है। पहुंच पहले से मौजूद सार्वजनिक प्रकार से प्रदान की जानी चाहिए।

उदाहरण: सिस्टम प्रक्रिया (एओएसपी या गैर-एओएसपी) में बदलाव से यह बदलना होगा कि यह नए, गैर-एओएसपी विक्रेता घटक के साथ कैसे इंटरैक्ट करता है।

सिस्टम छवि पर नीति विशिष्ट विक्रेता अनुकूलन की जानकारी के बिना लिखी जानी चाहिए। एओएसपी में विशिष्ट इंटरफेस से संबंधित नीति को सिस्टम/सेपॉलिसी/सार्वजनिक में विशेषताओं के माध्यम से उजागर किया जाता है ताकि विक्रेता नीति भविष्य की सिस्टम नीति में ऑप्ट-इन कर सके जो इन विशेषताओं का उपयोग करती है। हालाँकि, system/sepolicy/public में विशेषता एक्सटेंशन समर्थित नहीं हैं , इसलिए सभी नीति यह तय करती है कि सिस्टम घटक नए विक्रेता घटकों के साथ कैसे इंटरैक्ट करते हैं (और जिसे एओएसपी system/sepolicy/public में पहले से मौजूद विशेषताओं द्वारा नियंत्रित नहीं किया जाता है) device/ manufacturer / device-name /sepolicy । इसका मतलब यह है कि सिस्टम प्रकार केवल-फ्रेमवर्क ओटीए के हिस्से के रूप में विक्रेता प्रकारों को दी गई पहुंच को नहीं बदल सकते हैं।