小路的博客

Android应用沙盒机制

前言

  • Android使用沙盒来保护用户不受恶意应用的侵害，同时也将应用隔离开来，防止他们互相访问其数据，本文主要对Android应用沙盒中的几种技术做简要的总结。

一、Android应用DAC沙盒

  • 稍微了解Android一点的人都知道，Android上的App并不像Linux上的用户程序那样，启动应用的uid默认就是登录用户的uid，除非你使用sudo或者setuid等机制。而是每个Android应用都对应了一个uid，也就是一个用户，通过Linux系统的DAC机制将应用的数据严格隔离开来。
  • Android并没有使用/etc/passwd配置文件以及useradd、usermod和userdel等二进制来管理用户，这些东西对Android来说过于复杂。实际上Android应用到uid的映射是由PackageManagerService完成的，也就是PMS，并且存储在/data/system/packages.xml中。
  • 将Android应用使用DAC隔离开之后，如果应用要访问任何系统资源，便会被拒绝，所以Android设计了应用权限机制来向应用提供访问系统资源的通道，同时保护系统资源不被滥用。
  • 下面是在Pixel 2 XL (RP1A.201005.004.A1) 上面的一些例子 
    u:r:untrusted_app:s0:c161,c256,c512,c768 u0_a161 16613 887 14608676 86088 0                  0 S com.google.android.apps.photos
u:r:untrusted_app:s0:c138,c256,c512,c768 u0_a138 17204 888 1402772 138956 0                  0 S com.android.chrome
  • 可以看到相册应用的用户为u0_a161，而Chrome浏览器应用的用户为u0_a138

二、Android应用权限

  • Android应用权限的核心类型分为四种：普通权限、危险权限、签名权限、签名或系统权限
权限类型 权限行为
普通权限(Normal) 普通权限是只需要在AndroidManifest.xml中声明后就可以使用的权限
危险权限(dangerous) 危险权限除了需要在AndroidManifest.xml中声明之外，在Android 6.0或更高版本还需要使用动态权限API进行申请，并且用户点击同意之后才能使用；在Android 5.1以及更早版本，会在安装时单独列出危险权限以特别提醒用户。注意，如果自定义权限设置为了危险权限，无论Android版本是多少都只是会在安装时单独列出危险权限。
签名权限(signature) 签名权限仅会授予给与定义这个权限的包相同签名的应用。
签名或系统权限(signatureOrSystem) signature|privileged的旧同义词。签名或系统权限与签名权限唯一的区别就是，签名或系统权限也允许授予给特权应用(priv_app)。
  • 在自定义权限中，经常使用signature权限来保护敏感的接口，使其只能被可信的应用调用——那些具备和定义权限者相同签名的应用，如果使用的是signatureOrSystem，这个权限还可以被授予给特权应用。
  • 实际还有其他类型的权限，但都为非核心类型，使用的也比较少。

三、应用信息的存储

  • 应用信息的存储上文已经提到，位于/data/system/packages.xml中，这里面存储了应用的各种信息，下面是一个示例： 
    <package name="com.android.storagemanager" codePath="/system/priv-app/StorageManager" nativeLibraryPath="/system/priv-app/StorageManager/lib" publicFlags="541605445" privateFlags="8" ft="165151eba60" it="165151eba60" ut="165151eba60" version="29" userId="10036" appUseNotchMode="0" appUseSideMode="1" hwExtraFlags="0" isOrphaned="true" forceDarkMode="2">
<sigs count="1" schemeVersion="1">
    <cert index="13" />
</sigs>
<perms>
    <item name="android.permission.USE_RESERVED_DISK" granted="true" flags="0" />
    <!-- ... -->
</perms>
<proper-signing-keyset identifier="3" />
</package>
<package name="com.android.settings" codePath="/system/priv-app/Settings" nativeLibraryPath="/system/priv-app/Settings/lib" publicFlags="675823173" privateFlags="8" ft="165151eba60" it="165151eba60" ut="165151eba60" version="10010400" sharedUserId="1000" appUseNotchMode="0" appUseSideMode="1" hwExtraFlags="0" isOrphaned="true" forceDarkMode="2">
<sigs count="1" schemeVersion="1">
    <cert index="0" />
</sigs>
<perms>
    <item name="android.permission.REAL_GET_TASKS" granted="true" flags="0" />
    <!-- ... -->
</perms>
<proper-signing-keyset identifier="1" />
</package>
  • 可以看到这个文件中存储有很多内容，最关键的信息包括应用的uid、包名、各类路径，以及定义和授予的权限。
  • 例如StorageManager这个应用的uid是10036，而设置的uid是1000，也就是system的uid。

四、应用权限的映射

  • 我们知道Android使用的是Linux内核，而在Linux的安全模型中，如果需要访问系统资源，访问系统资源的用户和进程必须具备相应的权限。
  • Android如何将自行定义的Android权限映射到Linux层面的权限呢？答案就位于/etc/permissions/platform.xml中，下面是该文件的节选： 
    <permission name="android.permission.BLUETOOTH_ADMIN" >
<group gid="net_bt_admin" />
</permission>
<permission name="android.permission.BLUETOOTH" >
<group gid="net_bt" />
</permission>
  • 这里显示的就是，Android的两个蓝牙权限，分别对应了net_bt_admin和net_bt两个Linux组，在应用被授予相应的权限时，PMS会自动将应用uid加入这两个组中，这样应用就拥有了相应系统资源的访问权限了。

五、应用的SELinux标签

  • 在Android引入SELinux之后，对应用权限的划分更为细致，Android默认将应用分为四种：不可信应用、特权应用、平台应用和系统应用。
SELinux标签 标签行为
app_domain 所有应用的SELinux标签都继承于此
isolated_app 在Manifest中配置了isolatedProcess=true的服务进程，几乎没有特权，最典型的例子是WebView和浏览器的渲染进程
(ephemeral_app 所有用户使用的免安装应用都属于此标签，特权相比一般的第三方应用要少
untrusted_app_all 所有用户安装的应用都属于此标签，还包括一部分预装应用，具备较少的特权
untrusted_app_29 targetSdkVersion = 29的不可信应用
untrusted_app_27 25 < targetSdkVersion <= 28的不可信应用
untrusted_app_25 targetSdkVersion <= 25的不可信应用
priv-app 带有Privileged标记的预装应用，一般安装在/system/priv-app中，不可卸载，但不以system uid运行
platform_app 具备平台签名，但不以system uid运行的应用。除了AOSP和部分第三方ROM之外，几乎所有的OEM都不会公开其平台私钥，所以一般情况下平台应用只能是OEM提供的
system_app 既具备平台签名，又以system uid运行(配置android:sharedUserId="android.uid.system")的应用。使用system uid运行意味着它们实际不受应用沙盒的限制，并能访问绝大部分Android框架中的系统资源。
  • 下面是在Pixel 2 XL (RP1A.201005.004.A1) 上面的一些例子 
    u:r:untrusted_app:s0:c138,c256,c512,c768 u0_a138 17204 888 1375548 107564 0                  0 S com.android.chrome
u:r:priv_app:s0:c512,c768      u0_a177        5384    887 14111416 141208 0                  0 S com.google.android.apps.nexuslauncher
u:r:platform_app:s0:c512,c768  u0_a180        5130    887 14838840 173276 0                  0 S com.android.systemui
u:r:system_app:s0              system        16853    887 14090276 133588 0                  0 S com.android.settings
  • 可以得出以下结论：
    • Chrome在这台手机上是untrusted_app
    • 启动器nexuslauncher在这台手机上是priv_app
    • systemui在这台手机上是platform_app
    • 设置settings在这台手机上是system_app
  • 显然其中只有设置是以system uid运行的，其它进程使用的都是普通的应用uid。

六、Android应用MAC沙盒

  • 上面所说的SELinux标签，Android在源代码中为它们定义了不同的SELinux政策，这便实现了MAC层面的沙盒增强。这些政策的路径如下 
    system/sepolicy/public/app.te
system/sepolicy/private/app.te
system/sepolicy/private/isolated_app.te
system/sepolicy/private/ephemeral_app.te
system/sepolicy/private/untrusted_app_all.te
system/sepolicy/private/untrusted_app_29.te
system/sepolicy/private/untrusted_app_27.te
system/sepolicy/private/untrusted_app_25.te
system/sepolicy/private/priv_app.te
system/sepolicy/private/platform_app.te
system/sepolicy/private/system_app.te
  • 一般来说不建议App层面直接访问具备独立标签的用户态进程或者内核驱动，因为App的SELinux标签划分并非像UID一样细致，如果这样做会导致授予某一个应用权限的时候必须授予应用所在的整个标签权限，违反权限最小化原则。