Tổng quan
- Android 5 mặc định áp dụng enforcing mode cho “mọi thứ” –> nghiêm ngặt hơn KK 4.4 –> mọi access operation phải được cho phép rõ ràng
- VD: Terminal Emulator (được xếp vào loại untrusted_app –> app của bên thứ 3, ko phải trong platform) chạy trên KK có thể list các file, thư muc, link trong thư mục /dev bằng lệnh $ ls /dev nhưng trên Android L lại bị báo “opendir failed, Permission denied“
- Xác thực thông qua logcat hoặc dmesg hoặc proc/kmsg vs grep avc (nhận được các denial)
- VD dưới là 1 denial nhận được từ logcat khi một untrusted_app đang cố gắng đọc char dev file có tên “CnlFitCtrl0”
- { read } –> access operation
- scontext=u:r:untrusted_app:s0 –> subject context thuộc kiểu untrusted_app
- tcontext=u:object_r:device:s0 –> target context thuộc kiểu device
- tclass=chr_file –> đối tượng của access operation thuộc lớp char dev file
- Các tcontext trong hệ thống có thể được liệt kê ra dùng lệnh $ ls -Z
- Các scontext có thể được liệt kê dùng lệnh $ ps -Z
W/Thread-284( 3514): type=1400 audit(0.0:12): avc: denied { read } for name="CnlFitCtrl0" dev="tmpfs" ino=11516 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:device:s0 tclass=chr_file
- Có thể sử dụng tool audit2allow để dịch ngược các denial thành các policy statement (rule)
- Có 2 mode (tương ứng 2 option có thể đưa vào cmdline thông qua thuộc tính androidboot.selinux):
- permissive mode –> ko enforce + báo log
- enforcing mode –> enforce + báo log
- 1 option nữa có thể đưa vào cmdline là disabled –> khả năng là ko enforce + ko báo log
- Cú pháp của 1 “allow” policy statement:
allow <domains> <types>:<classes> <permissions>
- Sử dụng {} trong trường hợp <domains> & <permissions> có nhiều thành phần
- Các <classes> & danh sách các <permissions> tương ứng được define trong external/sepolicy/access_vectors
- AOSP define các type, attribute, macro, .v.v. & các policy source trong external/sepolicy
- attributes
- global_macros
- device.te
- untrusted_app.te
- file_contexts
- .v.v.
- Device-specific policy source được đặt trong device/<vendor>/…/sepolicy
- Sau khi build system image, các AOSP policy & device-specific policy được merge vs nhau & được build thành một số file trong out/…/product/<device>/root (cùng thư mục vs các file *.rc, file thực thi init, charger, .v.v.) & được đóng gói trong ramdisk.img –> mà ramdisk.img lại nằm trong boot.img –> do vậy, thực tế để update SE policy & test nhanh trên device, chỉ cần build riêng & nạp lại boot image là đủ
- …
[Ref]
<?> Cơ chế nào giúp 1 app thứ 3 như KingRoot vẫn có thể root đc 1 thiết bị Android chạy Android 5.0 ???
(% 