การติดตั้งใช้งาน SELinux

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

ไฟล์คีย์

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

โดยทั่วไปแล้ว คุณไม่ควรแก้ไขไฟล์ system/sepolicy โดยตรง แต่ให้เพิ่มหรือแก้ไขไฟล์นโยบายเฉพาะอุปกรณ์ของคุณเองใน /device/manufacturer/device-name/sepolicy ไดเรกทอรี ใน Android 8.0 ขึ้นไป การเปลี่ยนแปลงที่คุณทำกับไฟล์เหล่านี้ควร มีผลกับนโยบายในไดเรกทอรีของผู้ให้บริการเท่านั้น สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการแยก Sepolicy สาธารณะใน Android 8.0 ขึ้นไป โปรดดูที่ การปรับแต่ง SEPolicy ใน Android 8.0 ขึ้นไป ไม่ว่าคุณจะใช้ Android เวอร์ชันใด คุณก็ยังคงแก้ไขไฟล์เหล่านี้ได้

ไฟล์นโยบาย

ไฟล์ที่ลงท้ายด้วย *.te คือไฟล์แหล่งที่มาของนโยบาย SELinux กำหนดโดเมนและป้ายกำกับ คุณอาจต้องสร้างไฟล์นโยบายใหม่ใน /device/manufacturer/device-name/sepolicy, แต่คุณควรลองอัปเดตไฟล์ที่มีอยู่หากเป็นไปได้

ไฟล์บริบท

ไฟล์บริบทคือที่ที่คุณระบุป้ายกำกับสำหรับออบเจ็กต์

• file_contexts จะติดป้ายกำกับให้กับไฟล์และใช้งานโดย คอมโพเนนต์พื้นที่ผู้ใช้ เมื่อคุณสร้างนโยบายใหม่ ให้สร้างหรืออัปเดตไฟล์นี้ เพื่อกำหนดป้ายกำกับใหม่ให้กับไฟล์ หากต้องการใช้file_contextsใหม่ สร้างอิมเมจระบบไฟล์อีกครั้งหรือเรียกใช้ restorecon บนไฟล์เพื่อ ติดป้ายกำกับใหม่ เมื่ออัปเกรด การเปลี่ยนแปลงใน file_contexts มีดังนี้ นำไปใช้กับพาร์ติชันระบบและข้อมูลผู้ใช้โดยอัตโนมัติเป็นส่วนหนึ่งของ การเปลี่ยนแปลงจะมีผลโดยอัตโนมัติเมื่ออัปเกรดเป็น พาร์ติชันโดยเพิ่มการเรียก restorecon_recursive ไปยัง init.board.rc หลังจากต่อเชื่อมพาร์ติชันแล้ว Read-Write
• genfs_contexts จะกำหนดป้ายกำกับให้กับระบบไฟล์ เช่น proc หรือ vfat ไม่รองรับขยายเวลา การกำหนดค่านี้โหลดขึ้นมาโดยเป็นส่วนหนึ่งของนโยบายเคอร์เนลแต่ การเปลี่ยนแปลงอาจไม่มีผลสำหรับโหนดในแกน (In-core) ซึ่งต้องรีบูต หรือ ยกเลิกการต่อเชื่อมและต่อเชื่อมระบบไฟล์อีกครั้งเพื่อให้การเปลี่ยนแปลงมีผลโดยสมบูรณ์ อาจกำหนดป้ายกำกับเฉพาะให้กับการต่อเชื่อมเฉพาะ เช่น vfat โดยใช้ตัวเลือก context=mount
• property_contexts กำหนดป้ายกำกับให้กับพร็อพเพอร์ตี้ของระบบ Android ให้กับ ควบคุมว่ากระบวนการใดสามารถ ตั้งค่าได้ การกำหนดค่านี้จะอ่านโดย init กระบวนการระหว่างเริ่มต้น
• service_contexts กำหนดป้ายกำกับบริการ Android Binder ให้กับ ควบคุมว่ากระบวนการใดสามารถเพิ่ม (ลงทะเบียน) และค้นหา (ค้นหา) แฟ้ม การอ้างอิงสำหรับบริการ การกำหนดค่านี้จะอ่านโดย servicemanager กระบวนการระหว่างเริ่มต้น
• seapp_contexts กำหนดป้ายกำกับให้กับกระบวนการของแอปและ /data/data ไดเรกทอรี การกำหนดค่านี้จะอ่านโดย zygote กระบวนการเมื่อเปิดแอปแต่ละครั้งและภายในวันที่ installd ในระหว่างการเริ่มต้น
• mac_permissions.xml กำหนดแท็ก seinfo ให้กับแอป ตามลายเซ็นและชื่อแพ็กเกจหรือไม่ก็ได้ จากนั้นสามารถใช้แท็ก seinfo เป็นคีย์ใน seapp_contexts เพื่อกำหนดป้ายกำกับเฉพาะให้กับแอปทั้งหมดที่มี แท็ก seinfo นั้น การกำหนดค่านี้อ่านโดย system_server ระหว่างเริ่มต้น
• keystore2_key_contexts กำหนดป้ายกำกับให้กับเนมสเปซ Keystore 2.0 เนมสเปซเหล่านี้บังคับใช้โดย Daemon Keystore2 มีคีย์สโตร์อยู่เสมอ เนมสเปซที่อิงตาม UID/AID ที่ระบุ คีย์สโตร์ 2.0 บังคับใช้ sepolicy เพิ่มเติม เนมสเปซที่กำหนด คำอธิบายโดยละเอียดเกี่ยวกับรูปแบบและธรรมเนียมปฏิบัติของ ได้ที่นี่

ไฟล์ทำ BoardConfig.mk

หลังจากแก้ไขหรือเพิ่มไฟล์นโยบายและบริบทแล้ว ให้อัปเดต /device/manufacturer/device-name/BoardConfig.mk ไฟล์ให้อ้างอิงไดเรกทอรีย่อย sepolicy และไฟล์นโยบายใหม่แต่ละไฟล์ ดูข้อมูลเพิ่มเติมเกี่ยวกับตัวแปร BOARD_SEPOLICY ได้ที่ system/sepolicy/README ไฟล์

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

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

เมื่อไฟล์นโยบายใหม่และการอัปเดต BoardConfig.mk พร้อมใช้งาน พารามิเตอร์ ระบบจะรวมการตั้งค่านโยบายไว้ในไฟล์นโยบายเคอร์เนลขั้นสุดท้ายโดยอัตโนมัติ ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีสร้างนโยบายในอุปกรณ์ได้ที่ การสร้างนโยบาย Sepolicy

การใช้งาน

วิธีเริ่มต้นใช้งาน SELinux

1. เปิดใช้ SELinux ในเคอร์เนล CONFIG_SECURITY_SELINUX=y
2. เปลี่ยนพารามิเตอร์ kernel_cmdline หรือ Bootconfig เพื่อที่ว่า

   BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive

   หรือ วันที่

   BOARD_BOOTCONFIG := androidboot.selinux=permissive

   นโยบายนี้ใช้สำหรับการพัฒนานโยบายเบื้องต้นสำหรับอุปกรณ์เท่านั้น หลังจากที่คุณ มีนโยบาย Bootstrap เริ่มต้น ลบพารามิเตอร์นี้เพื่อให้ กำลังบังคับใช้อุปกรณ์ มิเช่นนั้น CTS จะไม่ผ่าน
3. เปิดเครื่องแบบไม่เข้มงวดและดูการปฏิเสธที่พบเมื่อเปิดเครื่อง:
   ใน Ubuntu 14.04 หรือใหม่กว่า วันที่

   adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
   

   ใน Ubuntu 12.04:

   adb pull /sys/fs/selinux/policy
   adb logcat -b all | audit2allow -p policy
   

4. ประเมินผลลัพธ์เพื่อหาคำเตือนที่คล้ายกับ init: Warning! Service name needs a SELinux domain defined; please fix! ดู การตรวจสอบวิธีการ และเครื่องมือ
5. ระบุอุปกรณ์และไฟล์ใหม่อื่นๆ ที่ต้องติดป้ายกำกับ
6. ใช้ป้ายกำกับที่มีอยู่หรือป้ายกำกับใหม่สำหรับออบเจ็กต์ ดูที่ *_contexts ไฟล์เพื่อดูว่าก่อนหน้านี้มีการติดป้ายกำกับสิ่งต่างๆ อย่างไร และใช้ความรู้เกี่ยวกับความหมายของป้ายกำกับเพื่อกำหนดป้ายกำกับใหม่ โดยหลักการแล้ว นี่จะเป็นป้ายกำกับที่มีอยู่ซึ่งสอดคล้องกับนโยบาย แต่บางครั้ง จะต้องใช้ป้ายกำกับใหม่และกฎในการเข้าถึงป้ายกำกับนั้นจะ ที่จำเป็น เพิ่มป้ายกำกับของคุณลงในไฟล์บริบทที่เหมาะสม
7. ระบุโดเมน/กระบวนการที่ควรมีโดเมนความปลอดภัยของตนเอง คุณอาจต้องเขียนนโยบายใหม่เอี่ยมสำหรับแต่ละนโยบาย ทั้งหมด บริการที่สร้างจาก init ควรมี ของตัวเอง คำสั่งต่อไปนี้จะช่วยแสดงคำสั่งที่ยังทำงานอยู่ (แต่ "ทั้งหมด" ต้องเข้ารับการรักษาดังกล่าว):
   วันที่

   adb shell su -c ps -Z | grep init
   

   adb shell su -c dmesg | grep 'avc: '
   

8. ตรวจสอบ init.device.rc เพื่อระบุโดเมนที่ ไม่มีประเภทโดเมน มอบโดเมนล่วงหน้าในบัญชี กระบวนการพัฒนาเพื่อหลีกเลี่ยงการเพิ่มกฎใน init หรือ มิฉะนั้นให้เข้าถึง init ที่เข้าถึงด้วยรายการที่อยู่ใน นโยบายของตัวเอง
9. ตั้งค่า BOARD_CONFIG.mk เพื่อใช้ BOARD_SEPOLICY_* ตัวแปร โปรดดู README ใน system/sepolicy เพื่อดูรายละเอียดการตั้งค่า
10. ตรวจสอบไฟล์ init.device.rc และ fstab.device และ โปรดตรวจสอบว่าการใช้ mount ทั้งหมดเป็นไปตาม ระบบไฟล์ที่มีป้ายกำกับ หรือตัวเลือก context= mount ที่ระบุ
11. ดำเนินการปฏิเสธแต่ละรายการและสร้างนโยบาย SELinux เพื่อจัดการกับการปฏิเสธแต่ละรายการอย่างเหมาะสม โปรดดู ตัวอย่างในการปรับแต่ง

คุณควรเริ่มจากนโยบายใน AOSP แล้วจึงต่อยอดจากนโยบาย การปรับแต่งของคุณเอง สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับกลยุทธ์ด้านนโยบายและ ตรวจสอบขั้นตอนเหล่านี้อย่างละเอียด การเขียนนโยบาย SELinux

กรณีการใช้งาน

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

ลิงก์สัญลักษณ์ - เนื่องจากลิงก์สัญลักษณ์ปรากฏเป็นไฟล์ จึงมักจะ อ่านเป็นไฟล์ได้ ซึ่งอาจนำไปสู่การเจาะช่องโหว่ เช่น ผู้ใช้ที่ได้รับสิทธิ์ เช่น init เปลี่ยนสิทธิ์ของไฟล์บางไฟล์ บางครั้งเปิดมากเกินไป

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

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

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

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

setattr - สำหรับคำสั่ง เช่น chmod และ chown คุณอาจระบุชุดของไฟล์ที่มีการเชื่อมโยง โดเมนสามารถดำเนินการ setattr ได้ สิ่งอื่นนอกเหนือจากนี้อาจเป็น จากการเปลี่ยนแปลงเหล่านี้ แม้ว่าจะรากก็ตาม ดังนั้นแอปพลิเคชันอาจเรียกใช้ chmod และ chown เทียบกับรายการที่ติดป้ายกำกับว่า app_data_files แต่ไม่ใช่ shell_data_files หรือ system_data_files