Start from scratch-go deep into Android (practice-let's start coding-android framework learning-6. Permission (permissions ))

Chapter 1 permission (permissions)

This document describes how application developers use the security functions provided by Android. The android open source project aosp provides a general Android security overview. Android is a permission-based operating system. Each application running on Android has its own system ID (Linux User ID and group ID ). Different parts of the system have different and obvious identifiers. Therefore, each application running on Linux is independent of each other and has nothing to do with the system.

In general, the "permissions" mechanism of Android is the function that your program implements. If you do not apply for permissions, the function will run in the same way. The permissions of each application are independent.

6.1 Security Framework

The core of the android security system architecture design is that by default, no program is allowed to perform harmful operations on other programs, operating systems, or users, including reading and writing users' private data (such as contacts or emails), reading and writing files from other programs, conducting network access or waking up devices, etc. Because the Android system allows each application to run in an independent sandboxes, the application must explicitly allocate resources and data by declaring the required permissions. Android does not use a dynamic authorization mechanism that is not conducive to security. Applications statically declare the permissions they need. During installation, the android system will prompt users whether they agree to obtain these permissions. If you do not agree, do not install it. If you install it, you agree. The Dalvik virtual machine is not a secure boundary. Any application can run local code (see Android ndk ). All types of applications -- Java, native, and both -- run in sandbox in the same way and with the same level of security.

6.2 application Digital Signature

All Android applications (APK files) must have a developer with a private key to sign the certificate used to identify the application author. This certificate requires loose and does not need to be signed by a dedicated Certificate Authority. Android applications can use self-signed certificates. The android certificate aims to differentiate the author of an application, allows the operating system to grant or deny the application signature-level permissions and the operating system to grant or deny the application requests to the same Linux identity as other applications. In the debugging phase, if you compile programs on two computers, generate two identical APK files, and load the files to your mobile phone, the later one will prompt "the installation is not completed" or is illegal. This is because the signatures of the two computers are different in the mode of mode. During the official release, you can use ise ISE to formally sign the program, you only need to use the same formal signature for publishing on different computers. Of course, this is not necessary in the debugging phase.

6.3 user ID and File Access

During installation, Android assigns a different Linux User IU (UID) to each program ). The identity of the software remains unchanged during the lifecycle of the device. On different devices, the same software may have a different uid. What is important is that different packages on a given device have different UIDs. Because security is implemented at the process level, theoretically, the code of the two software packages cannot run normally in the same process at the same time. They must run with different Linux users. In fact, you can assign the same user ID to the userid attribute of the manifest tag in androidmanifest. xml of each program, and regard the two applications as the same application with the same user ID and file permissions. To ensure security, only applications with the same digital signature (the request's shareduserid is the same) will be assigned the same user ID. Any data stored by the application will be assigned to the user ID of the application and cannot be accessed by other applications normally. When getsharedpreferences (string, INT), openfileoutput (string, INT), or openorcreatedatabase (string, Int, sqlitedatabase. cursorfactory) when creating a new file, you can use the mode_world_readable or mode_world_writeable mark to allow other applications to read/write files. After these global read and write permissions are set, the file is still owned by the application that created the file, but any other application can read and write it.

6.4 permission

An android application does not have any permissions, which means it cannot perform any operations that will adversely affect the user experience or any data on the device. To use the protection function of the device, you must declare the permissions required by the application on one or more <uses-Permission> tags in the androidmanifest. xml file. For example, an application that monitors received text messages must declare the following permissions, as shown in code list 6-1:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"    package="com.android.app.myapp" >    <uses-permission android:name="android.permission.RECEIVE_SMS" />    ...</manifest>

 

Code List 6-1

When installing an application, the installer must authorize the permissions required by the application during interaction based on the Application signature. No permission check is performed when the application is running: it is either given a special permission after installation, and can use the expected permission, or it is not granted permissions, any operation that uses these permissions will automatically fail without the user prompt. Generally, if the request permission fails, the application will throw a securityexception, but there are also exceptions. For example, the sendbroadcast (intent) function checks the permissions when all data is shipped to the receiver. When the function returns, it does not check the data permissions or receive any permission exceptions. In most cases, permission exceptions are recorded in logs. All permissions provided by the Android system can be found in manifest. permission. Any application can also define and execute its own permissions,

6.5 statements and implementation Permissions

To execute your own permissions, you must first declare them using one or more <permission> labels in your androidmanifest. xml file. For example, if an application wants to control who can start an activity, it can be declared as follows, as shown in code list 6-2:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"    package="com.me.app.myapp" >    <permission android:name="com.me.app.myapp.permission.DEADLY_ACTIVITY"        android:label="@string/permlab_deadlyActivity"        android:description="@string/permdesc_deadlyActivity"        android:permissionGroup="android.permission-group.COST_MONEY"        android:protectionLevel="dangerous" />    ...</manifest>

 

Code List 6-2

<Protectionlevel> A property is required. It tells the system how to notify users or who can use this permission when other applications require this permission. The <permissiongroup> attribute is optional and is used to help the system display permissions to users. It is usually set to a standard system group in Android. manifest. permission_group, which can be customized in rare cases. It is best to give priority to existing groups to simplify the permission UI display for users. Note that these two labels and descriptions should be licensed. The details of the permission list (Android: Label) or a single permission (Android: Description) are displayed. The tag should briefly introduce key functions of permission protection. Use a few simple sentences to describe what you can do with this permission. The Convention is to use the first sentence to describe the permission and the second sentence to warn the user about what will happen after the permission is authorized.

You can also use the shell command ADB shell PM list permissions to view the permission definitions on the current system. In particular, the-s option can be displayed in a simple table. As shown in code list 6-3:

$ adb shell pm list permissions -sAll Permissions: Network communication: view Wi-Fi state, create Bluetooth connections, fullInternet access, view network state Your location: access extra location provider commands, fine (GPS) location,mock location sources for testing, coarse (network-based) location Services that cost you money: send SMS messages, directly call phone numbers ...

 

Code List 6-3

1.Execute Permission In androidmanifest. xml

High-level permissions for components that enter the system or application can be implemented in androidmanifest. xml. All of these can be used in the Android: Permission attribute. Not only can applications use permissions, but we can also set permissions for a component.

◆ The activity permission (applied to the <activity> label) is used to restrict who can start the activity. This permission is checked during running context. startactivity () and activity. startactivityforresult (). If the caller does not have the required permissions, A securityexception exception will be thrown from this call.

◆ Service permission (applied to the <service> label) is used to restrict who can start or bind the service. When you run context. startservice (), context. stopservice (), and context. bindservice (), the permission is checked. If the caller does not have the required permissions, A securityexception is thrown.

◆ Broadcastreceiver permission (applied to the <receiver ER> label) is used to limit who can send broadcasts to the relevant receiver. After context. sendbroadcast () is returned, the permission check is performed when the system sends the submitted broadcast to the corresponding receiver. In the end, a permission failure will not return an exception to the caller, but will not implement the intent. Similarly, context. registerreceiver () can also be used with its own permission to limit who can send broadcasts to a receiver registered in the program. Another way is to provide a permission to context. sendbroadcast () to restrict which broadcastreceiver can receive the broadcast.

◆ Contentprovider permission (applied to the <provider> tag) is used to restrict who can access the data provided by contentprovider. (Content providers has an additional security mechanism called URI permissions, which will be discussed later .) Unlike other components, it has two separate permission attributes. You can set: Android: readpermission to restrict who can read and Android: writepermission to restrict who can write. Note that if the provider requires both read and write permissions, data in the provider cannot be read only when the write permission is required. When you retrieve the content provider for the first time and complete related operations, the permission is checked. (If you do not have any permissions, A securityexception is thrown .) You must have the read permission to use contentresolver. Query (). Write Permission to use contentresolver. insert (), contentresolver. Update (), and contentresolver. Delete. In all these cases, a securityexception is thrown if you do not have the required permissions.

2.Send broadcast execution permission

In addition to the previously mentioned permissions (used to restrict who can send broadcasts to the corresponding broadcastreceiver), you can also specify a permission when sending broadcasts. When you call context. sendbroadcast (), use a permission string (permission string), and you can require that the received Host Program have the corresponding permissions. It is worth noting that both the receiver and broadcast can require permissions. In this case, both permission checks must pass before sending the corresponding intent to the target.

3.Execute other Permissions

You can set more detailed permissions when calling the service. This is done through the context. checkcallingpermission () method. When calling, use a desired permission string (permission string) and return an integer to the caller to determine whether the caller has the required permission. It should be noted that this situation can only happen in calls from another process, usually the IDL Interface published by a service or other methods provided to other processes. Android provides many other effective methods for checking permissions. If a PID of another process exists, you can use context. checkpermission (string, Int, INT) to check the permission settings of the process. If you have another application package name, you can use packagemanager. checkpermission (string, string) to determine whether the package has the corresponding permissions.

6.6 URI permission

The standard permission system we have discussed so far is not enough for the content provider. A content provider may want to protect its read and write permissions, and the client corresponding to it also needs to pass a specific URI to other applications for operations on this URI. A typical example is the attachment of the mail application. Permission is used to protect access to emails because these are sensitive user data. However, if a URI pointing to an Image Attachment needs to be passed to the image browser, the image browser will not have the right to access the attachment, because it cannot have the access permission for all emails. The solution to this problem is per-Uri permission: when an activity is started or a result is returned to an activity, the caller can set intent. flag_grant_read_uri_permission and/or intent. flag_grant_write_uri_permission. This grants the activity the permission to access the specified URI of the intent, regardless of whether the activity has the permission to access the content provider corresponding to the intent. This mechanism allows a common (capability-style) model for user interaction (such as opening an attachment, selecting a contact from the list) and refining permissions. This is a key step to reduce the permissions required by the application and leave only the permissions directly related to the program behavior. We strongly recommend that you implement this function in content provider and declare the support using the Android: granturipermissions or <grant-Uri-permissions> tag.

FAQ group 213821767