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

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

การออกแบบนโยบาย SELinux ที่ใช้เสียงแหลมจะพิจารณาความแตกต่างแบบไบนารี ระหว่างนโยบายแพลตฟอร์มและผู้ให้บริการ แผนการจะกลายเป็น จะซับซ้อนมากขึ้นหากพาร์ติชันผู้ให้บริการสร้างทรัพยากร Dependency เช่น platform vendor < oem

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

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

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

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

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

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

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

นอกจากการขัดแย้งของป้ายกำกับแล้ว ประเภท/แอตทริบิวต์ SELinux อาจขัดแย้งกันด้วย ชื่อประเภท/แอตทริบิวต์ขัดแย้งกันจะส่งผลให้เกิดข้อผิดพลาดของคอมไพเลอร์นโยบายเสมอ

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

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

type foo, domain; → type vendor_foo, domain;

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

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

ประเภทที่พัก คำนำหน้าที่ยอมรับได้
พร็อพเพอร์ตี้การควบคุม ctl.vendor.
ctl.start$vendor.
ctl.stop$vendor.
init.svc.vendor.
อ่านได้เขียนได้ vendor.
อ่านอย่างเดียว ro.vendor.
ro.boot.
ro.hardware.
ต่อเนื่อง persist.vendor.

ผู้ให้บริการจะใช้ ro.boot.* (ซึ่งมาจากเคอร์เนล) ต่อไปได้ cmdline) และ ro.hardware.* (คุณสมบัติที่เกี่ยวข้องกับฮาร์ดแวร์อย่างเห็นได้ชัด)

บริการของผู้ให้บริการทั้งหมดในไฟล์ init rc ควรมี vendor. สำหรับบริการในไฟล์ init rc ของพาร์ติชันที่ไม่ใช่ระบบ กฎที่คล้ายกันได้แก่ ใช้กับป้ายกำกับ SELinux สำหรับพร็อพเพอร์ตี้ผู้ให้บริการ (vendor_ สำหรับพร็อพเพอร์ตี้ของผู้ให้บริการ)

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

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

ระบบ (/ระบบ)

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

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

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

เส้นทาง /vendor ป้ายกำกับที่แพลตฟอร์มมีให้ กระบวนการของแพลตฟอร์มขึ้นอยู่กับป้ายกำกับ
/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 แบบ Passthrough
  • เพิ่ม exec_types ใหม่ทั้งหมดในพาร์ติชัน vendor แล้ว ผ่าน SEPolicy ของผู้ให้บริการต้องมีแอตทริบิวต์ vendor_file_type ช่วงเวลานี้ คือสิ่งที่ไม่อนุญาต
  • หลีกเลี่ยงการติดป้ายกำกับเพื่อไม่ให้เกิดความขัดแย้งกับการอัปเดตแพลตฟอร์ม/เฟรมเวิร์กในอนาคต ไฟล์อื่นที่ไม่ใช่ exec_types ในพาร์ติชัน vendor
  • ทรัพยากร Dependency ของไลบรารีทั้งหมดสำหรับ HAL ของกระบวนการเดียวกันที่ระบุ AOSP ต้องเป็น ติดป้ายกำกับเป็น same_process_hal_file.

Procfs (/proc)

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

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

Debugf (/sys/kernel/debug)

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

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

ติดตาม (/ระบบ/เคอร์เนล/แก้ไขข้อบกพร่อง/การติดตาม)

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

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

Sysf (/sys)

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

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

tmpfs (/dev)

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

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

Rootf (/)

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

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

ข้อมูล (/data)

ข้อมูลมีป้ายกำกับผ่านชุดค่าผสมของ file_contexts กับ seapp_contexts

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

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

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

นโยบายเขียนด้วยประเภทของที่มีอยู่เป็นส่วนใหญ่: 

allow source_type target_type:target_class permission(s);

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

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

โดยจะเปลี่ยนเป็น 

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

แม้ว่านโยบายของผู้ให้บริการจะยังคงเหมือนเดิม แต่ v_domain จะเสียสิทธิ์เข้าถึงเนื่องจากไม่มีนโยบายสำหรับ sysfs_A ใหม่ ประเภท

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

การกำหนดนโยบายสาธารณะเป็นแอตทริบิวต์ที่มีเวอร์ชันเป็นไปตามนโยบาย 2 ข้อ เป้าหมายความเข้ากันได้

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

การเขียนนโยบาย

เพื่อบรรลุเป้าหมายในการไม่ต้องใช้ความรู้เกี่ยวกับการเปลี่ยนแปลงเวอร์ชันที่เจาะจงสำหรับ การพัฒนานโยบาย Android 8.0 มีการแมประหว่างแพลตฟอร์ม-สาธารณะ ประเภทนโยบายและแอตทริบิวต์ของนโยบาย แมปประเภท foo แล้ว ให้กับแอตทริบิวต์ foo_vN โดยที่ N คือค่า กำหนดเวอร์ชันเป้าหมาย vN สอดคล้องกับ ตัวแปรบิลด์ PLATFORM_SEPOLICY_VERSION และอยู่ในรูปแบบ MM.NN โดยที่ MM สอดคล้องกับหมายเลข SDK ของแพลตฟอร์ม และ NN เป็นเวอร์ชันเฉพาะแพลตฟอร์ม Sepolicy

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

นโยบายสาธารณะของแพลตฟอร์มที่ส่งออกเป็น allow source_foo target_bar:class perm; จะรวมอยู่ในนโยบายผู้ให้บริการ ระหว่าง คอมไพล์ (ซึ่งรวมถึง เวอร์ชันที่เกี่ยวข้อง) ข้อมูลดังกล่าวได้รับการแปลงเป็นนโยบายที่จะส่งไปยัง ส่วนผู้ให้บริการของอุปกรณ์ (แสดงในส่วน "ขั้นกลางทั่วไป" ที่เปลี่ยนรูปแบบ ภาษา (CIL)): 

 (allow source_foo_vN target_bar_vN (class (perm)))

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

ความแตกต่างของนโยบาย

สร้างแอตทริบิวต์โดยอัตโนมัติด้วยการเพิ่ม _vN ต่อท้าย ของแต่ละประเภทไม่ได้ทำอะไรหากไม่มีการแมปแอตทริบิวต์กับประเภทในเวอร์ชันต่างๆ แตกต่าง Android จะคงการแมประหว่างเวอร์ชันสำหรับแอตทริบิวต์และ ประเภทกับแอตทริบิวต์เหล่านั้น การดำเนินการนี้สามารถทำได้ในการแมปที่กล่าวถึงข้างต้น ไฟล์ที่มีคำสั่ง เช่น (CIL): 

(typeattributeset foo_vN (foo))

การอัปเกรดแพลตฟอร์ม

ส่วนต่อไปนี้จะแสดงรายละเอียดสถานการณ์ต่างๆ สำหรับการอัปเกรดแพลตฟอร์ม

ประเภทเดียวกัน

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

binder_device_v1 … binder_device_vN

เมื่ออัปเกรดจาก v1 → v2 นโยบายแพลตฟอร์มต้อง ประกอบด้วย: 

type binder_device; -> (type binder_device) (in CIL)

ในไฟล์การแมป v1 (CIL) ให้ทำดังนี้ 

(typeattributeset binder_device_v1 (binder_device))

ในไฟล์การแมป v2 (CIL) ให้ทำดังนี้ 

(typeattributeset binder_device_v2 (binder_device))

ในนโยบายผู้ให้บริการ v1 (CIL) 

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

ในนโยบายผู้ให้บริการ v2 (CIL) 

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
ประเภทใหม่

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

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

เมื่ออัปเกรดจาก v1 → v2 นโยบายแพลตฟอร์มต้อง ประกอบด้วย: 

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

ในไฟล์การแมป v1 (CIL) ให้ทำดังนี้ 

(typeattributeset sysfs_v1 (sysfs sysfs_A))

ในไฟล์การแมป v2 (CIL) ให้ทำดังนี้ 

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

ในนโยบายผู้ให้บริการ v1 (CIL) 

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

ในนโยบายผู้ให้บริการ v2 (CIL) 

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
ประเภทที่นำออก

สถานการณ์ (ซึ่งเกิดขึ้นไม่บ่อยนัก) นี้จะเกิดขึ้นเมื่อมีการนำประเภทหนึ่งๆ ออก ซึ่งอาจเกิดขึ้นได้เมื่อ ออบเจ็กต์ที่เกี่ยวข้อง:

  • ยังคงอยู่แต่ได้รับป้ายกำกับอื่น
  • นำออกแล้วโดยแพลตฟอร์ม

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

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

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

ตัวอย่างของเวอร์ชัน 1: ประเภทการยุบ (นำ sysfs_A ออก)

เมื่ออัปเกรดจาก v1 → v2 นโยบายแพลตฟอร์มต้อง ประกอบด้วย: 

type sysfs; (type sysfs) (in CIL)

ในไฟล์การแมป v1 (CIL) ให้ทำดังนี้ 

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

ในไฟล์การแมป v2 (CIL) ให้ทำดังนี้ 

(typeattributeset sysfs_v2 (sysfs))

ในนโยบายผู้ให้บริการ v1 (CIL) 

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

ในนโยบายผู้ให้บริการ v2 (CIL) 

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

ตัวอย่างเวอร์ชัน 2: การนำออกโดยสมบูรณ์ (foo type)

เมื่ออัปเกรดจาก v1 → v2 นโยบายแพลตฟอร์มต้อง ประกอบด้วย: 

# nothing - we got rid of the type

ในไฟล์การแมป v1 (CIL) ให้ทำดังนี้ 

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

ในไฟล์การแมป v2 (CIL) ให้ทำดังนี้ 

# nothing - get rid of it

ในนโยบายผู้ให้บริการ v1 (CIL) 

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

ในนโยบายผู้ให้บริการ v2 (CIL) 

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
คลาส/สิทธิ์ใหม่

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

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

allow {domain -coredomain} *:new_class perm;

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

ชั้นเรียน/สิทธิ์ที่นำออกแล้ว

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

การปรับแต่งผู้ให้บริการสำหรับ ประเภทใหม่/ประเภทที่ติดป้ายกำกับใหม่

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

เนื่องจากนโยบายของผู้ให้บริการเป็นนโยบายที่เก่าที่สุดในอุปกรณ์เสมอ คุณจึงไม่จำเป็นต้องดำเนินการ จะแปลงประเภทผู้ให้บริการทั้งหมดเป็นแอตทริบิวต์ในนโยบายโดยอัตโนมัติ แพลตฟอร์ม ไม่ได้อาศัยสิ่งใดที่มีป้ายกำกับในนโยบายผู้ให้บริการเนื่องจากแพลตฟอร์มไม่มี ความรู้ เกี่ยวกับเรื่องนี้ แต่แพลตฟอร์มนี้จะระบุแอตทริบิวต์และ ประเภทที่จะใช้ในการโต้ตอบกับออบเจ็กต์ที่มีป้ายกำกับประเภทนี้ (เช่น domain, sysfs_type ฯลฯ) เพื่อให้แพลตฟอร์ม จะมีการโต้ตอบอย่างถูกต้องกับออบเจ็กต์ แอตทริบิวต์ และประเภท ต้องนำไปใช้อย่างเหมาะสม และอาจต้องเพิ่มกฎที่เฉพาะเจาะจงลงใน โดเมนที่ปรับแต่งได้ (เช่น init)

การเปลี่ยนแปลงแอตทริบิวต์สำหรับ 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 ที่ไม่เสถียร แพลตฟอร์มไม่ควรดำเนินการกับไบนารีของผู้ให้บริการ โดยตรง คำแนะนำ
    • ทรัพยากร Dependency ของแพลตฟอร์มดังกล่าวบนไบนารีของผู้ให้บริการจะต้องอยู่หลัง HIDL HAL

      หรือ

    • coredomains ที่ต้องการสิทธิ์เข้าถึงไบนารีของผู้ให้บริการควรทำดังนี้ ถูกย้ายไปยังพาร์ติชันผู้ให้บริการ ดังนั้นจะหยุดเป็น coredomain

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

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

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

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

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

  • same_process_hwservice บริการเหล่านี้ (ตามคำจำกัดความ) จะทำงานใน กระบวนการของลูกค้า จึงมีสิทธิ์เข้าถึงระดับเดียวกับโดเมนไคลเอ็นต์ใน ที่กระบวนการทำงาน
  • coredomain_hwservice บริการเหล่านี้ไม่ก่อให้เกิดความเสี่ยง ที่เกี่ยวข้องกับเหตุผลที่ 2
  • hal_configstore_ISurfaceFlingerConfigs บริการนี้ ออกแบบมาสำหรับใช้งานในโดเมนต่างๆ โดยเฉพาะ
  • hal_graphics_allocator_hwservice การดำเนินการเหล่านี้ยัง เสนอโดยบริการ Binder ของ surfaceflinger แอปใดได้รับอนุญาต เพื่อเข้าถึง
  • 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

คำแนะนำ

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

    หรือ

  • แอปที่จำเป็นต้องเข้าถึง HAL ของ vendor โดยตรงจะต้องมี โดเมน Sepolicy ที่ผู้ให้บริการกำหนด

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

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

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

นโยบายสาธารณะบนแพลตฟอร์มเป็นหัวใจสำคัญของการปฏิบัติตาม Android 8.0 โมเดลสถาปัตยกรรมโดยไม่ต้องคงการรวมนโยบายแพลตฟอร์มไว้ จาก v1 และ v2 ผู้ให้บริการเห็นนโยบายแพลตฟอร์มบางส่วนที่ มีประเภทและแอตทริบิวต์ที่ใช้ได้ และกฎสำหรับประเภทและแอตทริบิวต์เหล่านั้น ซึ่งจะกลายเป็นส่วนหนึ่งของนโยบายผู้ให้บริการ (เช่น vendor_sepolicy.cil)

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

การแมปกับเชนแอตทริบิวต์

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

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

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

Uprev เวอร์ชัน

เพื่อความง่าย แพลตฟอร์ม Android จะเปิดตัวเวอร์ชัน Sepolicy เมื่อ ตัด Branch ของรุ่นแล้ว ดังที่อธิบายไว้ข้างต้น หมายเลขเวอร์ชันจะอยู่ใน PLATFORM_SEPOLICY_VERSION และอยู่ในรูปแบบ MM.nn โดยที่ MM สอดคล้องกับค่า SDK และ nn คือค่า คงมูลค่าส่วนตัวไว้ใน /platform/system/sepolicy.สำหรับ เช่น 19.0 สำหรับ Kitkat, 21.0 สำหรับ Lollipop 22.0 สำหรับ Lollipop-MR1 23.0 สำหรับ Marshmallow 24.0 สำหรับ Nougat, 25.0 สำหรับ Nougat-MR1, 26.0 สำหรับ Oreo, 27.0 สำหรับ Oreo-MR1 และ 28.0 สำหรับ Android 9 การเพิ่มขึ้นไม่ใช่จำนวนเต็มเสมอไป สำหรับ ตัวอย่างเช่น หาก MR ตัดไปที่เวอร์ชันหนึ่ง ทำให้จำเป็นต้องมีการเปลี่ยนแปลงที่เข้ากันไม่ได้ใน system/sepolicy/public แต่ไม่ได้เกิดการชน API แล้ว SEpolicy นั้น เวอร์ชันอาจเป็น: vN.1 เวอร์ชันที่อยู่ระหว่างการพัฒนา Branch เป็น 10000.0 ที่ไม่ได้ใช้ในการจัดส่ง

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

ผลกระทบด้านประสิทธิภาพของ หลายแอตทริบิวต์

ตามที่อธิบายไว้ใน https://github.com/SELinuxProject/cil/issues/9 แอตทริบิวต์จำนวนมากที่กำหนดให้กับประเภทจะส่งผลให้เกิดปัญหาด้านประสิทธิภาพ ในกรณีที่แคชนโยบายหายไป

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

นโยบายสาธารณะและนโยบายสาธารณะของผลิตภัณฑ์ System_ext

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

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

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

โดยพาร์ทเนอร์จะต้องทำดังนี้

  1. คัดลอกไฟล์การแมปพื้นฐานที่สร้างขึ้นจาก N system_ext และพาร์ติชันผลิตภัณฑ์ กับแผนผังต้นทาง
  2. แก้ไขไฟล์การแมปตามที่จำเป็น
  3. ติดตั้ง การแมปไฟล์ไปยัง N+1 (หรือใหม่กว่า) system_ext และ พาร์ติชันผลิตภัณฑ์

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

(typeattributeset foo_type_N (foo_type))
(expandtypeattribute foo_type_N true)
(typeattribute foo_type_N)

หากเพิ่ม bar_type ไปยัง system_ext ของ N+1 และ ควรจับคู่ bar_type กับ foo_type สำหรับ อัปเดตผู้ให้บริการ N ราย N.cil ได้จาก 

(typeattributeset foo_type_N (foo_type))

สู่ 

(typeattributeset foo_type_N (foo_type bar_type))

จากนั้นจึงติดตั้งลงในพาร์ติชันของ system_ext N+1 ผู้ให้บริการ N รายสามารถเข้าถึง N+1 ต่อไปได้ foo_type และ bar_type ของ system_ext

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

เพื่อรองรับความแตกต่างระหว่างนโยบายแพลตฟอร์มและผู้ให้บริการ ระบบจะสร้างไฟล์บริบท 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 เฉพาะแพลตฟอร์ม Android สำหรับ servicemanager 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/.