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

你可能感兴趣的:(Android,Sepolicy,android,selinux,安全)