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