บทความนี้อธิบายวิธีที่ 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
หลัก
- การพึ่งพาแพลตฟอร์มดังกล่าวในไบนารีของผู้ขายต้องอยู่เบื้องหลัง HIDL HAL
คุณลักษณะที่ไม่น่าเชื่อถือ
แอปที่ไม่น่าเชื่อถือซึ่งโฮสต์รหัสที่กำหนดเองไม่ควรเข้าถึงบริการ HwBinder ยกเว้นแอปที่ถือว่าปลอดภัยเพียงพอสำหรับการเข้าถึงจากแอปดังกล่าว (ดูบริการที่ปลอดภัยด้านล่าง) เหตุผลหลักสองประการสำหรับสิ่งนี้คือ:
- เซิร์ฟเวอร์ HwBinder ไม่ดำเนินการตรวจสอบไคลเอ็นต์เนื่องจาก HIDL ไม่ได้เปิดเผยข้อมูล UID ของผู้โทรในขณะนี้ แม้ว่า HIDL จะเปิดเผยข้อมูลดังกล่าว แต่บริการ HwBinder จำนวนมากอาจทำงานในระดับที่ต่ำกว่าแอป (เช่น HAL) หรือต้องไม่พึ่งพาข้อมูลประจำตัวของแอปในการอนุญาต ดังนั้น เพื่อความปลอดภัย สมมติฐานเริ่มต้นคือทุกบริการของ HwBinder จะถือว่าลูกค้าทั้งหมดของตนมีสิทธิ์เท่าเทียมกันในการดำเนินการที่เสนอโดยบริการ
- เซิร์ฟเวอร์ HAL (ส่วนย่อยของบริการ HwBinder) มีรหัสที่มีอัตราการเกิดปัญหาด้านความปลอดภัยสูงกว่าส่วนประกอบ
system/core
ร์ และสามารถเข้าถึงชั้นล่างของสแต็ก (จนถึงฮาร์ดแวร์) จึงเป็นการเพิ่มโอกาสในการข้ามรูปแบบความปลอดภัยของ Android .
บริการที่ปลอดภัย
บริการที่ปลอดภัย ได้แก่ :
-
same_process_hwservice
บริการเหล่านี้ (ตามคำจำกัดความ) ทำงานในกระบวนการของไคลเอ็นต์ ดังนั้นจึงมีการเข้าถึงเหมือนกับโดเมนของไคลเอ็นต์ที่กระบวนการทำงาน -
coredomain_hwservice
. บริการเหล่านี้ไม่ก่อให้เกิดความเสี่ยงที่เกี่ยวข้องกับเหตุผล #2 -
hal_configstore_ISurfaceFlingerConfigs
บริการนี้ได้รับการออกแบบมาโดยเฉพาะสำหรับการใช้งานโดยโดเมนใดๆ -
hal_graphics_allocator_hwservice
การดำเนินการเหล่านี้ยังนำเสนอโดยบริการsurfaceflinger
Binder ซึ่งแอพได้รับอนุญาตให้เข้าถึง -
hal_omx_hwservice
นี่เป็นบริการ 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 และพาร์ติชันผลิตภัณฑ์
ในการทำเช่นนั้น พันธมิตรจะต้อง:
- คัดลอกไฟล์การแมปฐานที่สร้างจาก
N
system_ext และพาร์ติชันผลิตภัณฑ์ ไปยังแผนผังต้นทาง - แก้ไขไฟล์การแมปตามต้องการ
- ติดตั้งไฟล์การแม็พ กับ
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
- แพลตฟอร์ม Android
-
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.
- แพลตฟอร์ม Android
-
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/.
- แพลตฟอร์ม Android
- ไม่ใช่แพลตฟอร์ม
mac_permissions.xml
- ส่วนขยายเฉพาะอุปกรณ์สำหรับแพลตฟอร์ม
mac_permissions.xml
ที่สร้างจากmac_permissions.xml
พบในไดเรกทอรีที่ชี้ไปที่BOARD_SEPOLICY_DIRS
ในไฟล์Boardconfig.mk
ของอุปกรณ์ - ต้องอยู่ในพาร์ติชัน
vendor
ที่/vendor/etc/selinux/.
- ส่วนขยายเฉพาะอุปกรณ์สำหรับแพลตฟอร์ม