การกำหนดค่า SELinux

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

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

เมื่อดำเนินการปรับแต่ง SELinux อย่าลืม

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

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

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

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

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

  1. ใช้เมนู Android รุ่นล่าสุด kernel
  2. ใช้ หลักการ ของสิทธิ์ขั้นต่ำที่สุด
  3. จัดการเฉพาะส่วนที่เพิ่มมาใน Android ของคุณเอง นโยบายเริ่มต้นจะทำงานร่วมกับ โอเพนซอร์สของ Android ฐานของโค้ดโปรเจ็กต์โดยอัตโนมัติ
  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 เริ่มต้นเป็น patch หากแพตช์คือ ที่ใช้กับนโยบายความปลอดภัยเริ่มต้น คุณไม่จำเป็นต้องทำการเปลี่ยนแปลงนี้กับ 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 };

ลองมาดูตัวอย่างกัน

ในบรรทัดแรก การประกาศประเภท Daemon ของ DHCP จะรับค่าจาก นโยบายความปลอดภัยพื้นฐาน (domain) จากแถลงการณ์ก่อนหน้า เช่น DHCP จะอ่านและเขียนจาก /dev/null ได้

ในบรรทัดที่ 2 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 และอินเทอร์เน็ตอาจสื่อสารกับ กันผ่านข้อบ่งชี้ไฟล์, ไฟล์ FIFO, ซ็อกเก็ต Datagram และสตรีม UNIX Socket 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
ระบบไฟล์ 
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 ของ SELinux ห้ามพฤติกรรมที่ไม่ควรเกิดขึ้น ด้วยการทดสอบความเข้ากันได้ มีการบังคับใช้กฎ neverallow ของ SELinux ในอุปกรณ์ต่างๆ แล้ว

หลักเกณฑ์ต่อไปนี้มีไว้เพื่อช่วยให้ผู้ผลิตหลีกเลี่ยงข้อผิดพลาด เกี่ยวข้องกับกฎ 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;
กฎนี้มีไว้เพื่อป้องกันการดำเนินการของโค้ดที่กำหนดเองในระบบ กล่าวโดยเจาะจงคือ Google จะยืนยันว่าจะมีการดำเนินการเฉพาะโค้ดใน /system เท่านั้น ซึ่งทำให้มีการรับประกันความปลอดภัยด้วยกลไกต่างๆ เช่น การเปิดเครื่องที่ได้รับการยืนยัน มักจะเป็นวิธีแก้ปัญหาที่ดีที่สุดเมื่อพบปัญหาเกี่ยวกับเรื่องนี้ กฎ neverallow ข้อคือการย้ายโค้ดที่ไม่เหมาะสมไปยัง พาร์ติชัน /system

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

ส่วนนี้จะแสดงหลักเกณฑ์สำหรับนโยบาย SELinux ของผู้ให้บริการใน Android 8.0 และ รวมถึงรายละเอียดเกี่ยวกับ SEPolicy สำหรับโครงการโอเพนซอร์ส Android (AOSP) และ ส่วนขยาย SEPolicy ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีเก็บนโยบาย 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 รวมนโยบายที่จำเป็นสำหรับ การทำงานของอิมเมจระบบ แต่นโยบายอิมเมจของผู้ให้บริการรายใดควร ไม่รู้เลย
  • ระบบ/sepolicy/ผู้ให้บริการ มีนโยบายสำหรับคอมโพเนนต์ที่ ไปที่ /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 อ้างอิง

การสนับสนุนรูปภาพผู้ให้บริการเพื่อทำงาน ด้วย 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 แบบขยาย

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

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

นโยบายสำหรับการโต้ตอบของคอมโพเนนต์ AOSP สาธารณะกับอิมเมจระบบเท่านั้น ส่วนขยายควรเป็น system/sepolicy/private

อิมเมจระบบ ส่วนขยายที่เข้าถึงเฉพาะอินเทอร์เฟซ AOSP

ตัวอย่าง: กระบวนการใหม่ของระบบที่ไม่ใช่ AOSP ต้องเข้าถึง HAL ใน ที่ AOSP ใช้อยู่

ซึ่งคล้ายกับ system-image-only ตัวอย่างส่วนขยาย ยกเว้นคอมโพเนนต์ใหม่ของระบบที่อาจโต้ตอบ อินเทอร์เฟซ 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 รุ่นถัดไปและต้องมีสิทธิ์เข้าถึง ไม่ใช่ AOSP HAL

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

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

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