ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP

หน้านี้ได้รับการแปลโดย Cloud Translation API

ความเข้ากันได้ของนโยบาย

หน้านี้อธิบายวิธีที่ Android จัดการปัญหาความเข้ากันได้ของนโยบายกับการอัปเดตแพลตฟอร์มแบบ Over-The-Air (OTA) ซึ่งการตั้งค่า SELinux ของแพลตฟอร์มใหม่อาจแตกต่างจากการตั้งค่า SELinux ของผู้จำหน่ายเก่า

การเป็นเจ้าของและการติดป้ายกำกับออบเจ็กต์

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

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

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

การกำหนดเนมสเปซของประเภท/ชื่อแอตทริบิวต์

นอกเหนือจากการทับซ้อนของป้ายกำกับแล้ว ชื่อประเภทและแอตทริบิวต์ของ SELinux ยังอาจทับซ้อนกันได้ด้วย SELinux ไม่อนุญาตให้ประกาศประเภทและแอตทริบิวต์เดียวกันหลายครั้ง นโยบายที่มีการประกาศซ้ำจะคอมไพล์ไม่สำเร็จ เราขอแนะนำอย่างยิ่งให้การประกาศของผู้ให้บริการทั้งหมดเริ่มต้นด้วยคำนำหน้า vendor_ เพื่อหลีกเลี่ยงการชนกันของประเภท และชื่อแอตทริบิวต์ เช่น ผู้ขายควรใช้ type vendor_foo, domain; แทน type foo, domain;

การเป็นเจ้าของไฟล์

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

ระบบ (/system)

เฉพาะอิมเมจระบบเท่านั้นที่ต้องระบุป้ายกำกับสำหรับคอมโพเนนต์ /system ถึง file_contexts, service_contexts ฯลฯ หากมีการเพิ่มป้ายกำกับ สำหรับคอมโพเนนต์ /system ในนโยบายของผู้ให้บริการ การอัปเดต OTA เฉพาะเฟรมเวิร์กอาจเป็นไปไม่ได้

ผู้ให้บริการ (/vendor)

นโยบาย SELinux ของ AOSP ติดป้ายกำกับส่วนต่างๆ ของพาร์ติชัน vendor ที่แพลตฟอร์มโต้ตอบด้วยอยู่แล้ว ซึ่งช่วยให้เขียนกฎ SELinux สำหรับกระบวนการของแพลตฟอร์มเพื่อให้สามารถพูดคุยหรือเข้าถึงส่วนต่างๆ ของพาร์ติชัน vendor ได้ ตัวอย่าง

/vendor path	ป้ายกำกับที่แพลตฟอร์มระบุ	กระบวนการของแพลตฟอร์มขึ้นอยู่กับป้ายกำกับ
`/vendor(/.*)?`	`vendor_file`	ไคลเอ็นต์ HAL ทั้งหมดในเฟรมเวิร์ก `ueventd` ฯลฯ
`/vendor/framework(/.*)?`	`vendor_framework_file`	`dex2oat`, `appdomain` และอื่นๆ
`/vendor/app(/.*)?`	`vendor_app_file`	`dex2oat`, `installd`, `idmap` ฯลฯ
`/vendor/overlay(/.*)`	`vendor_overlay_file`	`system_server`, `zygote`, `idmap` ฯลฯ

ดังนั้น คุณต้องปฏิบัติตามกฎที่เฉพาะเจาะจง (บังคับใช้ผ่าน neverallows) เมื่อติดป้ายกำกับไฟล์เพิ่มเติมในพาร์ติชัน vendor

vendor_file ต้องเป็นป้ายกำกับเริ่มต้นสำหรับไฟล์ทั้งหมดใน พาร์ติชัน vendor นโยบายแพลตฟอร์มกำหนดให้ต้องทำเช่นนี้เพื่อ เข้าถึงการใช้งาน HAL แบบส่งผ่าน
exec_typesใหม่ทั้งหมดที่เพิ่มในพาร์ติชัน vendor ผ่านนโยบายของผู้ให้บริการต้องมีแอตทริบิวต์ vendor_file_type ซึ่งบังคับใช้ผ่าน neverallows
เพื่อหลีกเลี่ยงการขัดแย้งกับการอัปเดตแพลตฟอร์ม/เฟรมเวิร์กในอนาคต ให้หลีกเลี่ยงการติดป้ายกำกับ ไฟล์อื่นๆ นอกเหนือจาก exec_types ในพาร์ติชัน vendor
การขึ้นต่อกันของไลบรารีทั้งหมดสำหรับ HAL ของกระบวนการเดียวกันที่ AOSP ระบุต้องมีป้ายกำกับเป็น same_process_hal_file.

Procfs (/proc)

ไฟล์ใน /proc อาจติดป้ายกำกับได้โดยใช้ป้ายกำกับ genfscon เท่านั้น ใน Android 7.0 ทั้งนโยบายแพลตฟอร์มและนโยบายผู้ให้บริการใช้ genfscon เพื่อติดป้ายกำกับไฟล์ใน procfs

คำแนะนำ: ป้ายกำกับนโยบายแพลตฟอร์มเท่านั้น /proc หากกระบวนการของผู้ให้บริการต้องเข้าถึงไฟล์ใน /proc ที่ปัจจุบันมีป้ายกำกับเริ่มต้น (proc) นโยบายของผู้ให้บริการไม่ควรติดป้ายกำกับอย่างชัดเจน แต่ควรใช้ประเภท proc ทั่วไปเพื่อเพิ่มกฎสำหรับโดเมนของผู้ให้บริการแทน ซึ่งจะช่วยให้แพลตฟอร์ม อัปเดตเพื่อรองรับอินเทอร์เฟซเคอร์เนลในอนาคตที่แสดงผ่าน procfs และติดป้ายกำกับอย่างชัดเจนได้ตามต้องการ

Debugfs (/sys/kernel/debug)

Debugfs สามารถติดป้ายกำกับได้ทั้งใน file_contexts และ genfscon ใน Android 7.0 ถึง Android 10 ทั้งแพลตฟอร์มและป้ายกำกับของผู้ให้บริการ debugfs

ใน Android 11 debugfs จะเข้าถึงหรือติดตั้งในอุปกรณ์ที่ใช้งานจริงไม่ได้ ผู้ผลิตอุปกรณ์ควร นำ debugfs ออก

Tracefs (/sys/kernel/debug/tracing)

Tracefs สามารถติดป้ายกำกับได้ทั้งใน file_contexts และ genfscon ใน Android 7.0 มีเพียงป้ายกำกับแพลตฟอร์ม tracefs

คำแนะนำ: มีเพียงแพลตฟอร์มเท่านั้นที่ติดป้ายกำกับ tracefs ได้

Sysfs (/sys)

ไฟล์ใน /sys อาจมีป้ายกำกับโดยใช้ทั้ง file_contexts และ genfscon ใน Android 7.0 ทั้งแพลตฟอร์มและผู้ให้บริการใช้ genfscon เพื่อติดป้ายกำกับไฟล์ใน sysfs

คำแนะนำ: แพลตฟอร์มอาจติดป้ายกำกับsysfs โหนดที่ไม่เจาะจงอุปกรณ์ มิฉะนั้นจะมีเพียงผู้ให้บริการเท่านั้นที่ติดป้ายกำกับไฟล์ได้

tmpfs (/dev)

ไฟล์ใน /dev อาจติดป้ายกำกับใน file_contexts ใน Android 7.0 ทั้งแพลตฟอร์มและไฟล์ป้ายกำกับของผู้ให้บริการจะอยู่ที่นี่

คำแนะนำ: ผู้ให้บริการอาจติดป้ายกำกับเฉพาะไฟล์ใน /dev/vendor (เช่น /dev/vendor/foo /dev/vendor/socket/bar)

Rootfs (/)

ไฟล์ใน / อาจติดป้ายกำกับใน file_contexts ใน Android 7.0 ทั้งไฟล์ป้ายกำกับของแพลตฟอร์มและผู้ให้บริการจะอยู่ที่นี่

คำแนะนำ: มีเพียงระบบเท่านั้นที่ติดป้ายกำกับไฟล์ใน / ได้

ข้อมูล (/data)

ระบบจะติดป้ายกำกับข้อมูลผ่านการผสมผสานระหว่าง file_contexts และ seapp_contexts

คำแนะนำ: ไม่อนุญาตให้ติดป้ายกำกับของผู้ให้บริการภายนอก /data/vendor มีเพียงแพลตฟอร์มเท่านั้นที่ติดป้ายกำกับส่วนอื่นๆ ของ /data

เวอร์ชันป้ายกำกับ Genfs

ตั้งแต่ vendor API level 202504 เป็นต้นไป ป้ายกำกับ SELinux รุ่นใหม่ที่กำหนดด้วย genfscon ใน system/sepolicy/compat/plat_sepolicy_genfs_ver.cil จะ ไม่บังคับสำหรับพาร์ติชัน vendor รุ่นเก่า ซึ่งจะช่วยให้พาร์ติชันรุ่นเก่า vendorยังคงใช้การติดตั้งใช้งาน SEPolicy ที่มีอยู่ได้ ซึ่งควบคุมโดยตัวแปร Makefile BOARD_GENFS_LABELS_VERSION ซึ่งจัดเก็บไว้ใน /vendor/etc/selinux/genfs_labels_version.txt

ตัวอย่าง

ในระดับ API ของผู้ให้บริการ 202404 ระบบจะติดป้ายกำกับโหนด /sys/class/udc เป็น sysfs โดยค่าเริ่มต้น
ตั้งแต่ API ระดับ 202504 ของผู้ให้บริการเป็นต้นไป /sys/class/udc จะมีป้ายกำกับเป็น sysfs_udc

อย่างไรก็ตาม /sys/class/udc อาจใช้งานโดยพาร์ติชัน vendor ที่ใช้ API ระดับ 202404 โดยมีป้ายกำกับ sysfs เริ่มต้นหรือป้ายกำกับเฉพาะของผู้ให้บริการ การติดป้ายกำกับ /sys/class/udc เป็น sysfs_udc โดยไม่มีเงื่อนไขอาจทำให้เกิดปัญหาความเข้ากันได้ กับพาร์ติชัน vendor เหล่านี้ การเลือก BOARD_GENFS_LABELS_VERSIONจะทำให้แพลตฟอร์มใช้ป้ายกำกับและสิทธิ์ก่อนหน้า สำหรับพาร์ติชัน vendor รุ่นเก่าต่อไป

BOARD_GENFS_LABELS_VERSION อาจมากกว่าหรือเท่ากับระดับ API ของผู้ให้บริการ เช่น vendorพาร์ติชันที่ใช้ API ระดับ 202404 สามารถตั้งค่า BOARD_GENFS_LABELS_VERSION เป็น 202504 เพื่อใช้ป้ายกำกับใหม่ที่เปิดตัว ใน 202504 ดูรายการ ป้ายกำกับ genfs ที่เฉพาะเจาะจงสำหรับ 202504

เมื่อติดป้ายกำกับโหนด genfscon แพลตฟอร์มต้องพิจารณาพาร์ติชันรุ่นเก่า vendorและใช้กลไกการย้อนกลับเพื่อ ความเข้ากันได้เมื่อจำเป็น แพลตฟอร์มสามารถใช้ไลบรารีเฉพาะแพลตฟอร์มเพื่อค้นหา เวอร์ชันป้ายกำกับ genfs

ในโฆษณาเนทีฟ ให้ใช้ libgenfslabelsversion ดู genfslabelsversion.h สำหรับไฟล์ส่วนหัวของ libgenfslabelsversion
ใน Java ให้ใช้ android.os.SELinux.getGenfsLabelsVersion()

นโยบายสาธารณะของแพลตฟอร์ม

นโยบาย SELinux ของแพลตฟอร์มแบ่งออกเป็นแบบส่วนตัวและแบบสาธารณะ นโยบายสาธารณะของแพลตฟอร์มประกอบด้วยประเภทและแอตทริบิวต์ที่พร้อมใช้งานเสมอ สำหรับระดับ API ของผู้ให้บริการ ซึ่งทำหน้าที่เป็น API ระหว่างแพลตฟอร์มกับผู้ให้บริการ นโยบายนี้จะแสดงต่อผู้เขียนนโยบายของผู้ให้บริการ เพื่อให้ผู้ให้บริการสร้างไฟล์นโยบายของผู้ให้บริการได้ ซึ่งเมื่อ รวมกับนโยบายส่วนตัวของแพลตฟอร์มแล้ว จะส่งผลให้นโยบายของอุปกรณ์ทํางานได้อย่างเต็มที่ นโยบายแพลตฟอร์มสาธารณะกำหนดไว้ใน system/sepolicy/public

เช่น ประเภท vendor_init ซึ่งแสดงถึงกระบวนการเริ่มต้นใน บริบทของผู้ให้บริการ จะกำหนดไว้ใน system/sepolicy/public/vendor_init.te ดังนี้

type vendor_init, domain;

ผู้ให้บริการสามารถดูประเภท vendor_init เพื่อเขียนกฎนโยบายที่กำหนดเองได้

# Allow vendor_init to set vendor_audio_prop in vendor's init scripts
set_prop(vendor_init, vendor_audio_prop)

แอตทริบิวต์ความเข้ากันได้

นโยบาย SELinux คือการโต้ตอบระหว่างประเภทต้นทางและเป้าหมายสำหรับ คลาสออบเจ็กต์และสิทธิ์ที่เฉพาะเจาะจง ออบเจ็กต์ทุกรายการ (เช่น กระบวนการ ไฟล์) ที่ได้รับผลกระทบจากนโยบาย SELinux จะมีได้เพียงประเภทเดียว แต่ประเภทนั้นอาจมีแอตทริบิวต์หลายรายการ

นโยบายส่วนใหญ่เขียนขึ้นโดยอิงตามประเภทที่มีอยู่ ในที่นี้ ทั้ง vendor_init และ debugfs เป็นประเภท

allow vendor_init debugfs:dir { mounton };

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

/sys(/.*)? u:object_r:sysfs:s0

นโยบายผู้ให้บริการให้สิทธิ์เข้าถึง /sys/usb ที่มีป้ายกำกับ sysfs ดังนี้

allow vendor_init sysfs:chr_file rw_file_perms;

หากมีการเปลี่ยนแปลงนโยบายแพลตฟอร์มเพื่อติดป้ายกำกับ /sys/usb เป็น sysfs_usb นโยบายของผู้ให้บริการจะยังคงเหมือนเดิม แต่ vendor_init จะสูญเสียสิทธิ์เข้าถึง /sys/usb เนื่องจากไม่มี นโยบายสำหรับ sysfs_usb ประเภทใหม่

/sys/usb u:object_r:sysfs_usb:s0

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

เช่น สมมติว่า /sys/usb มีป้ายกำกับเป็น sysfs ในนโยบายแพลตฟอร์ม 202504 และนโยบายผู้ขาย 202504 ให้สิทธิ์ vendor_init เข้าถึง /sys/usb ในกรณีดังกล่าว ให้ทำดังนี้

นโยบายผู้ให้บริการเขียนกฎ allow vendor_init sysfs:chr_file rw_file_perms; เนื่องจาก /sys/usb มีป้ายกำกับเป็น sysfs ในนโยบายแพลตฟอร์ม 202504 เมื่อระบบบิลด์คอมไพล์ นโยบายของผู้ให้บริการ ระบบจะแปลกฎเป็น allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms; โดยอัตโนมัติ แอตทริบิวต์ vendor_init_202504 และ sysfs_202504 สอดคล้องกับประเภท vendor_init และ sysfs ซึ่งเป็นประเภทที่แพลตฟอร์มกำหนด
ระบบบิลด์จะสร้างไฟล์การจับคู่ข้อมูลประจำตัว /system/etc/selinux/mapping/202504.cil เนื่องจากทั้งพาร์ติชัน system และ vendor ใช้ เวอร์ชัน 202504 เดียวกัน ไฟล์การแมปจึงมีการจับคู่ข้อมูลประจำตัว จาก type_202504 ไปยัง type เช่น vendor_init_202504 จับคู่กับ vendor_init และ sysfs_202504 จับคู่กับ sysfs
```
(typeattributeset sysfs_202504 (sysfs))
(typeattributeset vendor_init_202504 (vendor_init))
...
```

เมื่ออัปเกรดเวอร์ชันจาก 202504 เป็น 202604 ระบบจะสร้างไฟล์การแมปใหม่สำหรับพาร์ติชัน 202504 vendor ภายใต้ system/sepolicy/private/compat/202504/202504.cil ซึ่งจะติดตั้งลงใน /system/etc/selinux/mapping/202504.cil สำหรับพาร์ติชัน 202604 หรือใหม่กว่า system ในระยะแรก ไฟล์การแมปนี้จะมี การแมปข้อมูลประจำตัวตามที่อธิบายไว้ก่อนหน้านี้ หากมีการเพิ่มป้ายกำกับใหม่ sysfs_usb สำหรับ /sys/usb ลงในนโยบายแพลตฟอร์ม 202604 ระบบจะอัปเดตไฟล์การแมป เพื่อแมป sysfs_202504 กับ sysfs_usb ดังนี้

(typeattributeset sysfs_202504 (sysfs sysfs_usb))
(typeattributeset vendor_init_202504 (vendor_init))
...

การอัปเดตนี้จะช่วยให้กฎนโยบายของผู้ให้บริการที่แปลงแล้ว allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms; สามารถให้สิทธิ์เข้าถึงvendor_initประเภท sysfs_usb ใหม่โดยอัตโนมัติ

หากต้องการรักษาความเข้ากันได้กับพาร์ติชัน vendor รุ่นเก่า เมื่อใดก็ตามที่มีการเพิ่มประเภทสาธารณะใหม่ ประเภทนั้นจะต้องแมปกับแอตทริบิวต์ที่มีการกำหนดเวอร์ชันอย่างน้อย 1 รายการในไฟล์การแมป system/sepolicy/private/compat/ver/ver.cil หรือแสดงอยู่ใน system/sepolicy/private/compat/ver/ver.ignore.cil เพื่อระบุว่าไม่มีประเภทที่ตรงกันในเวอร์ชันของผู้ให้บริการก่อนหน้า

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

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

system_ext public and product public policy

ตั้งแต่ Android 11 เป็นต้นไป system_ext และพาร์ติชัน product จะได้รับอนุญาตให้ส่งออกประเภทสาธารณะที่กำหนดไปยังพาร์ติชัน vendor เช่นเดียวกับนโยบายสาธารณะของแพลตฟอร์ม นโยบายของผู้ให้บริการ จะใช้ประเภทและกฎที่แปลเป็นแอตทริบิวต์ที่มีการควบคุมเวอร์ชันโดยอัตโนมัติ เช่น จาก type เป็น type_ver โดยที่ ver คือระดับ API ของผู้ให้บริการ ของพาร์ติชัน vendor

เมื่อพาร์ติชัน system_ext และ product อิงตามแพลตฟอร์มเวอร์ชันเดียวกัน ver ระบบบิลด์จะสร้างไฟล์การแมปฐานไปยัง system_ext/etc/selinux/mapping/ver.cil และ product/etc/selinux/mapping/ver.cil ซึ่งมี การแมปข้อมูลประจำตัวจาก type ไปยัง type_ver นโยบายของผู้ให้บริการสามารถเข้าถึง type ด้วยแอตทริบิวต์ที่มีการควบคุมเวอร์ชัน type_ver

ในกรณีที่อัปเดตเฉพาะพาร์ติชัน system_ext และ product เช่น ver เป็น ver+1 (หรือหลังจากนั้น) ในขณะที่พาร์ติชัน vendor ยังคงอยู่ที่ ver นโยบายของผู้ให้บริการอาจสูญเสียสิทธิ์เข้าถึงประเภทของพาร์ติชัน system_ext และ product เพื่อป้องกันการหยุดทำงาน พาร์ติชัน system_ext และ product ควรมี ไฟล์การแมปจากประเภทที่เฉพาะเจาะจงไปยังแอตทริบิวต์ type_ver พาร์ทเนอร์แต่ละรายมีหน้าที่รับผิดชอบในการดูแลไฟล์การแมป หากรองรับพาร์ติชัน ver vendor ที่มี ver+1 (หรือใหม่กว่า) system_ext และพาร์ติชัน product

หากต้องการติดตั้งไฟล์การแมปไปยังพาร์ติชัน system_ext และ product ผู้ติดตั้งใช้งานอุปกรณ์หรือผู้ให้บริการควรทำดังนี้

คัดลอกไฟล์การแมปฐานที่สร้างขึ้นจากพาร์ติชัน ver system_ext และ product ไปยังแผนผังแหล่งที่มา
แก้ไขไฟล์การแมปตามต้องการ
ติดตั้งver+1system_extproduct

ตัวอย่างเช่น สมมติว่าพาร์ติชัน 202504 system_ext มีประเภทสาธารณะ 1 ประเภทชื่อ foo_type จากนั้น system_ext/etc/selinux/mapping/202504.cil ในพาร์ติชัน 202504 system_ext จะมีลักษณะดังนี้

(typeattributeset foo_type_202504 (foo_type))
(expandtypeattribute foo_type_202504 true)
(typeattribute foo_type_202504)

หากมีการเพิ่ม bar_type ลงใน 202604 system_ext และหาก bar_type ควรแมปกับ foo_type สำหรับพาร์ติชัน 202504 vendor คุณจะอัปเดต 202504.cil จาก (typeattributeset foo_type_202504 (foo_type)) เป็น (typeattributeset foo_type_202504 (foo_type bar_type)) แล้วติดตั้งลงในพาร์ติชัน 202604 system_ext ได้ พาร์ติชัน 202504 vendor จะยังคงเข้าถึง foo_type และ bar_type ของ 202604 system_ext ได้

การเปลี่ยนแปลงแอตทริบิวต์สำหรับ Android 9

อุปกรณ์ที่อัปเกรดเป็น Android 9 จะใช้แอตทริบิวต์ต่อไปนี้ได้ แต่อุปกรณ์ที่เปิดตัวด้วย Android 9 จะใช้ไม่ได้

แอตทริบิวต์ของผู้ละเมิด

Android 9 มีแอตทริบิวต์ที่เกี่ยวข้องกับโดเมนต่อไปนี้

data_between_core_and_vendor_violators แอตทริบิวต์สำหรับโดเมนทั้งหมดที่ละเมิดข้อกำหนดในการไม่แชร์ไฟล์ตาม เส้นทางระหว่าง vendor กับ coredomains กระบวนการของแพลตฟอร์มและ ผู้ให้บริการไม่ควรใช้ไฟล์ในดิสก์เพื่อสื่อสาร (ABI ไม่เสถียร) คำแนะนำ
- รหัสผู้ให้บริการควรใช้ /data/vendor
- ระบบไม่ควรใช้ /data/vendor
system_executes_vendor_violators. แอตทริบิวต์ สำหรับโดเมนของระบบทั้งหมด (ยกเว้น init และ shell domains) ที่ละเมิดข้อกำหนดในการไม่เรียกใช้ไบนารีของผู้ให้บริการ การดำเนินการไบนารีของผู้ให้บริการมี API ที่ไม่เสถียร แพลตฟอร์มไม่ควรเรียกใช้ไบนารีของผู้ให้บริการ โดยตรง คำแนะนำ
- การขึ้นต่อกันของแพลตฟอร์มดังกล่าวกับไบนารีของผู้ให้บริการต้องอยู่เบื้องหลัง HIDL HAL
  หรือ
- coredomains ที่ต้องเข้าถึงไบนารีของผู้ให้บริการควรย้ายไปที่พาร์ติชัน vendor และหยุดเป็น coredomain

แอตทริบิวต์ที่ไม่น่าเชื่อถือ

แอปที่ไม่น่าเชื่อถือซึ่งโฮสต์โค้ดที่กำหนดเองไม่ควรมีสิทธิ์เข้าถึงบริการ HwBinder ยกเว้นบริการที่ถือว่าปลอดภัยเพียงพอสำหรับการเข้าถึงจากแอปดังกล่าว (ดูบริการที่ปลอดภัยด้านล่าง) สาเหตุหลัก 2 ประการที่ทำให้เกิดกรณีนี้มีดังนี้

เซิร์ฟเวอร์ HwBinder ไม่ได้ทำการตรวจสอบสิทธิ์ไคลเอ็นต์เนื่องจากปัจจุบัน HIDL ไม่ได้แสดงข้อมูล UID ของผู้โทร แม้ว่า HIDL จะเปิดเผยข้อมูลดังกล่าว แต่บริการ HwBinder จำนวนมาก ทำงานในระดับที่ต่ำกว่าแอป (เช่น HAL) หรือ ต้องไม่ใช้ข้อมูลประจำตัวของแอปเพื่อการให้สิทธิ์ ดังนั้น เพื่อความปลอดภัย สมมติฐานเริ่มต้น คือบริการ HwBinder ทุกบริการจะถือว่าไคลเอ็นต์ทั้งหมดได้รับอนุญาตให้ดำเนินการที่บริการนำเสนอ อย่างเท่าเทียมกัน
เซิร์ฟเวอร์ HAL (ชุดย่อยของบริการ HwBinder) มีโค้ดที่มีอัตราการเกิดปัญหาด้านความปลอดภัยสูงกว่าsystem/coreคอมโพเนนต์และมีสิทธิ์เข้าถึงเลเยอร์ที่ต่ำกว่าของสแต็ก (ลงไปจนถึงฮาร์ดแวร์) จึงเพิ่มโอกาสในการข้ามโมเดลความปลอดภัยของ Android

บริการที่ปลอดภัย

บริการที่ปลอดภัยมีดังนี้

same_process_hwservice บริการเหล่านี้ (ตามคำจำกัดความ) ทำงานใน กระบวนการของไคลเอ็นต์ จึงมีสิทธิ์เข้าถึงเหมือนกับโดเมนไคลเอ็นต์ที่ กระบวนการทำงาน
coredomain_hwservice บริการเหล่านี้ไม่มีความเสี่ยง ที่เกี่ยวข้องกับเหตุผล #2
hal_configstore_ISurfaceFlingerConfigs บริการนี้ออกแบบมาเพื่อใช้กับโดเมนใดก็ได้โดยเฉพาะ
hal_graphics_allocator_hwservice การดำเนินการเหล่านี้ยัง มีให้บริการโดยบริการ surfaceflinger Binder ซึ่งแอปได้รับอนุญาต ให้เข้าถึง
hal_omx_hwservice นี่คือ HwBinder เวอร์ชันของ mediacodec บริการ Binder ซึ่งแอปได้รับอนุญาตให้เข้าถึง
hal_codec2_hwservice นี่คือเวอร์ชันใหม่กว่าของ hal_omx_hwservice

แอตทริบิวต์ที่ใช้ได้

hwservices ที่ไม่ถือว่าปลอดภัยทั้งหมดจะมีแอตทริบิวต์ untrusted_app_visible_hwservice เซิร์ฟเวอร์ HAL ที่เกี่ยวข้องมีแอตทริบิวต์ untrusted_app_visible_halserver อุปกรณ์ที่เปิดตัว พร้อม Android 9 ต้องไม่ใช้ untrusted แอตทริบิวต์ใดแอตทริบิวต์หนึ่ง

คำแนะนำ

แอปที่ไม่น่าเชื่อถือควรสื่อสารกับบริการของระบบที่สื่อสารกับ HAL ของ HIDL ของผู้ให้บริการแทน เช่น แอปสามารถพูดคุยกับ binderservicedomain จากนั้น mediaserver (ซึ่งเป็น binderservicedomain) จะพูดคุยกับ hal_graphics_allocator
หรือ
แอปที่ต้องการเข้าถึง vendor HAL โดยตรงควรมีโดเมน sepolicy ที่กำหนดโดยผู้ให้บริการของตนเอง

การทดสอบแอตทริบิวต์ไฟล์

Android 9 มีการทดสอบเวลาบิลด์ที่ช่วยให้มั่นใจว่าไฟล์ทั้งหมดในตำแหน่งที่เฉพาะเจาะจง มีแอตทริบิวต์ที่เหมาะสม (เช่น ไฟล์ทั้งหมดใน sysfs มีแอตทริบิวต์ sysfs_type ที่จำเป็น)

การติดป้ายกำกับบริบท SELinux

เพื่อรองรับความแตกต่างระหว่าง sepolicy ของแพลตฟอร์มและของผู้ให้บริการ ระบบจะสร้างไฟล์บริบท SELinux ในลักษณะที่แตกต่างกันเพื่อให้แยกกัน

บริบทของไฟล์

Android 8.0 ได้นำการเปลี่ยนแปลงต่อไปนี้มาใช้กับ file_contexts

เพื่อหลีกเลี่ยงค่าใช้จ่ายในการคอมไพล์เพิ่มเติมในอุปกรณ์ระหว่างการบูต file_contexts จะไม่มีอยู่ในรูปแบบไบนารี แต่จะเป็นไฟล์ข้อความนิพจน์ทั่วไปที่อ่านได้ เช่น {property, service}_contexts (เช่นเดียวกับในเวอร์ชันก่อน 7.0)
file_contexts จะแยกออกเป็น 2 ไฟล์ ดังนี้
- plat_file_contexts
  - แพลตฟอร์ม Android file_context ที่ไม่มีป้ายกำกับเฉพาะอุปกรณ์ ยกเว้นการติดป้ายกำกับส่วนของพาร์ติชัน /vendor ที่ต้องติดป้ายกำกับอย่างถูกต้องเพื่อให้ไฟล์ sepolicy ทำงานได้อย่างเหมาะสม
  - ต้องอยู่ในพาร์ติชัน system ที่ /system/etc/selinux/plat_file_contexts ในอุปกรณ์และ โหลดโดย init เมื่อเริ่มต้นพร้อมกับ file_context ของผู้ให้บริการ
- vendor_file_contexts
  - file_contextเฉพาะอุปกรณ์ที่สร้างขึ้นโดยการรวม file_contexts ที่พบในไดเรกทอรีที่ระบุโดย BOARD_SEPOLICY_DIRS ในไฟล์ Boardconfig.mk ของอุปกรณ์
  - ต้องติดตั้งที่ /vendor/etc/selinux/vendor_file_contexts ในพาร์ติชัน vendor และโหลดโดย init ที่จุดเริ่มต้นพร้อมกับแพลตฟอร์ม file_context

บริบทของพร็อพเพอร์ตี้

ใน Android 8.0 property_contexts จะแยกออกเป็น 2 ไฟล์ดังนี้

plat_property_contexts
- แพลตฟอร์ม Android property_context ที่ไม่มีป้ายกำกับเฉพาะอุปกรณ์
- ต้องอยู่ในพาร์ติชัน system ที่ /system/etc/selinux/plat_property_contexts และโหลดโดย init เมื่อเริ่มต้นพร้อมกับ property_contexts ของผู้ให้บริการ
vendor_property_contexts
- property_contextเฉพาะอุปกรณ์ที่สร้างขึ้นโดยการรวม property_contexts ที่พบในไดเรกทอรีที่ระบุโดย BOARD_SEPOLICY_DIRS ใน Boardconfig.mk ของอุปกรณ์
- ต้องอยู่ในพาร์ติชัน vendor ที่ /vendor/etc/selinux/vendor_property_contexts และต้อง โหลดโดย init เมื่อเริ่มต้นพร้อมกับแพลตฟอร์ม property_context

บริบทของบริการ

ใน Android 8.0 service_contexts จะแยกเป็นไฟล์ต่อไปนี้

plat_service_contexts
- service_context สำหรับ servicemanager โดยเฉพาะแพลตฟอร์ม Android service_context ไม่มีป้ายกำกับเฉพาะอุปกรณ์
- ต้องอยู่ในพาร์ติชัน system ที่ /system/etc/selinux/plat_service_contexts และโหลดโดย servicemanager ที่จุดเริ่มต้นพร้อมกับ service_contexts ของผู้ให้บริการ
vendor_service_contexts
- service_contextเฉพาะอุปกรณ์ที่สร้างขึ้นโดยการรวม service_contexts ที่พบในไดเรกทอรีที่ระบุโดย BOARD_SEPOLICY_DIRS ใน Boardconfig.mk ของอุปกรณ์
- ต้องอยู่ในพาร์ติชัน vendor ที่ /vendor/etc/selinux/vendor_service_contexts และโหลดโดย servicemanager เมื่อเริ่มต้นพร้อมกับแพลตฟอร์ม service_contexts
- แม้ว่า servicemanager จะค้นหาไฟล์นี้ในเวลาที่เปิดเครื่อง แต่สำหรับอุปกรณ์ TREBLE ที่เป็นไปตามข้อกำหนดอย่างสมบูรณ์ vendor_service_contexts จะต้องไม่มีอยู่ เนื่องจาก การโต้ตอบทั้งหมดระหว่าง vendor กับ system ต้องผ่าน hwservicemanager/hwbinder
plat_hwservice_contexts
- แพลตฟอร์ม Android hwservice_context สำหรับ hwservicemanager ที่ไม่มีป้ายกำกับเฉพาะอุปกรณ์
- ต้องอยู่ในพาร์ติชัน system ที่ /system/etc/selinux/plat_hwservice_contexts และโหลดโดย hwservicemanager ที่จุดเริ่มต้นพร้อมกับ vendor_hwservice_contexts
vendor_hwservice_contexts
- hwservice_contextเฉพาะอุปกรณ์ที่สร้างขึ้นโดยการรวม hwservice_contexts ที่พบในไดเรกทอรีที่ระบุโดย BOARD_SEPOLICY_DIRS ใน Boardconfig.mk ของอุปกรณ์
- ต้องอยู่ในพาร์ติชัน vendor ที่ /vendor/etc/selinux/vendor_hwservice_contexts และต้อง โหลดโดย hwservicemanager ที่จุดเริ่มต้นพร้อมกับ plat_service_contexts
vndservice_contexts
- service_contextเฉพาะอุปกรณ์สำหรับ vndservicemanagerที่สร้างขึ้นโดยการรวม vndservice_contextsที่อยู่ในไดเรกทอรีที่ระบุโดย BOARD_SEPOLICY_DIRSใน Boardconfig.mkของอุปกรณ์
- ไฟล์นี้ต้องอยู่ในพาร์ติชัน vendor ที่ /vendor/etc/selinux/vndservice_contexts และโหลดโดย vndservicemanager เมื่อเริ่มต้น

บริบท Seapp

ใน Android 8.0 seapp_contexts จะแยกออกเป็น 2 ไฟล์ดังนี้

plat_seapp_contexts
- แพลตฟอร์ม Android seapp_context ที่ไม่มีการเปลี่ยนแปลง เฉพาะอุปกรณ์
- ต้องอยู่ในพาร์ติชัน system ที่ /system/etc/selinux/plat_seapp_contexts.
vendor_seapp_contexts
- ส่วนขยายเฉพาะอุปกรณ์สำหรับแพลตฟอร์ม seapp_context ที่สร้างขึ้น โดยการรวม seapp_contexts ที่พบในไดเรกทอรี ซึ่ง BOARD_SEPOLICY_DIRS ชี้ไปยังในไฟล์ Boardconfig.mk ของอุปกรณ์
- ต้องอยู่ในพาร์ติชัน vendor ที่ /vendor/etc/selinux/vendor_seapp_contexts

สิทธิ์ MAC

ใน Android 8.0 mac_permissions.xml จะแยกออกเป็น 2 ไฟล์ดังนี้

แพลตฟอร์ม mac_permissions.xml
- แพลตฟอร์ม Android mac_permissions.xml ที่ไม่มี การเปลี่ยนแปลงเฉพาะอุปกรณ์
- ต้องอยู่ในพาร์ติชัน system ที่ /system/etc/selinux/.
นอกแพลตฟอร์ม mac_permissions.xml
- ส่วนขยายเฉพาะอุปกรณ์ไปยังแพลตฟอร์ม mac_permissions.xml สร้างจาก mac_permissions.xml พบในไดเรกทอรีที่ระบุโดย BOARD_SEPOLICY_DIRS ใน Boardconfig.mk ของอุปกรณ์
- ต้องอยู่ในพาร์ติชัน vendor ที่ /vendor/etc/selinux/.