Google มุ่งมั่นที่จะพัฒนาความเท่าเทียมทางเชื้อชาติสำหรับชุมชนคนผิวดำ มาดูกันว่า
หน้านี้ได้รับการแปลโดย Cloud Translation API
Switch to English

การปรับแต่ง SELinux

หลังจากที่คุณรวมระดับพื้นฐานของฟังก์ชันการทำงานของ SELinux และวิเคราะห์ผลลัพธ์อย่างละเอียดแล้วคุณอาจเพิ่มการตั้งค่านโยบายของคุณเองเพื่อให้ครอบคลุมการปรับแต่งของคุณในระบบปฏิบัติการ Android นโยบายเหล่านี้จะต้องเป็นไปตามข้อกำหนดของ โปรแกรมความเข้ากันได้ของ Android และต้องไม่ลบการตั้งค่า SELinux เริ่มต้น

ผู้ผลิตไม่ควรลบนโยบาย SELinux ที่มีอยู่ มิฉะนั้นพวกเขาเสี่ยงที่จะทำลายการใช้งาน Android SELinux และแอปพลิเคชันที่ควบคุม ซึ่งรวมถึงแอปพลิเคชันของบุคคลที่สามที่อาจต้องได้รับการปรับปรุงให้สอดคล้องกับการปฏิบัติงาน แอปพลิเคชันต้องไม่มีการแก้ไขใด ๆ เพื่อให้สามารถใช้งานได้บนอุปกรณ์ที่เปิดใช้งาน SELinux ต่อไป

เมื่อเริ่มทำการปรับแต่ง SELinux อย่าลืม:

  • เขียนนโยบาย SELinux สำหรับ daemons ใหม่ทั้งหมด
  • ใช้โดเมนที่กำหนดไว้ล่วงหน้าตามความเหมาะสม
  • กำหนดโดเมนให้กับกระบวนการใด ๆ ที่กลับกลายเป็นบริการ init
  • ทำความคุ้นเคยกับมาโครก่อนเขียนนโยบาย
  • ส่งการเปลี่ยนแปลงนโยบายหลักไปที่ AOSP

และอย่าลืม:

  • สร้างนโยบายที่เข้ากันไม่ได้
  • อนุญาตการปรับแต่งนโยบายผู้ใช้ปลายทาง
  • อนุญาตการปรับแต่งนโยบาย MDM
  • ทำให้ผู้ใช้กลัวกับการละเมิดนโยบาย
  • เพิ่มแบ็คดอร์

ดูส่วน คุณลักษณะความปลอดภัยของเคอร์เนล ของ เอกสารข้อกำหนดความเข้ากันได้ ของ Android สำหรับข้อกำหนดเฉพาะ

SELinux ใช้วิธีการที่อนุญาตพิเศษหมายความว่าการเข้าถึงทั้งหมดจะต้องได้รับอนุญาตอย่างชัดเจนในนโยบายเพื่อที่จะได้รับอนุญาต เนื่องจากนโยบาย SELinux ที่เป็นค่าเริ่มต้นของ Android รองรับโครงการ Open Source ของ Android อยู่แล้วคุณไม่จำเป็นต้องแก้ไขการตั้งค่า SELinux แต่อย่างใด หากคุณกำหนดการตั้งค่า SELinux เองโปรดระมัดระวังเป็นอย่างยิ่งที่จะไม่ทำลายแอปพลิเคชันที่มีอยู่ ที่จะเริ่มต้น:

  1. ใช้ เคอร์เนล Android ล่าสุด
  2. นำ หลักการสิทธิพิเศษมาใช้อย่างน้อยที่สุด
  3. ระบุที่อยู่เพิ่มเติมที่คุณเพิ่มลงใน Android นโยบายเริ่มต้นทำงานร่วมกับ codebase Project Android Open Source โดยอัตโนมัติ
  4. แบ่งส่วนประกอบซอฟต์แวร์ออกเป็นโมดูลที่ทำหน้าที่เอกพจน์
  5. สร้างนโยบาย SELinux ที่แยกงานเหล่านั้นออกจากฟังก์ชั่นที่ไม่เกี่ยวข้อง
  6. วางนโยบายเหล่านั้นในไฟล์ *.te (ส่วนขยายสำหรับไฟล์นโยบาย SELinux นโยบาย) ภายในไดเร็กทอรี /device/ manufacturer / device-name /sepolicy และใช้ตัวแปร BOARD_SEPOLICY เพื่อรวมไว้ใน BOARD_SEPOLICY ของคุณ
  7. สร้างโดเมนใหม่ที่อนุญาตในขั้นต้น สิ่งนี้ทำได้โดยใช้การประกาศที่อนุญาตในไฟล์. .te ของโดเมน
  8. วิเคราะห์ผลลัพธ์และปรับแต่งคำจำกัดความโดเมนของคุณ
  9. ลบการประกาศที่อนุญาตเมื่อไม่มีการปฏิเสธเพิ่มเติมปรากฏใน userdebug builds

หลังจากที่คุณรวมการเปลี่ยนแปลงนโยบายของ SELinux แล้วให้เพิ่มขั้นตอนในเวิร์กโฟลว์การพัฒนาของคุณเพื่อให้แน่ใจว่า SELinux สามารถทำงานร่วมกันได้ในอนาคต ในกระบวนการพัฒนาซอฟต์แวร์ที่สมบูรณ์แบบนโยบาย SELinux จะเปลี่ยนเฉพาะเมื่อโมเดลซอฟต์แวร์เปลี่ยนแปลงและไม่ใช่การนำไปใช้จริง

เมื่อคุณเริ่มปรับแต่ง SELinux ให้ตรวจสอบสิ่งที่คุณเพิ่มลงใน Android ก่อน หากคุณได้เพิ่มส่วนประกอบที่ดำเนินการฟังก์ชั่นใหม่ตรวจสอบให้แน่ใจว่าส่วนประกอบนั้นเป็นไปตามนโยบายความปลอดภัยของ Android รวมถึงนโยบายใด ๆ ที่เกี่ยวข้องที่สร้างขึ้นโดย OEM ก่อนที่จะเปิดโหมดบังคับใช้

เพื่อป้องกันปัญหาที่ไม่จำเป็นมันจะดีกว่า overbroad และ over-compatible มากกว่าการ จำกัด และเข้ากันไม่ได้ซึ่งส่งผลให้ฟังก์ชั่นอุปกรณ์ที่ใช้งานไม่ได้ ในทางกลับกันหากการเปลี่ยนแปลงของคุณจะเป็นประโยชน์ต่อผู้อื่นคุณควรส่งการแก้ไขนโยบาย 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;

ตัวอย่างนโยบาย

นี่คือตัวอย่างนโยบายที่สมบูรณ์แบบสำหรับ DHCP ซึ่งเราตรวจสอบด้านล่าง:

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 };

ลองแยกตัวอย่าง:

ในบรรทัดแรกการประกาศชนิด DHCP daemon สืบทอดจากนโยบายความปลอดภัยพื้นฐาน ( domain ) จากตัวอย่างคำสั่งก่อนหน้า DHCP สามารถอ่านและเขียนถึง /dev/null

ในบรรทัดที่สอง DHCP ถูกระบุว่าเป็นโดเมนที่อนุญาต

ใน init_daemon_domain(dhcp) สถานะนโยบาย DHCP จะเกิดจาก init และได้รับอนุญาตให้สื่อสารกับมัน

ใน net_domain(dhcp) นโยบายอนุญาตให้ DHCP ใช้ฟังก์ชั่นเครือข่ายทั่วไปจากโดเมน net เช่นการอ่านและเขียนแพ็กเก็ต TCP สื่อสารผ่านซ็อกเก็ตและดำเนินการร้องขอ DNS

ในบรรทัด allow dhcp proc_net:file write; สถานะนโยบาย DHCP สามารถเขียนไปยังไฟล์ที่ระบุใน /proc บรรทัดนี้แสดงให้เห็นถึงการติดฉลากไฟล์อย่างละเอียดของ SELinux โดยใช้ proc_net เพื่อ จำกัด การเข้าถึงเพื่อเขียนเฉพาะไฟล์ภายใต้ /proc/sys/net

บล็อกสุดท้ายของตัวอย่างที่เริ่มต้นด้วย allow dhcp netd:fd use; แสดงให้เห็นว่าแอปพลิเคชันอาจได้รับอนุญาตให้โต้ตอบซึ่งกันและกัน นโยบายกล่าวว่า DHCP และ netd อาจสื่อสารกันผ่านตัวอธิบายไฟล์ไฟล์ 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 กฎห้ามพฤติกรรมที่ไม่ควรเกิดขึ้น ด้วยการทดสอบ ความเข้ากันได้ กฎ 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 พาร์ติชัน /system

การปรับแต่ง SEPolicy ใน Android 8.0+

ส่วนนี้มีแนวทางสำหรับนโยบายผู้จำหน่าย SELinux ใน Android 8.0 และสูงกว่ารวมถึงรายละเอียดเกี่ยวกับ 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:

  • ระบบ / sepolicy / สาธารณะ รวมนโยบายที่ส่งออกเพื่อใช้ในนโยบายเฉพาะผู้ขาย ทุกอย่างเข้าสู่ โครงสร้างพื้นฐานความเข้ากันได้ ของ Android 8.0 นโยบายสาธารณะนั้นมีวัตถุประสงค์เพื่อคงอยู่ตลอดการเผยแพร่เพื่อให้คุณสามารถรวมอะไร /public ในนโยบายที่กำหนดเองของคุณ ด้วยเหตุนี้ประเภทของนโยบายที่สามารถวางใน /public จึงถูก จำกัด มากขึ้น พิจารณาสิ่งนี้ API นโยบายที่ส่งออกของแพลตฟอร์ม: สิ่งใดก็ตามที่เกี่ยวข้องกับส่วนต่อประสานระหว่าง /system /vendor และ /vendor อยู่ที่นี่
  • ระบบ / sepolicy / ส่วนตัว รวมนโยบายที่จำเป็นสำหรับการทำงานของอิมเมจระบบ แต่นโยบายอิมเมจของผู้ขายไม่ควรมีความรู้
  • ระบบ / sepolicy / ผู้ขาย รวมนโยบายสำหรับส่วนประกอบที่เข้า /vendor แต่มีอยู่ในแผนภูมิแพลตฟอร์มหลัก (ไม่ใช่ไดเรกทอรีเฉพาะอุปกรณ์) นี่เป็นสิ่งประดิษฐ์ของการสร้างความแตกต่างของระบบระหว่างอุปกรณ์และส่วนประกอบทั่วโลก แนวคิดนี้เป็นส่วนหนึ่งของนโยบายเฉพาะอุปกรณ์ที่อธิบายไว้ด้านล่าง
  • อุปกรณ์ / manufacturer / device-name / sepolicy รวมถึงนโยบายเฉพาะอุปกรณ์ ยังรวมถึงการปรับแต่งอุปกรณ์ตามนโยบายซึ่งใน Android 8.0 และสูงกว่านั้นสอดคล้องกับนโยบายสำหรับส่วนประกอบในภาพผู้ขาย

สถานการณ์นโยบายที่รองรับ

สำหรับอุปกรณ์ที่ใช้ Android 8.0 ขึ้นไปอิมเมจของผู้ขายจะต้องทำงานร่วมกับอิมเมจระบบ OEM และอิมเมจระบบ AOSP ที่อ้างอิงโดย Google (และส่งต่อ CTS ในอิมเมจอ้างอิงนี้) ข้อกำหนดเหล่านี้ทำให้แน่ใจได้ว่ามีการแยกอย่างชัดเจนระหว่างกรอบงานและรหัสผู้ขาย อุปกรณ์ดังกล่าวรองรับสถานการณ์ต่อไปนี้

ส่วนขยายภาพผู้จำหน่ายเท่านั้น

ตัวอย่าง : การเพิ่มบริการใหม่ไปยัง vndservicemanager จากอิมเมจผู้ขายที่สนับสนุนกระบวนการจากอิมเมจผู้จัดจำหน่าย

เช่นเดียวกับอุปกรณ์ที่เปิดตัวด้วย Android เวอร์ชันก่อนหน้าเพิ่มการปรับแต่งเฉพาะ device/ manufacturer / device-name /sepolicy ใน device/ manufacturer / device-name /sepolicy นโยบายใหม่ที่ควบคุมว่าองค์ประกอบของผู้ขายโต้ตอบกับ (เฉพาะ) ส่วนประกอบของผู้ขายอื่น ๆ ควรเกี่ยวข้องกับประเภทที่มีเฉพาะใน device/ manufacturer / device-name /sepolicy นโยบายที่เขียนในที่นี้อนุญาตให้ใช้รหัสกับผู้จำหน่ายในการทำงานจะไม่ได้รับการอัปเดตเป็นส่วนหนึ่งของ OTA เฉพาะเฟรมเวิร์กและจะแสดงในนโยบายรวมบนอุปกรณ์ที่มีอิมเมจระบบ AOSP อ้างอิง

การสนับสนุนภาพผู้จำหน่ายเพื่อทำงานกับ AOSP

ตัวอย่าง : การเพิ่มกระบวนการใหม่ (ลงทะเบียนกับ hwservicemanager จากอิมเมจผู้ขาย) ที่ใช้ HAL ที่กำหนดโดย AOSP

เช่นเดียวกับอุปกรณ์ที่เปิดตัวด้วย Android เวอร์ชันก่อนหน้านี้ให้ทำการปรับแต่งเฉพาะ device/ manufacturer / device-name /sepolicy ใน device/ manufacturer / device-name /sepolicy นโยบายที่ส่งออกเป็นส่วนหนึ่งของ system/sepolicy/public/ พร้อมใช้งานและถูกจัดส่งเป็นส่วนหนึ่งของนโยบายผู้ขาย ประเภทและคุณสมบัติจากนโยบายสาธารณะอาจใช้ในกฎใหม่ที่กำหนดการโต้ตอบกับบิตเฉพาะผู้จำหน่ายใหม่ภายใต้ข้อ จำกัด neverallow ระบุ เช่นเดียวกับกรณีของผู้จัดจำหน่ายเท่านั้นนโยบายใหม่ที่นี่จะไม่ได้รับการอัปเดตเป็นส่วนหนึ่งของ OTA เฉพาะเฟรมเวิร์กและจะแสดงในนโยบายรวมบนอุปกรณ์ที่มีอิมเมจระบบ AOSP อ้างอิง

ส่วนขยายเฉพาะภาพระบบ

ตัวอย่าง : การเพิ่มเซอร์วิสใหม่ (ลงทะเบียนกับ servicemanager) ที่เข้าถึงได้โดยกระบวนการอื่นจากอิมเมจระบบเท่านั้น

เพิ่มนโยบายนี้เพื่อ system/sepolicy/private คุณสามารถเพิ่มกระบวนการพิเศษหรือวัตถุเพื่อเปิดใช้งานการทำงานในอิมเมจระบบพันธมิตรโดยที่บิตใหม่เหล่านั้นไม่จำเป็นต้องโต้ตอบกับส่วนประกอบใหม่ในอิมเมจของผู้ขาย (โดยเฉพาะกระบวนการหรือวัตถุดังกล่าวจะต้องทำงานอย่างสมบูรณ์โดยไม่มีนโยบายจากอิมเมจ . นโยบายที่ส่งออกโดย system/sepolicy/public มีให้บริการที่นี่เช่นเดียวกับที่มีไว้สำหรับส่วนขยายภาพเท่านั้น นโยบายนี้เป็นส่วนหนึ่งของอิมเมจระบบและสามารถอัปเดตใน OTA เฉพาะเฟรมเวิร์ก แต่จะไม่ปรากฏเมื่อใช้อิมเมจระบบ AOSP อ้างอิง

ส่วนขยายภาพผู้จำหน่ายที่ให้บริการส่วนประกอบ AOSP แบบขยาย

ตัวอย่าง: HAL ที่ไม่ใช่ AOSP ใหม่สำหรับใช้โดยไคลเอ็นต์ที่ขยายเพิ่มซึ่งมีอยู่ในอิมเมจระบบ AOSP (เช่น system_server แบบขยาย)

นโยบายสำหรับการโต้ตอบระหว่างระบบและผู้ขายจะต้องรวมอยู่ในไดเรกทอรี device/ manufacturer / device-name /sepolicy จัดส่งบนพาร์ติชันผู้จัดจำหน่าย นี่คล้ายกับสถานการณ์ข้างต้นของการเพิ่มการสนับสนุนภาพผู้จัดจำหน่ายเพื่อทำงานกับอิมเมจ AOSP อ้างอิงยกเว้นองค์ประกอบ AOSP ที่ถูกปรับเปลี่ยนอาจจำเป็นต้องมีนโยบายเพิ่มเติมในการทำงานอย่างถูกต้องกับพาร์ติชันระบบที่เหลือ (ซึ่งใช้ได้ตราบใดที่ยังคงอยู่ มีฉลากประเภท AOSP สาธารณะ)

นโยบายสำหรับการโต้ตอบของคอมโพเนนต์ AOSP สาธารณะที่มีส่วนขยายเฉพาะภาพระบบเท่านั้นควรอยู่ใน system/sepolicy/private

ส่วนขยายภาพระบบที่เข้าถึงอินเตอร์เฟส AOSP เท่านั้น

ตัวอย่าง: กระบวนการระบบใหม่ที่ไม่ใช่ AOSP ต้องเข้าถึง HAL ที่ AOSP อาศัยอยู่

สิ่งนี้คล้ายกับ ตัวอย่างส่วนขยายเฉพาะภาพระบบ ยกเว้นส่วนประกอบระบบใหม่อาจมีการโต้ตอบระหว่าง system/vendor ส่วนต่อประสาน system/vendor นโยบายสำหรับส่วนประกอบของระบบใหม่จะต้องอยู่ใน system/sepolicy/private ซึ่งเป็นที่ยอมรับหากผ่าน AOSP ที่สร้างไว้แล้วในส่วนของ system/sepolicy/public (เช่นประเภทและคุณสมบัติที่จำเป็นสำหรับการใช้งาน) ในขณะที่นโยบายอาจรวมอยู่ในนโยบายเฉพาะอุปกรณ์ แต่จะไม่สามารถใช้ system/sepolicy/private ประเภทอื่น ๆ หรือการเปลี่ยนแปลง (ในทางใด ๆ ที่มีผลต่อนโยบาย) อันเป็นผลมาจากการอัพเดตเฟรมเวิร์กเท่านั้น นโยบายอาจมีการเปลี่ยนแปลงใน OTA เฉพาะเฟรมเวิร์ก แต่จะไม่ปรากฏเมื่อใช้อิมเมจระบบ AOSP (ซึ่งจะไม่มีส่วนประกอบของระบบใหม่)

ส่วนขยายภาพผู้จำหน่ายที่ให้บริการส่วนประกอบของระบบใหม่

ตัวอย่าง: การ เพิ่ม HAL ที่ไม่ใช่ AOSP ใหม่สำหรับใช้โดยกระบวนการไคลเอ็นต์โดยไม่มีอะนาล็อก AOSP (และต้องใช้โดเมนของตัวเอง)

คล้ายกับตัวอย่าง AOSP-extensions นโยบายสำหรับการโต้ตอบระหว่างระบบและผู้จัดจำหน่ายจะต้องอยู่ในไดเรกทอรี 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 และสูงกว่าไม่รองรับสถานการณ์และตัวอย่างนโยบายต่อไปนี้

ส่วนขยายเพิ่มเติมสำหรับอิมเมจระบบที่ต้องได้รับอนุญาตสำหรับส่วนประกอบภาพผู้ขายใหม่หลังจาก OTA เฉพาะเฟรมเวิร์ก

ตัวอย่าง: กระบวนการของระบบที่ไม่ใช่ AOSP ใหม่ซึ่งต้องการโดเมนของตัวเองถูกเพิ่มเข้าใน Android รุ่นถัดไปและต้องการเข้าถึง HAL ที่ไม่ใช่ AOSP ใหม่

คล้ายกับระบบ ใหม่ (ที่ไม่ใช่ AOSP) และ การโต้ตอบ ส่วนประกอบของผู้ขาย ยกเว้นชนิดระบบใหม่ถูกนำมาใช้ใน OTA เฉพาะเฟรมเวิร์ก แม้ว่าสามารถเพิ่มประเภทใหม่ให้กับนโยบายใน system/sepolicy/public แต่นโยบายของผู้ขายที่มีอยู่ไม่มีความรู้เกี่ยวกับประเภทใหม่เนื่องจากกำลังติดตามเฉพาะนโยบายสาธารณะของระบบ Android 8.0 AOSP จัดการสิ่งนี้โดยการเปิดเผยทรัพยากรที่ผู้ให้บริการจัดหาผ่านทางแอตทริบิวต์ (เช่นแอตทริบิวต์ hal_foo ) แต่เนื่องจากส่วนขยายพันธมิตรของแอตทริบิวต์ไม่ได้รับการสนับสนุนใน system/sepolicy/public วิธีนี้ไม่สามารถใช้ได้กับนโยบายของผู้ขาย การเข้าถึงต้องจัดให้โดยประเภทสาธารณะที่มีอยู่ก่อนหน้านี้

ตัวอย่าง: การเปลี่ยนแปลงกระบวนการของระบบ (AOSP หรือไม่ใช่ AOSP) ต้องเปลี่ยนวิธีการโต้ตอบกับองค์ประกอบผู้ขายที่ไม่ใช่ AOSP ใหม่

นโยบายเกี่ยวกับอิมเมจระบบต้องถูกเขียนโดยไม่มีความรู้เกี่ยวกับการปรับแต่งผู้จำหน่ายเฉพาะ นโยบายที่เกี่ยวข้องกับอินเทอร์เฟซเฉพาะใน AOSP จึงถูกเปิดเผยผ่านแอตทริบิวต์ในระบบ / sepolicy / พับลิกเพื่อให้นโยบายผู้ขายสามารถเลือกใช้นโยบายระบบในอนาคตซึ่งใช้แอตทริบิวต์เหล่านี้ได้ อย่างไรก็ตามส่วนขยายแอตทริบิวต์ใน system/sepolicy/public จะไม่ได้รับการสนับสนุนเพื่อให้ทุก dictating นโยบายว่าส่วนประกอบของระบบโต้ตอบกับองค์ประกอบของผู้ขายใหม่ (และที่ไม่ได้รับการจัดการโดยคุณลักษณะอยู่แล้วใน AOSP system/sepolicy/public ) จะต้องอยู่ใน device/ manufacturer / device-name /sepolicy ซึ่งหมายความว่าประเภทระบบไม่สามารถเปลี่ยนการเข้าถึงที่อนุญาตให้กับประเภทผู้จัดจำหน่ายซึ่งเป็นส่วนหนึ่งของ OTA เฉพาะเฟรมเวิร์ก