为何Android普通APP可以执行私有数据中的so文件，而system app却不可以？

本文基于Android 10的Sepolicy进行分析。

在热更新或者减少安装包的大小实践中，可以看到普通APP可以在安装以后下载共享库文件，也就是.so文件，然后进行动态加载动作。

同样的，如果是一个system app，想要执行类似地加载动态库的动作为什么会不行？

首先你需要知道的是：如果APP要加载一个so库，必须拥有该库文件标签的execute权限。

1. 普通APP的私有数据区的数据标签为app_data_file，而在selinu的源码中，可以找到如下策略：

#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 /dataneverallow {  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是处于何种安全考虑。有想法的还原留言讨论。

思考：

更多相关文章

随机推荐