กำลังตรวจสอบ SELinux

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

หลังจากใช้นโยบายใหม่ ตรวจสอบให้แน่ใจว่า SELinux ทำงานในโหมดที่ถูกต้องบนอุปกรณ์โดยออกคำสั่ง getenforce

สิ่งนี้จะพิมพ์โหมด SELinux ส่วนกลาง: บังคับใช้หรืออนุญาต ในการกำหนดโหมด SELinux สำหรับแต่ละโดเมน คุณต้องตรวจสอบไฟล์ที่เกี่ยวข้องหรือเรียกใช้ sepolicy-analyze เวอร์ชันล่าสุดด้วยแฟล็กที่เหมาะสม ( -p ) มีอยู่ใน /platform/system/sepolicy/tools/

การอ่านปฏิเสธ

ตรวจสอบข้อผิดพลาด ซึ่งกำหนดเส้นทางเป็นบันทึกเหตุการณ์ไปยัง dmesg และ logcat และสามารถดูได้ในอุปกรณ์ ผู้ผลิตควรตรวจสอบเอาต์พุต SELinux ไปที่ dmesg บนอุปกรณ์เหล่านี้และปรับแต่งการตั้งค่าก่อนเผยแพร่สู่สาธารณะในโหมดอนุญาตและเปลี่ยนเป็นโหมดบังคับใช้ในที่สุด ข้อความบันทึกของ SELinux มี avc: และอาจพบได้ง่ายด้วย grep เป็นไปได้ที่จะจับบันทึกการปฏิเสธที่กำลังดำเนินอยู่โดยการรัน cat /proc/kmsg หรือจับบันทึกการปฏิเสธจากการบู๊ตครั้งก่อนโดยการรัน cat /sys/fs/pstore/console-ramoops

ด้วยผลลัพธ์นี้ ผู้ผลิตสามารถระบุได้อย่างง่ายดายเมื่อผู้ใช้หรือส่วนประกอบระบบละเมิดนโยบาย SELinux ผู้ผลิตสามารถซ่อมแซมพฤติกรรมที่ไม่ดีนี้ได้โดยการเปลี่ยนแปลงซอฟต์แวร์ นโยบาย SELinux หรือทั้งสองอย่าง

โดยเฉพาะอย่างยิ่ง ข้อความบันทึกเหล่านี้บ่งชี้ว่ากระบวนการใดจะล้มเหลวภายใต้โหมดบังคับใช้และเหตุใด นี่คือตัวอย่าง:

avc: denied  { connectto } for  pid=2671 comm="ping" path="/dev/socket/dnsproxyd"
scontext=u:r:shell:s0 tcontext=u:r:netd:s0 tclass=unix_stream_socket

ตีความผลลัพธ์นี้ดังนี้:

  • { connectto } ด้านบนแสดงถึงการดำเนินการที่กำลังดำเนินการ เมื่อรวมกับ tclass ในตอนท้าย ( unix_stream_socket ) จะบอกคุณคร่าวๆ ว่ากำลังทำอะไรอยู่ ในกรณีนี้ มีบางอย่างพยายามเชื่อมต่อกับยูนิกซ์สตรีมซ็อกเก็ต
  • scontext (u:r:shell:s0) บอกคุณว่าบริบทใดที่เริ่มต้นการดำเนินการ ในกรณีนี้เป็นสิ่งที่ทำงานเป็นเชลล์
  • tcontext (u:r:netd:s0) จะบอกบริบทของเป้าหมายของการดำเนินการ ในกรณีนี้ นั่นคือ unix_stream_socket ที่ netd เป็นเจ้าของ
  • comm="ping" ที่ด้านบนจะให้คำแนะนำเพิ่มเติมเกี่ยวกับสิ่งที่กำลังดำเนินการในขณะที่สร้างการปฏิเสธ ในกรณีนี้ เป็นคำใบ้ที่ดีทีเดียว

ตัวอย่างอื่น:

adb shell su root dmesg | grep 'avc: '

เอาท์พุท:

<5> type=1400 audit: avc:  denied  { read write } for  pid=177
comm="rmt_storage" name="mem" dev="tmpfs" ino=6004 scontext=u:r:rmt:s0
tcontext=u:object_r:kmem_device:s0 tclass=chr_file

นี่คือองค์ประกอบหลักจากการปฏิเสธนี้:

  • การดำเนินการ - การดำเนินการที่พยายามจะเน้นในวงเล็บ read write หรือ setenforce
  • นักแสดง - รายการ scontext (บริบทต้นทาง) แสดงถึงนักแสดง ในกรณีนี้คือ rmt_storage daemon
  • ออบเจ็กต์ - รายการ tcontext (บริบทเป้าหมาย) แสดงถึงอ็อบเจ็กต์ที่กำลังดำเนินการ ในกรณีนี้คือ kmem
  • ผลลัพธ์ - รายการ tclass (คลาสเป้าหมาย) ระบุประเภทของอ็อบเจ็กต์ที่กำลังดำเนินการ ในกรณีนี้คือ chr_file (อุปกรณ์อักขระ)

ดัมพ์ผู้ใช้และ Kernel Stacks

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

เคอร์เนลล่าสุดกำหนดจุดติดตามชื่อ avc:selinux_audited ใช้ Android simpleperf เพื่อเปิดใช้งาน tracepoint นี้และจับ callchain

การกำหนดค่าที่รองรับ

  • เคอร์เนลลิ นุ กซ์ >= 5.10 โดยเฉพาะสาขาเคอร์เนลทั่วไปของ Android และ android12-5.10 ได้รับการสนับสนุน รองรับสาขา android12-5.4 ด้วย คุณสามารถใช้ simpleperf เพื่อตรวจสอบว่าจุดติดตามถูกกำหนดบนอุปกรณ์ของคุณหรือไม่: adb root && adb shell simpleperf list | grep avc:selinux_audited สำหรับเคอร์เนลเวอร์ชันอื่น คุณอาจใช้ cherry pick commits dd81662 และ 30969bc
  • มันควรจะเป็นไปได้ที่จะทำซ้ำเหตุการณ์ที่คุณกำลังแก้ไขจุดบกพร่อง ไม่รองรับเหตุการณ์เวลาบูตโดยใช้ simpleperf; อย่างไรก็ตาม คุณอาจยังสามารถเริ่มบริการใหม่เพื่อทริกเกอร์เหตุการณ์ได้

จับสายการโทร

ขั้นตอนแรกคือการบันทึกเหตุการณ์โดยใช้ simpleperf record :

adb shell -t "cd /data/local/tmp && su root simpleperf record -a -g -e avc:selinux_audited"

จากนั้น เหตุการณ์ที่ก่อให้เกิดการปฏิเสธควรเกิดขึ้น หลังจากนั้นควรหยุดการบันทึก ในตัวอย่างนี้ โดยใช้ Ctrl-c ตัวอย่างควรได้รับการบันทึก:

^Csimpleperf I cmd_record.cpp:751] Samples recorded: 1. Samples lost: 0.

สุดท้าย อาจใช้ simpleperf report เพื่อตรวจสอบ stacktrace ที่จับได้ ตัวอย่างเช่น:

adb shell -t "cd /data/local/tmp && su root simpleperf report -g --full-callgraph"
[...]
Children  Self     Command  Pid   Tid   Shared Object                                   Symbol
100.00%   0.00%    dmesg    3318  3318  /apex/com.android.runtime/lib64/bionic/libc.so  __libc_init
       |
       -- __libc_init
          |
           -- main
              toybox_main
              toy_exec_which
              dmesg_main
              klogctl
              entry_SYSCALL_64_after_hwframe
              do_syscall_64
              __x64_sys_syslog
              do_syslog
              selinux_syslog
              slow_avc_audit
              common_lsm_audit
              avc_audit_post_callback
              avc_audit_post_callback

ห่วงโซ่การโทรด้านบนเป็นเคอร์เนลแบบรวมและสายการเรียกของ userspace ช่วยให้คุณมีมุมมองที่ดีขึ้นของการไหลของโค้ดโดยเริ่มต้นการติดตามจาก userspace ไปจนถึงเคอร์เนลที่เกิดการปฏิเสธ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ simpleperf โปรดดู คำสั่งอ้างอิงคำสั่ง Simpleperf Executable

เปลี่ยนเป็นอนุญาต

การบังคับใช้ SELinux สามารถปิดใช้งานได้ผ่าน ADB บน ​​userdebug หรือ eng builds ในการดำเนินการดังกล่าว ก่อนอื่นให้เปลี่ยน ADB เป็น root โดยเรียกใช้ adb root จากนั้นหากต้องการปิดใช้งานการบังคับใช้ SELinux ให้เรียกใช้:

adb shell setenforce 0

หรือที่บรรทัดคำสั่งเคอร์เนล (ระหว่างการนำอุปกรณ์ต้นทาง):

androidboot.selinux=permissive
androidboot.selinux=enforcing

หรือผ่าน bootconfig ใน Android 12:

androidboot.selinux=permissive
androidboot.selinux=enforcing

ใช้ audit2allow

เครื่องมือ audit2allow ใช้การปฏิเสธ dmesg และแปลงเป็นคำสั่งนโยบาย SELinux ที่เกี่ยวข้อง ด้วยเหตุนี้ จึงสามารถเร่งการพัฒนา SELinux ได้อย่างมาก

หากต้องการใช้งาน ให้เรียกใช้:

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

อย่างไรก็ตาม ต้องใช้ความระมัดระวังเพื่อตรวจสอบการเพิ่มแต่ละรายการที่อาจเป็นไปได้สำหรับการอนุญาตที่เกินขอบเขต ตัวอย่างเช่น การป้อน audit2allow อนุญาตการปฏิเสธ rmt_storage ที่แสดงผลลัพธ์ก่อนหน้านี้ในคำสั่งนโยบาย SELinux ที่แนะนำต่อไปนี้:

#============= shell ==============
allow shell kernel:security setenforce;
#============= rmt ==============
allow rmt kmem_device:chr_file { read write };

สิ่งนี้จะทำให้ rmt สามารถเขียนหน่วยความจำเคอร์เนลซึ่งเป็นช่องโหว่ด้านความปลอดภัยที่เห็นได้ชัด บ่อยครั้ง คำสั่ง audit2allow เป็นเพียงจุดเริ่มต้น หลังจากใช้ข้อความเหล่านี้ คุณอาจต้องเปลี่ยนโดเมนต้นทางและป้ายกำกับของเป้าหมาย รวมทั้งรวมมาโครที่เหมาะสมเพื่อให้ได้นโยบายที่ดี บางครั้งการปฏิเสธที่กำลังตรวจสอบไม่ควรส่งผลให้เกิดการเปลี่ยนแปลงนโยบายเลย ควรเปลี่ยนแอปพลิเคชันที่ละเมิด