背景
Android 8.1 中引入了 Project Treble 架構,用於將 vendor 下的驅動和 Android system 系統分開,Android system 可以單獨升級。SELinux 同樣分成了兩部分,位於 /system/etc/selinux 下的 platform 部分和位於 /vendor/etc/selinux 下的 vendor 部分。本文分析 Android 大版本升級過程中對 property 增加的一些限制,以及如何繞過這些限制。
Coredomain
哪些是 coredomain?
Coredomain 是 attribute,屬於 domain (針對進程)或者 type(針對對象,如文件等)的集合。coremain 可以理解爲包含 system 下可執行文件和 apps 所運行的 domain 或者說包含所有屬於 Android 的 domain。
如何查看?
代碼中查看
有兩種定義方式:
1. type XXX ..., coredomain ...;
2. typeattribute XXX coredomain;
上面兩種方式都是將 XXX 放入到 coredomain 集合中,即 XXX 是屬於 coredomain,對 coredomain 配置的權限也會同步給 XXX,同樣對 coredomain 的限制也會限制 XXX。
工具查看
Android system/sepolicy 源碼下有 sepolicy-analyze 工具,然後需要編譯好的 sepolicy 文件,使用下面命令可以查看 coredomain 都包含那些 domain:
sepolicy-analyze 編譯好的sepolicy attribute coredomain
{:.warning}
編譯好的policy,手機上可以從這兩個地方取:1. /vendor(或者odm)/etc/selinux/precompiled_sepolicy; 2. /sys/fs/selinux/policy
Android P
新增限制
升級 Android P 後發現 property 新增了一個 neverallow(neverallow 用於限制配置,明確指定不能幹什麼)。來看下該 neverallow:
#https://cs.android.com/android/platform/superproject/+/android-9.0.0_r11:system/sepolicy/public/property.te;l=314
compatible_property_only(`
# Neverallow coredomain to set vendor properties
neverallow {
coredomain
-init
-system_writes_vendor_properties_violators
} {
property_type
-apexd_prop
-audio_prop
-bluetooth_a2dp_offload_prop
-bluetooth_audio_hal_prop
-bluetooth_prop
-bootloader_boot_reason_prop
-boottime_prop
-bpf_progs_loaded_prop
-config_prop
-cppreopt_prop
-ctl_adbd_prop
-ctl_bootanim_prop
-ctl_bugreport_prop
-ctl_console_prop
-ctl_default_prop
-ctl_dumpstate_prop
-ctl_fuse_prop
-ctl_gsid_prop
-ctl_interface_restart_prop
-ctl_interface_start_prop
-ctl_interface_stop_prop
-ctl_mdnsd_prop
-ctl_restart_prop
-ctl_rildaemon_prop
-ctl_sigstop_prop
-ctl_start_prop
-ctl_stop_prop
-dalvik_prop
-debug_prop
-debuggerd_prop
-default_prop
-device_logging_prop
-dhcp_prop
-dumpstate_options_prop
-dumpstate_prop
-exported2_config_prop
-exported2_default_prop
-exported2_radio_prop
-exported2_system_prop
-exported2_vold_prop
-exported3_default_prop
-exported3_radio_prop
-exported3_system_prop
-exported_bluetooth_prop
-exported_config_prop
-exported_dalvik_prop
-exported_default_prop
-exported_dumpstate_prop
-exported_ffs_prop
-exported_fingerprint_prop
-exported_overlay_prop
-exported_pm_prop
-exported_radio_prop
-exported_secure_prop
-exported_system_prop
-exported_system_radio_prop
-exported_vold_prop
-exported_wifi_prop
-extended_core_property_type
-ffs_prop
-fingerprint_prop
-firstboot_prop
-device_config_activity_manager_native_boot_prop
-device_config_reset_performed_prop
-device_config_boot_count_prop
-device_config_input_native_boot_prop
-device_config_netd_native_prop
-device_config_runtime_native_boot_prop
-device_config_runtime_native_prop
-device_config_media_native_prop
-dynamic_system_prop
-gsid_prop
-heapprofd_enabled_prop
-heapprofd_prop
-hwservicemanager_prop
-last_boot_reason_prop
-system_lmk_prop
-log_prop
-log_tag_prop
-logd_prop
-logpersistd_logging_prop
-lowpan_prop
-lpdumpd_prop
-mmc_prop
-net_dns_prop
-net_radio_prop
-netd_stable_secret_prop
-nfc_prop
-overlay_prop
-pan_result_prop
-persist_debug_prop
-persistent_properties_ready_prop
-pm_prop
-powerctl_prop
-radio_prop
-restorecon_prop
-safemode_prop
-serialno_prop
-shell_prop
-system_boot_reason_prop
-system_prop
-system_radio_prop
-system_trace_prop
-test_boot_reason_prop
-test_harness_prop
-theme_prop
-time_prop
-traced_enabled_prop
-traced_lazy_prop
-vendor_default_prop
-vendor_security_patch_level_prop
-vold_prop
-wifi_log_prop
-wifi_prop
}:property_service set;
')
可以看到限制的是除了 init 和 system_writes_vendor_properties_violators 的 coredomain, 這些 domains 不能設置上述白名單之外的 property type, 這些屬於AOSP 定義的 types,所以是限制 system domains 不能設置 vendor properties,符合 Prject Treble 設計思想。
如何繞過限制?
由於廠商基本都會:
- 定義新的 property type,用於細粒度控制訪問權限,如 platform_app 或者 system_app 設置新的property,三方 app 可以讀;
- coredomain 需要設置 vendor properties。
但現在增加了 neverallow 限制,這些規則在編譯階段就會報錯,所以需要想辦法繞過限制。
從上面可以看到限制會排除 init 和 system_writes_vendor_properties_violators,init 是 domain,不能滿足要求,我們是需要 platform_app 或者 system_app 有權限。看下 system_writes_vendor_properties_violators 的定義:
# All system domains which violate the requirement of not writing vendor
# properties.
# TODO(b/78598545): Remove this once there are no violations
attribute system_writes_vendor_properties_violators;
首先是 attribute,不是具體的 type, 並且從註釋上看到,表示 system domains 違反去寫 vendor properties 的集合。這個也是 google 用於在升級中故意新增的,用於臨時繞過 neverallow 限制。所以,我們可以需要違反 neverallow 的添加上該 attribute。
解決方案爲: 爲需要違反的 domain 添加 system_writes_vendor_properties_violators。
如要給 platform_app 添加,配置下面規則:
typeattribute platform_app system_writes_vendor_properties_violators;
Android Q
新增限制
google 在 GTS 中新增了一條測試 case:
com.google.android.security.gts.SELinuxHostTest#testNoExemptionsForCoreWritingVendorSysprops
SELinuxHostTest 是在 GTS GtsSecurityHostTestCases.jar 中,使用 JD-GUI 反編譯找到 testNoExemptionsForCoreWritingVendorSysprops 方法:
public void testNoExemptionsForCoreWritingVendorSysprops() {
if (this.mFirstApiLevel < 29) { // 使用 firstApi 排除升級的老機型
return;
}
// 是獲取有 attribute 是 system_writes_vendor_properties_violators 的 domain
Set<String> types = sepolicyAnalyzeGetTypesAssociatedWithAttribute("system_writes_vendor_properties_violators");
if (!types.isEmpty()) {
List<String> sortedTypes = new ArrayList<String>(types);
Collections.sort(sortedTypes);
fail("Policy exempts core domains from ban on writing vendor system properties: " + sortedTypes); // 不爲空,則測試失敗
}
}
}
從上面看到: 1)針對的是 Q 新機型; 2)若指定有 system_writes_vendor_properties_violators 的則失敗,即不能爲 domain 指定 system_writes_vendor_properties_violators。
所有針對 Q 新機型,不能採用 P 繞過方式。
如何繞過限制?
使用現有的 AOSP property type
Neverallow 不能從 domain 進行繞過,只能選擇從 property type,即不能定義新的 property,只能使用現有的。這樣有兩個弊端:
- 不能對權限細粒度控制,只能在現有權限的基礎上增加,而不能減少,這樣修改的話勢必導致權限擴大;
- type 名字選擇都是有意義,但現在只能從權限和名字上找到平衡,可能權限滿足,但名字意義差太遠。
那有沒有更好的方式?
定義新的 property type
通過對 neverallow 中的每個 type 分析,發現 extended_core_property_type 是 attribute,而不是具體的 type:
# All properties that are not specific to device but are added from
# outside of AOSP. (e.g. OEM-specific properties)
# These properties are not accessible from device-specific domains
attribute extended_core_property_type;
從註釋可以看到,這個 attribute 是 google 專門給廠商保留的,太好了。 但是 “These properties are not accessible from device-specific domains” 表示 device-specific domains 不能訪問,來看下是怎麼限制的:
# Prevent properties from being read
neverallow {
domain
-coredomain
-appdomain
-vendor_init
} {
core_property_type
extended_core_property_type # it
exported_dalvik_prop
exported_ffs_prop
exported_system_radio_prop
exported2_config_prop
exported2_system_prop
exported2_vold_prop
exported3_default_prop
exported3_system_prop
-debug_prop
-logd_prop
-nfc_prop
-powerctl_prop
-radio_prop
}:file no_rw_file_perms;
可以看到除了 coredomain, appdomain, vendor_init 外都不能訪問,那這種方式定義的 property 只能由 coredomain, appdomain 和 vendor_init 來訪問。雖然有限制,但是已經能滿足大部分需求,如上面提到的規則: platform_app 或者 system_app 設置,三方 apps 去讀。
解決方案:爲新定義的 property type 指定 extended_core_property_type。
{:.warning}
這種方式 vendor domain沒有權限去讀寫。
思考
如果有需求是需要 coredomain 和 vendor domain 同時有讀寫權限,那怎麼辦?
目前來看,新建 property type不能滿足需求,現有 AOSP 存在的 property type 如果沒有限制,也儘量不要使用,防止以後有變動,建議:
1. 業務邏輯上重新設計,儘量避免這種情況出現;
2. 使用 init 或者 vendor_init 代替設置,init 和 vendor_init 權限較高,並且限制較少,如對 init script 中配置自動 setprop 規則。
end
關注公衆號,瞭解更多信息!