- 1、 DAC sandbox for Android Applications
- 2、 Android App permissions
- 3、 Storage of application information
- 4、 Mapping of application permissions
- 5、 Applied SELinux Tags
- 6、 Android App MAC sandbox
Android uses sandbox to protect users from malicious applications. At the same time, it also isolates applications to prevent them from accessing their data. This paper mainly summarizes several technologies in Android application sandbox.
1、 DAC sandbox for Android Applications
- People who know a little about Android know that apps on Android are not like user programs on Linux. The uid for starting applications is the uid of the logged in user by default, unless you use sudo or setuid mechanisms. Instead, each Android application corresponds to a uid, that is, a user, which strictly isolates the application data through the DAC mechanism of the Linux system.
- Android does not use the / etc / passwd configuration file and binaries such as useradd, usermod and userdel to manage users, which are too complex for Android. In fact, the mapping of Android application to uid is completed by packagemanagerservice, that is, PMS, and stored in / data / system / packages.xml.
- After isolating the Android application from the DAC, if the application wants to access any system resources, it will be rejected. Therefore, Android has designed an application permission mechanism to provide the application with a channel to access the system resources and protect the system resources from abuse.
- Here are some examples on 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 album application is U0_ A161, while the user of Chrome browser application is U0_ a138
2、 Android App permissions
The core types of Android application permissions are divided into four types: normal permission, dangerous permission, signature permission, signature or system permission
|Permission type||Permission behavior|
|Normal permission||Normal permissions are permissions that can be used only after they are declared in androidmanifest.xml.|
|Dangerous authority||In addition to being declared in androidmanifest.xml, the dangerous permission needs to be applied by using the dynamic permission API in Android 6.0 or later, and the user can only use it after clicking the consent; In Android 5.1 and earlier, dangerous permissions are listed separately during installation to remind users. Note that if the custom permissions are set to dangerous permissions, dangerous permissions will only be listed separately during installation regardless of the Android version.|
|Signature authority (signature)||Signing permission will only be granted to applications with the same signature as the package that defines this permission.|
|Signature or system authority (signatureorsystem)||Old synonym for signature|privileged. The only difference between signature or system permission and signature permission is that signature or system permission can also be granted to privileged applications (priv_apps). This field is now deprecated.|
In custom permissions, signature permissions are often used to protect sensitive interfaces so that they can only be called by trusted applications – those with the same signature as those who define permissions.
3、 Storage of application information
As mentioned above, the storage of application information is located in / data / system / packages.xml, which stores various application information. The following 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 key information includes the uid of the application, package name, various paths, and the permissions defined and granted.
- For example, the uid of the storagemanager application is 10036, and the set uid is 1000, that is, the uid of the system.
4、 Mapping of application permissions
- We know that Android uses the Linux kernel, and in the Linux security model, if you need to access system resources, 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 in / etc / permissions / platform.xml. The following is an excerpt of 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 net respectively_ bt_ Admin and net_ BT two Linux groups. When the application is granted corresponding permissions, PMS will automatically add the application uid to the two groups, so that the application has access to the corresponding system resources.
5、 Applied SELinux Tags
After the introduction of SELinux in Android, the division of application permissions is more detailed. Android divides applications into four types by default: untrusted applications, privileged applications, platform applications and system applications.
|SELinux label||Label behavior|
|Untrusted_app||Untrusted applications have the least privileges and access to system resources is strictly limited. All applications installed by users and some pre installed applications belong to this label.|
|Privileged application (priv APP)||The privileged application is located in the / system / priv app directory or other directories defined by the OEM. It cannot be uninstalled, but it does not run as a system uid.|
|Platform_app||The platform application has a platform signature, but does not run as a system uid. Except AOSP and some third-party ROMs, almost all OEMs will not disclose their platform private key, so generally, platform applications can only be provided by OEMs.|
|System_app||The system application has both platform signature and system uid (Android: shareduserid = “Android. Uid. System” configured). Running with system uid means that they are not limited by the application sandbox and can access most of the system resources in the Android framework.|
Here are some examples on pixel 2 XL (rp1a.201005.004. A1)
The following conclusions can be drawn:
- Chrome is untrusted on this phone_ app
- The initiator nexus launcher is priv on this phone_ app
- Systemui is platform on this phone_ app
- Setting settings is system on this phone_ app
Obviously, only the settings are run as system uid, and other processes use ordinary application uid.
6、 Android App MAC sandbox
For the SELinux tags mentioned above, Android defines different SELinux policies for them in the source code, which realizes the sandbox enhancement at the MAC level.
The above is the details of Android application sandbox mechanism. For more information about Android application sandbox mechanism, please pay attention to other relevant articles of developeppaer!