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

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

การออกแบบนโยบาย SELinux ที่ใช้ Treble พิจารณาความแตกต่างแบบไบนารีระหว่าง แพลตฟอร์ม และนโยบาย ผู้จำหน่าย รูปแบบจะซับซ้อนมากขึ้นหากพาร์ติชันผู้ขายสร้างการพึ่งพา เช่น 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;

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

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

ผู้จำหน่ายสามารถใช้ 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 ได้ ตัวอย่าง:

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

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

Procfs (/โปรค)

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

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

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

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

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

Tracefs (/sys/kernel/debug/การติดตาม)

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 จึงมีการแมประหว่างประเภทนโยบายสาธารณะของแพลตฟอร์มและคุณลักษณะ ประเภท 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 ที่สร้างสิทธิ์ในการเพิ่ม ค้นหา และแสดงรายการ ผู้จำหน่าย daemons ที่ต้องการลงทะเบียนกับ 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 เวอร์ชัน HwBinder ซึ่งแอปต่างๆ ได้รับอนุญาตให้เข้าถึงได้
• 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 โดยไม่ต้องรักษาการรวมนโยบายแพลตฟอร์มจากเวอร์ชัน 1 และเวอร์ชัน 2 เข้าด้วยกัน ผู้ขายจะพบกับชุดย่อยของนโยบายแพลตฟอร์มที่มีประเภทและคุณลักษณะที่ใช้งานได้ รวมถึงกฎเกี่ยวกับประเภทและคุณลักษณะเหล่านั้น ซึ่งต่อมาจะกลายเป็นส่วนหนึ่งของนโยบายผู้ขาย (เช่น vendor_sepolicy.cil )

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

การแมปกับกลุ่มแอตทริบิวต์

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

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

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

การปรับปรุงเวอร์ชัน

เพื่อความเรียบง่าย แพลตฟอร์ม Android จะเผยแพร่เวอร์ชัน sepolicy เมื่อสาขาการเผยแพร่ใหม่ถูกตัดออก ตามที่อธิบายไว้ข้างต้น หมายเลขเวอร์ชันอยู่ใน 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 Bump ไปยังเวอร์ชันต่างๆ จำเป็นต้องมีการเปลี่ยนแปลงที่เข้ากันไม่ได้ใน system/sepolicy/public แต่ไม่ใช่การ Bump 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 ที่มี system_ext N+1 (หรือใหม่กว่า) และพาร์ติชันผลิตภัณฑ์

ในการทำเช่นนั้น พันธมิตรจะต้อง:

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
  • แพลตฟอร์ม Android property_context ที่ไม่มีป้ายกำกับเฉพาะอุปกรณ์
  • ต้องอยู่ในพาร์ติชัน system ที่ /system/etc/selinux/plat_property_contexts และโหลดโดย init เมื่อเริ่มต้นพร้อมกับ vendor 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 เมื่อเริ่มต้นพร้อมกับ vendor 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 จะถูกแบ่งออกเป็นสองไฟล์:

• 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/.