Google มุ่งมั่นที่จะพัฒนาความเท่าเทียมทางเชื้อชาติสำหรับชุมชนคนผิวดำ มาดูกันว่า
หน้านี้ได้รับการแปลโดย Cloud Translation API
Switch to English

Init Vendor

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

init ผู้ขาย ถูกออกแบบมาเพื่อปิดหลุมนี้โดยการใช้ vendor_init Linux (SELinux) โดเมนเพิ่มความปลอดภัยแยกต่างหากเพื่อรันคำสั่งที่พบใน /vendor มีสิทธิ์เฉพาะของผู้ขาย

กลไก

ผู้ขาย init จะให้กระบวนการย่อยของ init เริ่มต้นในกระบวนการบูตด้วยบริบท SELinux u:r:vendor_init:s0 บริบท SELinux นี้มีการอนุญาตน้อยกว่าบริบทเริ่มต้นเริ่มต้นอย่างมากและการเข้าถึงนั้น จำกัด เฉพาะไฟล์คุณสมบัติและอื่น ๆ ที่เฉพาะเจาะจงของผู้ขายหรือเป็นส่วนหนึ่งของ ABI ของผู้จำหน่ายระบบที่มีความเสถียร

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

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

ลูปการประมวลผลหลักของ init ประกอบด้วยการตรวจสอบว่าหากคำสั่งนั้นมีคำอธิบายประกอบเพื่อทำงานในกระบวนการย่อยของผู้จัดจำหน่ายและมีต้นกำเนิดจากสคริปต์ผู้จำหน่ายคำสั่งนั้นจะถูกส่งผ่านการสื่อสารระหว่างกระบวนการ (IPC) ไปยังกระบวนการย่อย init ของผู้จัดจำหน่าย และส่งผลลัพธ์กลับไปที่ init

การใช้ Vendor Init

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

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

type=1400 audit(1511821362.996:9): avc: denied { search } for pid=540 comm="init" name="nfc" dev="sda45" ino=1310721 scontext=u:r:vendor_init:s0 tcontext=u:object_r:nfc_data_file:s0 tclass=dir permissive=0
init: Command 'write /data/nfc/bad_file_access 1234' action=boot (/vendor/etc/init/hw/init.walleye.rc:422) took 2ms and failed: Unable to write to file '/data/nfc/bad_file_access': open() failed: Permission denied

หากคำสั่งล้มเหลวมีสองตัวเลือก:

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

สำหรับอุปกรณ์ที่เปิดตัวก่อน Android 9 กฎของเนเวอร์โลว์อาจถูกบายพาสได้โดยการเพิ่ม data_between_core_and_vendor_violators พิมพ์ซ้ำไปยังไฟล์ vendor_init.te เฉพาะอุปกรณ์

รหัสตำแหน่ง

จำนวนมากของตรรกะสำหรับผู้ขาย init IPC อยู่ใน ระบบ / core / init / subcontext.cpp

ตารางคำสั่งอยู่ในคลาส BuiltinFunctionMap ใน system / core / init / builtins.cpp และมีหมายเหตุประกอบที่ระบุว่าคำสั่งจะต้องทำงานในกระบวนการย่อย init ของผู้ขายหรือไม่

SEPolicy สำหรับผู้จัดจำหน่าย init ถูกแบ่งข้ามไพรเวต ( system / sepolicy / private / vendor_init.te ) และ public ( system / sepolicy / public / vendor_init.te ) ใน system / sepolicy