หลังจากที่คุณได้รวมระดับพื้นฐานของฟังก์ชัน SELinux และวิเคราะห์ผลลัพธ์อย่างละเอียดแล้ว คุณสามารถเพิ่มการตั้งค่านโยบายของคุณเองเพื่อให้ครอบคลุมการปรับแต่งของคุณในระบบปฏิบัติการ Android นโยบายเหล่านี้ต้องยังคงเป็นไปตามข้อกำหนดของ โปรแกรมความเข้ากันได้ของ Android และต้องไม่ลบการตั้งค่า SELinux เริ่มต้นออก
ผู้ผลิตไม่ควรลบนโยบาย SELinux ที่มีอยู่ มิฉะนั้น อาจเสี่ยงที่จะทำลายการใช้งาน Android SELinux และแอปพลิเคชันที่ควบคุม ซึ่งรวมถึงแอปพลิเคชันของบริษัทอื่นที่อาจจำเป็นต้องได้รับการปรับปรุงเพื่อให้สอดคล้องและใช้งานได้ แอปพลิเคชันต้องไม่มีการปรับเปลี่ยนเพื่อให้ทำงานต่อบนอุปกรณ์ที่เปิดใช้งาน SELinux ได้
เมื่อเริ่มต้นปรับแต่ง SELinux อย่าลืม:
- เขียนนโยบาย SELinux สำหรับ daemons ใหม่ทั้งหมด
- ใช้โดเมนที่กำหนดไว้ล่วงหน้าเมื่อใดก็ตามที่เหมาะสม
- กำหนดโดเมนให้กับกระบวนการใด ๆ ที่เกิดขึ้นเป็นบริการ
init - ทำความคุ้นเคยกับมาโครก่อนเขียนนโยบาย
- ส่งการเปลี่ยนแปลงนโยบายหลักไปยัง AOSP
และจำไว้ว่าอย่า:
- สร้างนโยบายที่เข้ากันไม่ได้
- อนุญาตให้ปรับแต่งนโยบายผู้ใช้ปลายทาง
- อนุญาตให้ปรับแต่งนโยบาย MDM
- ขู่ผู้ใช้ด้วยการละเมิดนโยบาย
- เพิ่มแบ็คดอร์
ดูส่วน คุณสมบัติความปลอดภัยของเคอร์เนล ของ เอกสารข้อกำหนดความเข้ากันได้ของ Android สำหรับข้อกำหนดเฉพาะ
SELinux ใช้วิธีไวท์ลิสต์ ซึ่งหมายความว่าการเข้าถึงทั้งหมดต้องได้รับอนุญาตอย่างชัดเจนในนโยบายจึงจะได้รับอนุญาต เนื่องจากนโยบาย SELinux เริ่มต้นของ Android รองรับ Android Open Source Project อยู่แล้ว คุณไม่จำเป็นต้องแก้ไขการตั้งค่า SELinux แต่อย่างใด หากคุณกำหนดการตั้งค่า SELinux เอง โปรดระมัดระวังไม่ให้แอปพลิเคชันที่มีอยู่เสียหาย ที่จะเริ่มต้น:
- ใช้ เคอร์เนล Android ล่าสุด
- ยึดหลักอภิสิทธิ์น้อยที่สุด
- ระบุเฉพาะส่วนเพิ่มเติมของคุณเองใน Android นโยบายเริ่มต้นทำงานร่วมกับฐานรหัส โครงการโอเพนซอร์สของ Android โดยอัตโนมัติ
- แบ่งส่วนประกอบซอฟต์แวร์ออกเป็นโมดูลที่ทำงานเอกพจน์
- สร้างนโยบาย SELinux ที่แยกงานเหล่านั้นออกจากฟังก์ชันที่ไม่เกี่ยวข้อง
- ใส่นโยบายเหล่านั้นในไฟล์
*.te(ส่วนขยายสำหรับไฟล์ต้นทางนโยบาย SELinux) ภายในไดเร็กทอรี/device/ manufacturer / device-name /sepolicyและใช้ตัวแปรBOARD_SEPOLICYเพื่อรวมไว้ในบิลด์ของคุณ - ทำให้โดเมนใหม่ได้รับอนุญาตในขั้นต้น ซึ่งทำได้โดยใช้การประกาศอนุญาตในไฟล์ .
.teของโดเมน - วิเคราะห์ผลลัพธ์และปรับแต่งคำจำกัดความโดเมนของคุณ
- ลบการประกาศอนุญาตเมื่อไม่มีการปฏิเสธเพิ่มเติมปรากฏใน 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. รวมนโยบายที่จำเป็นสำหรับการทำงานของรูปภาพผลิตภัณฑ์ แต่นโยบายรูปภาพของผู้ขายไม่ควรมีความรู้ ติดตั้งในพาร์ติชันผลิตภัณฑ์
สถานการณ์นโยบายที่รองรับ
บนอุปกรณ์ที่เปิดตัวด้วย 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 เฉพาะเฟรมเวิร์ก