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-Writegenfs_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
- เปิดใช้ SELinux ในเคอร์เนล
CONFIG_SECURITY_SELINUX=y
- เปลี่ยนพารามิเตอร์ kernel_cmdline หรือ Bootconfig เพื่อที่ว่า
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
หรือ วันที่BOARD_BOOTCONFIG := androidboot.selinux=permissive
นโยบายนี้ใช้สำหรับการพัฒนานโยบายเบื้องต้นสำหรับอุปกรณ์เท่านั้น หลังจากที่คุณ มีนโยบาย Bootstrap เริ่มต้น ลบพารามิเตอร์นี้เพื่อให้ กำลังบังคับใช้อุปกรณ์ มิเช่นนั้น CTS จะไม่ผ่าน - เปิดเครื่องแบบไม่เข้มงวดและดูการปฏิเสธที่พบเมื่อเปิดเครื่อง:
ใน 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
- ประเมินผลลัพธ์เพื่อหาคำเตือนที่คล้ายกับ
init: Warning! Service name needs a SELinux domain defined; please fix!
ดู การตรวจสอบวิธีการ และเครื่องมือ - ระบุอุปกรณ์และไฟล์ใหม่อื่นๆ ที่ต้องติดป้ายกำกับ
- ใช้ป้ายกำกับที่มีอยู่หรือป้ายกำกับใหม่สำหรับออบเจ็กต์ ดูที่
*_contexts
ไฟล์เพื่อดูว่าก่อนหน้านี้มีการติดป้ายกำกับสิ่งต่างๆ อย่างไร และใช้ความรู้เกี่ยวกับความหมายของป้ายกำกับเพื่อกำหนดป้ายกำกับใหม่ โดยหลักการแล้ว นี่จะเป็นป้ายกำกับที่มีอยู่ซึ่งสอดคล้องกับนโยบาย แต่บางครั้ง จะต้องใช้ป้ายกำกับใหม่และกฎในการเข้าถึงป้ายกำกับนั้นจะ ที่จำเป็น เพิ่มป้ายกำกับของคุณลงในไฟล์บริบทที่เหมาะสม - ระบุโดเมน/กระบวนการที่ควรมีโดเมนความปลอดภัยของตนเอง
คุณอาจต้องเขียนนโยบายใหม่เอี่ยมสำหรับแต่ละนโยบาย ทั้งหมด
บริการที่สร้างจาก
init
ควรมี ของตัวเอง คำสั่งต่อไปนี้จะช่วยแสดงคำสั่งที่ยังทำงานอยู่ (แต่ "ทั้งหมด" ต้องเข้ารับการรักษาดังกล่าว):
วันที่adb shell su -c ps -Z | grep init
adb shell su -c dmesg | grep 'avc: '
- ตรวจสอบ
init.device.rc
เพื่อระบุโดเมนที่ ไม่มีประเภทโดเมน มอบโดเมนล่วงหน้าในบัญชี กระบวนการพัฒนาเพื่อหลีกเลี่ยงการเพิ่มกฎในinit
หรือ มิฉะนั้นให้เข้าถึงinit
ที่เข้าถึงด้วยรายการที่อยู่ใน นโยบายของตัวเอง - ตั้งค่า
BOARD_CONFIG.mk
เพื่อใช้BOARD_SEPOLICY_*
ตัวแปร โปรดดู README ในsystem/sepolicy
เพื่อดูรายละเอียดการตั้งค่า - ตรวจสอบไฟล์ init.device.rc และ fstab.device และ
โปรดตรวจสอบว่าการใช้
mount
ทั้งหมดเป็นไปตาม ระบบไฟล์ที่มีป้ายกำกับ หรือตัวเลือกcontext= mount
ที่ระบุ - ดำเนินการปฏิเสธแต่ละรายการและสร้างนโยบาย 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