บทความนี้จะอธิบายวิธีที่ 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;
คุณสมบัติของระบบและความเป็นเจ้าของการติดฉลากกระบวนการ
การหลีกเลี่ยงการชนกันของป้ายกำกับจะแก้ไขได้ดีที่สุดโดยใช้เนมสเปซคุณสมบัติ หากต้องการระบุคุณสมบัติของแพลตฟอร์มได้อย่างง่ายดายและหลีกเลี่ยงความขัดแย้งของชื่อเมื่อเปลี่ยนชื่อหรือเพิ่มคุณสมบัติของแพลตฟอร์มที่ส่งออก ตรวจสอบให้แน่ใจว่าคุณสมบัติของผู้จำหน่ายทั้งหมดมีส่วนนำหน้าเป็นของตัวเอง:
ประเภทอสังหาริมทรัพย์ | คำนำหน้าที่ยอมรับได้ |
---|---|
คุณสมบัติการควบคุม | 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 , installd , idmap ฯลฯ |
/vendor/overlay(/. * ) | vendor_overlay_file | system_server , zygote , idmap ฯลฯ |
ด้วยเหตุนี้จึงต้องปฏิบัติตามกฎเฉพาะ (บังคับใช้ผ่าน 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
- การพึ่งพาแพลตฟอร์มดังกล่าวในไบนารีของผู้ขายจะต้องอยู่เบื้องหลัง 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 เวอร์ชัน 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
(หรือใหม่กว่า) และพาร์ติชันผลิตภัณฑ์
ในการทำเช่นนั้น พันธมิตรจะต้อง:
- คัดลอกไฟล์การแม็พฐานที่สร้างขึ้นจาก
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
- แพลตฟอร์ม Android
property_context
ที่ไม่มีป้ายกำกับเฉพาะอุปกรณ์ - ต้องอยู่ในพาร์ติชัน
system
ที่/system/etc/selinux/plat_property_contexts
และโหลดโดยinit
เมื่อเริ่มต้นพร้อมกับ vendorproperty_contexts
- แพลตฟอร์ม Android
-
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
เมื่อเริ่มต้นพร้อมกับ vendorservice_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
เมื่อเริ่มต้น
-
บริบทของ Seapp
ใน 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/.
- ส่วนขยายเฉพาะอุปกรณ์ไปยังแพลตฟอร์ม