ปรับแต่ง SELinux

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

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

เมื่อเริ่มปรับแต่ง SELinux โปรดคำนึงถึงสิ่งต่อไปนี้

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

และอย่าลืมว่าอย่าทำสิ่งต่อไปนี้

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

ดูข้อกำหนดเฉพาะได้ในส่วนฟีเจอร์ความปลอดภัยของเคอร์เนลของเอกสารคำจำกัดความความเข้ากันได้ของ Android

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

  1. ใช้เคอร์เนล Android เวอร์ชันล่าสุด
  2. ใช้หลักการให้สิทธิ์ขั้นต่ำที่สุด
  3. พูดถึงเฉพาะสิ่งที่คุณเพิ่มลงใน Android เท่านั้น นโยบายเริ่มต้นจะทำงานร่วมกับโค้ดเบสของ Android Open Source Project โดยอัตโนมัติ
  4. จัดแบ่งคอมโพเนนต์ซอฟต์แวร์ออกเป็นโมดูลที่ทํางานอย่างใดอย่างหนึ่ง
  5. สร้างนโยบาย SELinux ที่จะแยกงานเหล่านั้นออกจากฟังก์ชันที่ไม่เกี่ยวข้อง
  6. ใส่นโยบายเหล่านั้นในไฟล์ *.te (ส่วนขยายสำหรับไฟล์ต้นทางนโยบาย SELinux) ภายในไดเรกทอรี /device/manufacturer/device-name/sepolicy และใช้ตัวแปร 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 };

คำสั่งเดียวกันนี้สามารถเขียนด้วยมาโคร *_file_perms SELinux (อักษรย่อ) ดังนี้

# 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 จะรับค่ามาจากนโยบายความปลอดภัยพื้นฐาน (domain) จากตัวอย่างคำสั่งก่อนหน้า DHCP สามารถอ่านและเขียนลงใน /dev/null

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

ในบรรทัด init_daemon_domain(dhcp) นโยบายระบุว่า DHCP สร้างขึ้นจาก init และได้รับอนุญาตให้สื่อสารกับ 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 ซ็อกเก็ต Datagram และซ็อกเก็ตสตรีม UNIX DHCP จะอ่านและเขียนจากซ็อกเก็ต Datagram และซ็อกเก็ตสตรีม 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
filesystem 
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

กฎ neverallow ของ SELinux ห้ามไม่ให้มีพฤติกรรมที่ไม่ควรเกิดขึ้น เมื่อทำการทดสอบความเข้ากันได้ ระบบจะบังคับใช้กฎ SELinux neverallow ในอุปกรณ์ต่างๆ

หลักเกณฑ์ต่อไปนี้มีไว้เพื่อช่วยผู้ผลิตหลีกเลี่ยงข้อผิดพลาดที่เกี่ยวข้องกับกฎ neverallow ในระหว่างการปรับแต่ง หมายเลขกฎที่ใช้ที่นี่สอดคล้องกับ Android 5.1 และอาจมีการเปลี่ยนแปลงตามรุ่น

กฎ 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
ดูหน้า man ของ ptrace sys_ptrace ความสามารถนี้จะให้สิทธิ์ในการptraceกระบวนการใดก็ได้ ซึ่งช่วยให้ควบคุมกระบวนการอื่นๆ ได้อย่างมาก และควรเป็นของคอมโพเนนต์ของระบบที่กําหนดเท่านั้นตามที่ระบุไว้ในกฎ ความจำเป็นในการใช้ความสามารถนี้มักจะบ่งบอกถึงการมีบางอย่างที่ไม่ได้ออกแบบมาสำหรับบิลด์ที่แสดงต่อผู้ใช้หรือฟังก์ชันการทำงานที่ไม่จำเป็น นำคอมโพเนนต์ที่ไม่จำเป็นออก

กฎ 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
กฎนี้มีไว้เพื่อป้องกันไม่ให้ระบบเรียกใช้โค้ดที่กําหนดเอง กล่าวโดยละเอียดคือ ไฟล์จะยืนยันว่ามีเพียงโค้ดใน /system เท่านั้นที่เรียกใช้ได้ ซึ่งช่วยให้มั่นใจได้ว่าระบบมีความปลอดภัยด้วยกลไกต่างๆ เช่น การเปิดเครื่องที่ได้รับการยืนยัน บ่อยครั้งที่วิธีแก้ปัญหาที่ดีที่สุดเมื่อพบปัญหาเกี่ยวกับกฎneverallowข้อนี้คือย้ายโค้ดที่ไม่ถูกต้องไปยังพาร์ติชัน/system

ปรับแต่ง SEPolicy ใน Android 8.0 ขึ้นไป

ส่วนนี้ให้หลักเกณฑ์สำหรับนโยบาย SELinux ของผู้ให้บริการใน Android 8.0 ขึ้นไป รวมถึงรายละเอียดเกี่ยวกับ SEPolicy และส่วนขยาย SEPolicy ของโครงการโอเพนซอร์ส Android (AOSP) ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีทำให้นโยบาย 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 จึงถูกจํากัดมากกว่า โปรดทราบว่านี่คือ API นโยบายที่ส่งออกของแพลตฟอร์ม: ทุกอย่างที่เกี่ยวข้องกับอินเทอร์เฟซระหว่าง /system กับ /vendor จะอยู่ที่นี่
  • system/sepolicy/private มีนโยบายที่จำเป็นต่อการทำงานของอิมเมจระบบ แต่นโยบายรูปภาพของผู้ขายไม่ควรทราบ
  • system/sepolicy/vendor มีนโยบายสำหรับคอมโพเนนต์ที่อยู่ใน /vendor แต่อยู่ในโครงสร้างแพลตฟอร์มหลัก (ไม่ใช่ไดเรกทอรีเฉพาะอุปกรณ์) นี่เป็นรายการต่างๆ ของความแตกต่างระหว่างอุปกรณ์กับคอมโพเนนต์ส่วนกลางของระบบบิลด์ ซึ่งในทางแนวคิดแล้ว รายการเหล่านี้เป็นส่วนหนึ่งของนโยบายเฉพาะอุปกรณ์ที่อธิบายไว้ด้านล่าง
  • device/manufacturer/device-name/sepolicy รวมถึงนโยบายเฉพาะอุปกรณ์ รวมถึงการปรับแต่งอุปกรณ์ตามนโยบาย ซึ่งใน Android 8.0 ขึ้นไปจะสอดคล้องกับนโยบายสำหรับคอมโพเนนต์ในรูปภาพผู้ให้บริการ

ใน Android 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. ระบุนโยบายที่จำเป็นต่อการทำงานของรูปภาพผลิตภัณฑ์ แต่นโยบายรูปภาพของผู้ขายไม่ควรทราบ ติดตั้งลงในพาร์ติชันผลิตภัณฑ์
หมายเหตุ: เมื่อใช้ GSI ระบบจะไม่มาสก์พาร์ติชัน system_ext และพาร์ติชันผลิตภัณฑ์ของ OEM กฎใน sepolicy ของผู้ให้บริการที่ใช้ system_ext และนโยบายสาธารณะของผลิตภัณฑ์ OEM จะกลายเป็น NOP เนื่องจากไม่มีคำจำกัดความประเภทสำหรับ OEM โดยเฉพาะ
หมายเหตุ: โปรดระมัดระวังเป็นพิเศษเมื่อใช้ system_ext และนโยบายสาธารณะของผลิตภัณฑ์ นโยบายสาธารณะจะทำหน้าที่เป็น API ที่ส่งออกระหว่าง system_ext/product กับผู้ให้บริการ พาร์ทเนอร์ควรจัดการปัญหาความเข้ากันได้ด้วยตนเอง

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

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

ชิ้นงานที่มีเฉพาะรูปภาพของผู้ขาย

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

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

การรองรับ Vendor-Image เพื่อทำงานร่วมกับ AOSP

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

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

ส่วนขยายรูปภาพผู้ให้บริการที่แสดงคอมโพเนนต์ใหม่ของระบบ

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

เช่นเดียวกับตัวอย่างส่วนขยาย 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 ขึ้นไปไม่รองรับสถานการณ์และตัวอย่างนโยบายต่อไปนี้

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

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

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

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

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