本文基于Android 10的Sepolicy进行分析。
在热更新或者减少安装包的大小实践中,可以看到普通APP可以在安装以后下载共享库文件,也就是.so文件,然后进行动态加载动作。
同样的,如果是一个system app,想要执行类似地加载动态库的动作为什么会不行?
首先你需要知道的是:如果APP要加载一个so库,必须拥有该库文件标签的execute权限。
1. 普通APP的私有数据区的数据标签为app_data_file,而在selinux的源码中,可以找到如下策略:
#Some apps ship with shared libraries and binaries that they write out to their sandbox directory and then execute.
allow untrusted_app_all privapp_data_file:file { r_file_perms execute };
allow untrusted_app_all app_data_file:file { r_file_perms execute };
auditallow untrusted_app_all app_data_file:file execute;
根据上述的策略和描述可以看出,允许普通的APP对私有数据的数据拥有execute权限。并且auditallow将在APP执行(execute)一个app_data_file时记录日志。
2. 我们再看system APP的数据标签为system_data_app_file:
# /data/data subdirectory for system UID apps.
type system_app_data_file, file_type, data_file_type, core_data_file_type, mlstrustedobject;
system_data_app_file和data_file_type属性关联,而后者和system APP之间有如下限制:
# Blacklist app domains not allowed to execute from /data
neverallow {
bluetooth
isolated_app
nfc
radio
shared_relro
system_app
} {
data_file_type
-dalvikcache_data_file
-system_data_file # shared libs in apks
-apk_data_file
}:file no_x_file_perms;
可以看出,system APP无法获取data_file_type的execute权限。 这也就是为什么system APP无法动态加载共享库。
思考:
正如最前面的注释,既然google考虑到普通APP需要在自己的存储区动态加载共享库,那拥有更高权限的system APP反而被加以限制?难道厂商的system APP就不能通过动态加载动态库来修正问题吗?不知道google是处于何种安全考虑。有想法的可以留言讨论。