[AOSP] Tạo thư mục device mới của vendor

  • Test trên HLOS01010 (Lollipop 5.0)

[11:22 PM]datvtb@datvtb ~/WORKING/hlos01010_server_TEST
$ source build/envsetup.sh
including device/samsung/manta/vendorsetup.sh
including device/XXX/YYY/vendorsetup.sh
including device/vutuda/pentagon/vendorsetup.sh
including device/asus/deb/vendorsetup.sh
including device/asus/flo/vendorsetup.sh
...

[11:22 PM]datvtb@datvtb ~/WORKING/hlos01010_server_TEST
$ lunch

You're building on Linux

Lunch menu... pick a combo:
1. aosp_arm-eng
2. aosp_arm64-eng
3. aosp_mips-eng
4. aosp_mips64-eng
5. aosp_x86-eng
6. aosp_x86_64-eng
7. aosp_manta-userdebug
8. YYY-userdebug
9. pentagon-userdebug
10. aosp_deb-userdebug
11. aosp_flo-userdebug
...
23. msm8226-userdebug
24. aosp_shamu-userdebug
25. aosp_hammerhead-userdebug
26. aosp_mako-userdebug

Which would you like? [aosp_arm-eng] 9

============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=5.0
TARGET_PRODUCT=pentagon
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=krait
TARGET_2ND_ARCH=
TARGET_2ND_ARCH_VARIANT=
TARGET_2ND_CPU_VARIANT=
HOST_ARCH=x86_64
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.11.0-15-generic-x86_64-with-Ubuntu-12.04-precise
HOST_BUILD_TYPE=release
BUILD_ID=LRX21M
OUT_DIR=out
============================================

 

[Android] SELinux

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 cmdlinedisabled –> 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 initcharger, .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 ???