การปรับแต่ง 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 Open Source โดยอัตโนมัติ
  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 };

คำสั่งเดียวกันนี้สามารถเขียนด้วยมาโคร 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 กฎห้ามมิให้พฤติกรรมที่ไม่ควรเกิดขึ้น ด้วยการทดสอบ ความเข้ากันได้ ตอนนี้มีการบังคับใช้กฎ 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:

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

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