android io模型_基本的Android安全模型-CSDN博客

android io模型

Security is always one of the most essential criterions that has been focused on in Android OS from its ground up until the latest updated versions. In this article, we will discover a couple of models that define how Android behaves.

安全性一直是Android OS从底层到最新更新版本一直关注的最重要标准之一。在本文中，我们将发现几个定义Android行为的模型。

Before diving into the detail, it is worth noting that Android platform makes use of Linux, so its features are often based on the principles of Linux.

在深入探讨细节之前，值得注意的是Android平台使用Linux，因此其功能通常基于Linux原理。

1.应用程序沙箱 (1. Application Sandbox)

The foundation of the Android application security model is that no two applications running on the same device should be able to access each other’s data without authorization.

Android应用程序安全模型的基础是，在同一设备上运行的两个应用程序都不能未经授权访问彼此的数据。

They should not affect the operation of other applications, either. These are the concepts of an Application Sandbox. It takes advantages of Linux user-based protection to isolate resources for each application and assign a unique user identifier (UID). That means each application will be running under its own user and its own virtual machine (VM), Dalvik or ART, so each process executes independently from one another. However, do not mistake the above concept with a virtual machine (in term of virtualization) like VirtualBox or VMWare on which one can run a malware without harming remaining parts of the system. It is simply a game of permission. From Linux viewpoint, a user can only access or execute data whose it has the permission, the behavior in Android stays the same except the fact that each application is now associated to a unique user. An app owns its private data directory that is protected by the system of permission and can only be accessible from the application owner. An exception where two apps can be processed under the same user and share the same VM is when they use a shareUserId tag which is declared in AndroidManifest.xml:

它们也不应该影响其他应用程序的运行。这些是“ 应用程序沙箱”的概念。它利用基于Linux用户的保护功能来隔离每个应用程序的资源并分配唯一的用户标识符 (UID)。这意味着每个应用程序都将在其自己的用户和自己的虚拟机 (VM)(Dalvik或ART)下运行，因此每个进程都彼此独立地执行。但是，不要将上述概念与VirtualBox或VMWare之类的虚拟机(在虚拟化方面)相 混淆，在其中可以运行恶意软件而不会损害系统的其余部分。这只是一个许可游戏。从Linux的角度来看，用户只能访问或执行获得许可的数据，Android中的行为保持不变，除了每个应用程序现在都与唯一用户相关联的事实。应用拥有自己的私有数据目录，该目录受许可系统保护，并且只能从应用所有者访问。当两个应用程序使用在AndroidManifest.xml中声明的shareUserId标记时，可以在同一用户下处理两个应用程序并共享相同VM的情况是一个例外：

android:shareUserId="com.modulotech.example"

With this tag, two or more applications will be sharing the same UID, accessing the each other’s data, holding the same set of permissions, and if desired, running the same process. However, the feature is deprecated in API 29 and higher because of non-deterministic behavior within the package manager.

使用此标记，两个或多个应用程序将共享相同的UID，访问彼此的数据，持有相同的权限集，并且如果需要，运行相同的进程。但是，由于包管理器中的不确定行为，API 29及更高版本中不推荐使用该功能。

活页夹 (Binder)

There are still cases where processes would like to communicate with each other. That is the moment when Binder plays its role.

在某些情况下，进程仍希望彼此通信。那是活页夹发挥作用的时刻。

Binder is the Android-specific Inter Process Communication (IPC), also an Inter Components Communication. All applications have access to the Binder and are able to communicate with it. Parcels are sent from apps to the Binder and passed to Activity Manager to check whether the calling application has permissions to perform the request. Unlike Java, Android does not have an entry point like function main() , but every component could be one if they are declared to be exposed. A particular entry point within an application is invoked through Binder — which, of course, requires an appropriate permission the achieve the request.

活页夹是特定于Android的进程间通信 (IPC)，也是组件间通信 。所有应用程序都可以访问Binder并能够与其通信。包裹从应用程序发送到活页夹，然后传递到活动管理器，以检查调用应用程序是否具有执行请求的权限。与Java不同，Android没有像main()函数那样的入口点，但是如果声明将其公开，则每个组件都可以是一个。通过Binder调用应用程序中的特定入口点-当然，要获得请求，它需要适当的权限。

2.应用程序签名 (2. Application Signing)

Application Signing helps to identify the author of an application and to update the application without any complex permission. It also represents a degree of trust in other aspects of the security model. The signing of a package is done cryptographically using a certificate whose key is hold by application developers (nowadays the key may also be stored on Play Store utilising Play App Signing’s feature). The signing of a package is mandatory even if the application running is in debug mode. In that case, the application will be signed, silently by Android Studio or intentionally by command line, with the default debug certificate which is only valid during development.

应用程序签名有助于识别应用程序的作者并在没有任何复杂权限的情况下更新应用程序。它还代表了对安全模型其他方面的信任程度。软件包的签名使用证书由密码完成，该证书的密钥由应用程序开发人员持有(如今，密钥也可以使用Play App Signing的功能存储在Play商店中)。即使运行的应用程序处于调试模式，也必须对软件包进行签名。在这种情况下，将使用默认调试证书对应用程序进行签名，而默认调试证书仅在开发期间有效，该应用程序将由Android Studio静默签名或通过命令行有意签名。

The idea of the Android Application Signing model is to prevent an application from being maliciously manipulated. Once application codes are decompiled and then modified, the certificate will no longer be valid.

Android应用程序签名模型的思想是防止恶意操作应用程序。一旦对应用程序代码进行反编译然后进行修改，证书将不再有效。

Application signing is also the first step to place the application in its Application Sandbox. Signed certificate defines the UID that the application will be assigned. That is why, as mentioned in the Application Sandbox session, two or more applications that share the same UID through shareUserId tag must be signed by the same certificate.

应用程序签名也是将应用程序放置在其应用程序沙箱中的第一步。签名证书定义了将分配应用程序的UID。这就是为什么，如“ 应用程序沙箱”会话中所述，必须通过同一证书对两个或多个通过shareUserId标记共享同一UID的应用程序进行签名。

Note that you can sign two or more applications, which do not share the same UID, with the same certificate. However, they will be running under different users and VMs.

请注意，您可以使用相同的证书签署两个或多个不共享相同UID的应用程序。但是，它们将在不同的用户和VM下运行。

When you try to install/update an application with a non-identical certificate, you will get an error:

当您尝试使用不相同的证书安装/更新应用程序时，将收到错误消息：

adb: failed to install release_app.apk: Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.modulo.example signatures do not match previously installed version; ignoring!]

To sign an open/unsigned apk, you can use some built-in tools in JDK or SDK. Feel free to read my article on how can we achieve that.

要对打开/未签名的apk进行签名，可以使用JDK或SDK中的某些内置工具。随意阅读我的文章，了解如何实现这一目标。

3.申请许可。 (3. Application Permission.)

Note that this is not the same permission in user-based Linux as we have been discussing earlier.

请注意，这与我们之前讨论的基于用户的Linux中的权限不同。

With the characteristics of an Operating System for mobile device, Android controls certain types of information and resources which are often seen as sensitive such as: SMS message, contact, telephone, location, camera etc. Thus, granting access to these pieces of info to the right applications having the correct demand is one of the goals of Android Security Models. That is why Application Permissions is created.

凭借适用于移动设备的操作系统的特点，Android控制了通常被视为敏感的某些类型的信息和资源，例如：SMS消息，联系人，电话，位置，摄像头等。因此，将访问这些信息的权限授予具有正确需求的正确应用程序是Android安全模型的目标之一。这就是创建应用程序权限的原因。

As Android OS is not able to detect whether an application is eligible to use a resource; what it does is to deactivate all the accesses and only grant permissions when apps request (for the minor permissions) or user accepts (for the major permissions). In that way, Android ensures that only resources permitted are exposed to the applications permitted.

由于Android操作系统无法检测应用程序是否有资格使用资源；它的作用是停用所有访问权限，仅在应用程序请求(次要权限)或用户接受(主要权限)时授予权限。这样，Android可以确保仅将允许的资源公开给允许的应用程序。

Before installing an application from Play Store, you can preview the requested permissions for the app by clicking “Permission detail”.

在Play商店中安装应用程序之前，您可以通过单击“权限详细信息”预览该应用程序请求的权限。

Request permissions of an application are previewed on Play Store

As Android developers, we should be quite familiar with this feature.

作为Android开发人员，我们应该非常熟悉此功能。

Typically, permission preferences are stored by Activity Package Manager in different files such as: /data/system/packages.list, /data/system/packages.xml, /data/system/users/0/runtime-permissions.xml. These files are not accessible on non-rooted devices. However, there are some special permissions that rely on Linux kernel. When an application requests these permissions, its UID will be added to a Linux group id (GID). For instance, requesting android.permission.INTERNET puts the application into the inet group. The permission <-> GID mapping can be found at /system/etc/permissions/platform.xml (similarly to the above files, this one is only accessible to rooted device or an emulator).

通常，权限首选项由活动包管理器存储在不同的文件中，例如： /data/system/packages.list、/data/system/packages.xml，/ data / system / users / 0 / runtime-permissions.xml。 这些文件在非root用户的设备上不可访问。但是，有些依赖Linux内核的特殊权限。当应用程序请求这些权限时，其UID将添加到Linux组ID(GID)。例如，请求android.permission.INTERNET会将应用程序放入inet组。许可<-> GID映射可以在/system/etc/permissions/platform.xml中找到 (类似于以上文件，只有root用户的设备或仿真器才能访问此文件)。

防护等级 (Protection levels)

Each permission is associated to a protection level. According to the official documentation, there are three levels of protection that affect third-party applications: normal, signature, and dangerous. As you can notice, they are the levels assigned to the permissions which can be granted to third-party applications. In fact, by taking a look at class PermissionInfo in Android source code, we can see that there are in total six protection levels: PROTECTION_NORMAL (normal), PROTECTION_DANGEROUS(dangerous), PROTECTION_SIGNATURE(signature), PROTECTION_SIGNATURE_OR_SYSTEM(signatureOrSystem), PROTECTION_FLAG_SYSTEM(system), PROTECTION_FLAG_DEVELOPMENT(development).

每个权限都与保护级别相关联。根据官方文档，存在影响第三方应用程序的三级保护： 正常，签名和危险。 如您所见，它们是分配给可以授予第三方应用程序权限的级别。实际上，通过查看Android源代码中的PermissionInfo类，我们可以看到总共有六个保护级别：PROTECTION_NORMAL( 常规 )，PROTECTION_DANGEROUS( 危险 )，PROTECTION_SIGNATURE( 签名 )，PROTECTION_SIGNATURE_OR_SYSTEM( signatureOrSystem )，PROTECTION_FLAG_SYSTEM( 系统 )，PROTECTION_FLAG_DEVELOPMENT( 开发 )。

However, as Android developers, we should only care about the three levels mentioned in the official documentation. The most important one is dangerous level because it often requests sensitive data, so the application must prompt user to grant permission at runtime. The permissions associated to this level are also called Runtime Permissions.

但是，作为Android开发人员，我们应该只关心官方文档中提到的三个级别。最重要的级别是危险级别，因为它通常会请求敏感数据，因此应用程序必须提示用户在运行时授予权限。与此级别相关的权限也称为“运行时权限”。

4.数据加密 (4. Data encryption)

Encryption is the process of encoding all user data on an Android device using symmetric encryption keys. Once a device is encrypted, all user-created data is automatically encrypted before committing it to disk and all reads automatically decrypt data before returning it to the calling process.

加密是使用对称加密密钥在Android设备上对所有用户数据进行编码的过程。加密设备后，所有 用户创建的数据都将被自动加密，然后再将其提交到磁盘；所有读取的数据将被自动解密，然后再将其返回到调用过程。

The purpose of data encryption is to protect all user data (only the data in /data partition is encrypted) when the OS suspects that the phone might be out of user’s control. More accurately, data encryption will be triggered when the phone is powered off and then decrypted when user reboots the device and unlocks screen with PIN/password/pattern. That is why Android users often see a small lagging when the device has been rebooted.

数据加密的目的是当操作系统怀疑手机可能不受用户控制时，保护所有用户数据(仅/ data分区中的数据被加密)。更准确地说，数据加密将在手机关机时触发，然后在用户重新启动设备并使用PIN /密码/模式解锁屏幕时解密。因此，重启设备后，Android用户通常会看到一小段滞后现象。

I am not an expert on cryptography so I will not explain how Android encrypts data. I am simply introducing the basic idea of this model.

我不是密码学专家，因此不会解释Android如何加密数据。我只是在介绍此模型的基本思想。

Android has two methods for device encryption: Full-disk encryption(FDE) and File-based encryption(FBE).

Android有两种设备加密方法： 全盘加密 (FDE)和基于文件的加密(FBE)。

全盘加密 (Full-disk encryption)

FDE was introduced in Android 4.4 but only became stable from Android 5.0 onwards and has been in use up to Android 9.0. It is no longer allowed in Android 10 and higher.

FDE是在Android 4.4中引入的，但从Android 5.0起才稳定，直到Android 9.0为止一直在使用。 Android 10及更高版本不再允许使用此功能。

FDE uses a master key, which is randomly generated upon first boot, to encrypt the whole user’s data. This master key is also encrypted using user PIN/password/pattern. Thus, when user changes this PIN/password/pattern, only the master key is re-encrypted, not the whole data.

FDE使用主密钥(该密钥在首次启动时会随机生成)来加密整个用户的数据。该主密钥也使用用户PIN /密码/模式进行加密。因此，当用户更改此PIN /密码/模式时，仅主密钥被重新加密，而不是整个数据。

基于文件的加密 (File-based encryption)

FBE is supported from Android 7.0 and later. For Android 10 and higher, FBE is required.

Android 7.0及更高版本支持FBE。对于Android 10及更高版本，需要FBE。

The difference between FBE and FDE is that FBE provides an encryption using different keys on different files. It means that theses files will be decrypted independently. It avoids a situation where someone somehow has a “universal” key and uses it to open all data.

FBE和FDE之间的区别在于FBE使用不同文件上的不同密钥来提供加密。这意味着这些文件将被独立解密。它避免了有人以某种方式拥有“通用”密钥并使用它来打开所有数据的情况。

To know if your device supports FDE or FBE, you can execute the following command (assuming that you already activate the developer mode in your phone and SDK is available in your workstation):

要知道您的设备是否支持FDE或FBE，可以执行以下命令(假设您已经在电话中激活了开发人员模式，并且工作站中提供了SDK)：