Of Stack

Explain the sandbox mechanism of Android application in detail

  • 2021-12-12 09:43:55
  • OfStack
Preface to the table of contents 1. Android applies DAC sandbox 2. Android application permissions 3. Storage of application information 4. Apply the mapping of permissions 5. Applied SELinux tags 6. Android applies MAC sandbox

Preface

Android uses sandbox to protect users from malicious applications, and also isolates applications to prevent them from accessing their data. This paper mainly summarizes several technologies in Android application sandbox.

1. Android application DAC sandbox

Anyone who knows a little about Android1 knows that App on Android is not like the user program on Linux, and uid for starting the application is uid for logging in to the user by default, unless you use sudo or setuid and other mechanisms. Instead, each Android application corresponds to one uid, that is, one user, and the application data is strictly isolated through the DAC mechanism of Linux system. Android does not use the/etc/passwd configuration file and binary systems such as useradd, usermod, and userdel to manage users, which are too complicated for Android. Actually, the mapping of Android to uid is done by PackageManagerService, that is, PMS, and stored in/data/system/packages. xml. After the Android application is isolated by DAC, if the application wants to access any system resources, it will be rejected. Therefore, Android designs an application permission mechanism to provide the application with access to system resources and protect the system resources from abuse. Here are some examples above 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

You can see that the user of the photo album application is u0_a161, and the user of the Chrome browser application is u0_a138

2. Android application permissions

There are four core types of Android application permissions: normal permissions, dangerous permissions, signed permissions, and signed or system permissions

权限类型 权限行为
普通权限(Normal) 普通权限是只需要在AndroidManifest.xml中声明后就可以使用的权限。
危险权限(dangerous) 危险权限除了需要在AndroidManifest.xml中声明之外，在Android 6.0或更高版本还需要使用动态权限API进行申请，并且用户点击同意之后才能使用；在Android 5.1以及更早版本，会在安装时单独列出危险权限以特别提醒用户。注意，如果自定义权限设置为了危险权限，无论Android版本是多少都只是会在安装时单独列出危险权限。
签名权限(signature) 签名权限仅会授予给与定义这个权限的包相同签名的应用。
签名或系统权限(signatureOrSystem) signature|privileged的旧同义词。签名或系统权限与签名权限唯1的区别就是，签名或系统权限也允许授予给特权应用（priv_app），该字段现已弃用。

In custom permissions, signature permissions are often used to protect sensitive interfaces so that they can only be invoked by trusted applications--those that have the same signature as the one defining the permissions.

3. Storage of application information

The storage of application information, mentioned above, is located at/data/system/packages. xml, which stores all kinds of application information. Here is an example: 


<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" user 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" sharedUser 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>
You can see that there are many contents stored in this file. The most critical information includes the uid of the application, the package name, various paths, and the defined and granted permissions. For example, the uid of StorageManager is 10036, while the set uid is 1000, which is uid of system.

4. Apply the mapping of permissions

We know that Android uses the Linux kernel, and in the security model of Linux, if you need to access system resources, the users and processes accessing system resources must have corresponding permissions. How does Android map self-defined Android permissions to Linux level permissions? The answer is located at/etc/permissions/platform. xml, and the following is an excerpt from the file: 

<permission name="android.permission.BLUETOOTH_ADMIN" >
    <group g />
</permission>
<permission name="android.permission.BLUETOOTH" >
    <group g />
</permission>

What is shown here is that the two Bluetooth permissions of Android correspond to two Linux groups, net_bt_admin and net_E120EN. When the application is granted the corresponding permissions, PMS will automatically add the application uid to these two groups, so that the application has the access rights of the corresponding system resources.

5. Applied SELinux tags

After the introduction of SELinux into Android, the division of application rights is more detailed. By default, Android divides applications into four types: untrusted applications, privileged applications, platform applications and system applications.

SELinux标签 标签行为
不可信应用(untrusted_app) 不可信应用拥有最少的特权，访问系统资源受到严格限制，所有用户安装的应用以及部分预装应用都属于此标签。
特权应用(priv-app) 特权应用位于/system/priv-app目录或OEM定义的其它目录下，不可卸载，但不以system uid运行。
平台应用(platform_app) 平台应用具备平台签名，但不以system uid运行。除了AOSP和部分第3方ROM之外，几乎所有的OEM都不会公开其平台私钥，所以1般情况下平台应用只能是OEM提供的。
系统应用(system_app) 系统应用既具备平台签名，又以system uid运行(配置android:sharedUserId=”android.uid.system”)。使用system uid运行意味着它们可以不受应用沙盒的限制，并能访问绝大部分Android框架中的系统资源。

Here are some examples above Pixel 2 XL (RP1A. 201005. 004. A1)

The following conclusions can be drawn:

Chrome on this phone is untrusted_app The starter nexuslauncher is priv_app on this phone systemui on this phone is platform_app Set settings to system_app on this phone

Obviously, only the setup runs as system uid, and other processes use the common application uid.

6. Android Application MAC Sandbox

For the SELinux tags mentioned above, Android defines different SELinux policies in the source code, which implements sandbox enhancement at MAC level.

The above is a detailed explanation of Android application sandbox mechanism details, more information about Android application sandbox mechanism please pay attention to other related articles on this site!

Related articles: