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

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

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

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

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

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

ความเป็นเจ้าของและการติดฉลากออบเจ็กต์

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

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

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

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

ประเภท/แอตทริบิวต์เนมสเปซ

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

type foo, domain; → type np_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_ สำหรับคุณสมบัติของผู้ขาย)

ความเป็นเจ้าของไฟล์

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

ระบบ (/ระบบ)

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

ผู้ขาย (/ ผู้ขาย)

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

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

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

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

โปรค (/proc)

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

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

ดีบัก (/sys/เคอร์เนล/ดีบัก)

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 ทั้งแพลตฟอร์มและผู้ขายใช้ file_contexts และ genfscon เพื่อติดป้ายกำกับไฟล์ใน sysfs

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

tmpfs (/ dev)

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

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

รูท (/)

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

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

ข้อมูล (/ข้อมูล)

ข้อมูลถูกติดป้ายกำกับโดยใช้ 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 ใหม่

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

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

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

ความสามารถในการเขียนนโยบาย

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

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

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

 (allow source_foo_vN target_bar_vN (class (perm)))

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

นโยบายแตกต่าง

การสร้างแอตทริบิวต์โดยอัตโนมัติโดยการเพิ่ม _v N ต่อท้ายแต่ละประเภทจะไม่มีผลใดๆ หากไม่มีการแมปแอตทริบิวต์กับประเภทข้ามเวอร์ชันต่างๆ 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)

เมื่ออัปเกรดจาก 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 ที่สร้างสิทธิ์ในการเพิ่ม ค้นหา และแสดงรายการ daemon ของผู้ขายที่ต้องการลงทะเบียนกับ servicemanager จำเป็นต้องมีการอนุญาตที่ไม่พร้อมใช้งาน ใน Android 8.0 เฉพาะนโยบายแพลตฟอร์มเท่านั้นที่สามารถเพิ่มคลาสและการอนุญาตใหม่ได้

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

allow {domain -coredomain} *:new_class perm;

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

ลบคลาส/สิทธิ์

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

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

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

เนื่องจากนโยบายของผู้ขายเป็นนโยบายที่เก่าที่สุดบนอุปกรณ์เสมอ ไม่จำเป็นต้องแปลงประเภทผู้ขายทั้งหมดเป็นแอตทริบิวต์ในนโยบายโดยอัตโนมัติ แพลตฟอร์มนี้ไม่ต้องพึ่งพาสิ่งใดๆ ที่ระบุไว้ในนโยบายของผู้ขาย เนื่องจากแพลตฟอร์มนั้นไม่มีความรู้ในเรื่องนี้ อย่างไรก็ตาม แพลตฟอร์มจะจัดเตรียมแอตทริบิวต์และประเภทสาธารณะที่ใช้ในการโต้ตอบกับอ็อบเจ็กต์ที่มีป้ายกำกับประเภทเหล่านี้ (เช่น 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 ที่ไม่เสถียร แพลตฟอร์มไม่ควรรันไบนารีของผู้ขายโดยตรง คำแนะนำ:
    • การพึ่งพาแพลตฟอร์มดังกล่าวในไบนารีของผู้ขายต้องอยู่เบื้องหลัง 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 การดำเนินการเหล่านี้ยังนำเสนอโดยบริการ surfaceflinger Binder ซึ่งแอพได้รับอนุญาตให้เข้าถึง
  • hal_omx_hwservice นี่เป็นบริการ Mediacodec Binder เวอร์ชัน mediacodec ซึ่งแอปได้รับอนุญาตให้เข้าถึงได้
  • hal_codec2_hwservice นี่เป็นเวอร์ชันใหม่ของ hal_omx_hwservice

คุณสมบัติที่ใช้ได้

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

คำแนะนำ:

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

    หรือ

  • แอปที่ต้องการเข้าถึง HAL ของ vendor โดยตรงควรมีโดเมนแยกย่อยที่ผู้ขายกำหนด

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

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

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

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

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

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

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

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

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

เวอร์ชัน uprevs

เพื่อความเรียบง่าย แพลตฟอร์ม Android จะเผยแพร่เวอร์ชันที่แยกตัวออกจากกันเมื่อมีการตัดสาขาที่ออกใหม่ ตามที่อธิบายไว้ข้างต้น หมายเลขเวอร์ชันมีอยู่ใน 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 Uprevs ไม่ใช่ เลขจำนวนเต็มเสมอ ตัวอย่างเช่น หาก MR ชนกับเวอร์ชันจำเป็นต้องมีการเปลี่ยนแปลงที่เข้ากันไม่ได้ใน system/sepolicy/public แต่ไม่ใช่การชน API เวอร์ชัน sepolicy นั้นอาจเป็น: vN.1 เวอร์ชันที่มีอยู่ในสาขาการพัฒนาคืออุปกรณ์ที่ไม่เคยใช้ในการจัดส่ง 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 ในพาร์ติชัน N system_ext จะมีลักษณะดังนี้:

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

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

(typeattributeset foo_type_N (foo_type))

ถึง

(typeattributeset foo_type_N (foo_type bar_type))

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

การติดฉลากบริบท SELinux

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

บริบทไฟล์

Android 8.0 นำเสนอการเปลี่ยนแปลงต่อไปนี้สำหรับ file_contexts :

  • เพื่อหลีกเลี่ยงการคอมไพล์โอเวอร์เฮดบนอุปกรณ์ระหว่างการบู๊ต file_contexts จะหยุดอยู่ในรูปแบบไบนารี แต่สามารถอ่านได้ ไฟล์ข้อความนิพจน์ทั่วไป เช่น {property, service}_contexts (เหมือนก่อน 7.0)
  • file_contexts ถูกแบ่งระหว่างสองไฟล์:
    • plat_file_contexts
      • file_context แพลตฟอร์ม Android ที่ไม่มีป้ายกำกับเฉพาะอุปกรณ์ ยกเว้นส่วนการติดฉลากของพาร์ติชั่น /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 จะถูกแบ่งระหว่างสองไฟล์:

  • plat_property_contexts
    • property_context แพลตฟอร์ม Android_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 เมื่อเริ่มต้น

บริบทของแอป

ใน Android 8.0 seapp_contexts จะถูกแบ่งระหว่างสองไฟล์:

  • 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 จะถูกแบ่งระหว่างสองไฟล์:

  • แพลตฟอร์ม 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/.