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

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

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

เมื่อเริ่มต้นปรับแต่ง SELinux อย่าลืม:

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

และจำไว้ว่าอย่า:

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

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

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

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

หลังจากที่คุณได้รวมการเปลี่ยนแปลงนโยบาย SELinux แล้ว ให้เพิ่มขั้นตอนในเวิร์กโฟลว์การพัฒนาของคุณเพื่อให้แน่ใจว่า 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;

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

นี่คือตัวอย่างนโยบายที่สมบูรณ์สำหรับ 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 อาจสื่อสารกันผ่าน file descriptor, ไฟล์ 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 ห้ามพฤติกรรมที่ไม่ควรเกิดขึ้น ด้วยการทดสอบ ความเข้ากันได้ กฎ 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

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

ส่วนนี้ระบุหลักเกณฑ์สำหรับนโยบาย SELinux ของผู้จำหน่ายใน Android 8.0 ขึ้นไป รวมถึงรายละเอียดเกี่ยวกับส่วนขยาย SEPolicy และ SEPolicy ของ Android Open Source Project (AOSP) สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีที่นโยบาย SELinux สามารถทำงานร่วมกันได้ระหว่างพาร์ติชันและเวอร์ชัน Android โปรดดูที่ ความเข้ากันได้

การวางนโยบาย

ใน Android 7.0 และรุ่นก่อนหน้า ผู้ผลิตอุปกรณ์สามารถเพิ่มนโยบายใน BOARD_SEPOLICY_DIRS ได้ ซึ่งรวมถึงนโยบายที่มุ่งเพิ่มนโยบาย AOSP ในอุปกรณ์ประเภทต่างๆ ใน Android 8.0 ขึ้นไป การเพิ่มนโยบายใน BOARD_SEPOLICY_DIRS จะวางนโยบายไว้ในอิมเมจผู้ขายเท่านั้น

ใน Android 8.0 ขึ้นไป นโยบายมีอยู่ในตำแหน่งต่อไปนี้ใน AOSP:

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

ใน Android 11 ขึ้นไป พาร์ติชั่น system_ext และ product ยังสามารถรวมนโยบายเฉพาะของพาร์ติชั่นได้อีกด้วย 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 และพาร์ติชั่นผลิตภัณฑ์ กฎในการแบ่งแยกผู้จัดจำหน่ายที่ใช้ 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 อ้างอิง

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