Android permission Acquisition Mechanism and FAQs

The Android system runs on the Linux kernel. Android and Linux have their own strict security and permission mechanisms,
Many new users like me, especially those who are used to low security restrictions on Windows, are easily confused in this regard. The following is my summary about permissions related to the Android system,
As a summary of the permission learning for Android during this period, I hope it will be helpful to you. If this is incorrect, please point it out.

First, we should clarify two concepts:
YesAPK running permissionAndPermission to be accessed (read/write execution) on the file systemTwo concepts.
The APK program runs on a virtual machine and corresponds to the unique permission mechanism of Android. It uses Linux permission settings only when it is embodied in the file system.

(1) Linux File System Permissions
-Rwxr-X -- X system 4156 2010-04-30 16:13 test.apk
It indicates the access permissions of the corresponding user/user group and others to the file, and the permissions for running the file are completely irrelevant.
For example, the preceding example only shows that the System user has the permission to read and write the file, the system group user has the permission to read and execute the file, and other users only have the permission to execute the file.
Test.apk is irrelevant to what can be done after it is run.
Do not check that the APK file system belongs to system/system users and user groups, or root/root users and user groups. In this case, the APK has system or root permissions.

(2) Permission rules for Android

(1) The APK in Android must be signed.
This signature is not based on an authoritative certificate. It does not determine whether an application allows installation, but is a self-signed certificate.
It is important that the permissions of the Android system are signature-based. For example, if the system-level permission has a specific signature and the signature is incorrect, the permission cannot be obtained.

The default APK file is signed by debug.
For details about the signatures used when obtaining system permissions, see how to grant system permissions to Android applications.

(2) process-level security mechanism based on userid
As we all know, a process has an independent address space, and the process and process cannot access each other by default. It is a reliable protection mechanism.
Android assigns a unique Linux userid for each package (APK) installed on the device. The name is "app _" and a number is added, for example, app_43.
Different userids run in different processes, so the APK cannot access each other by default.

Android provides the following mechanism to break the barriers mentioned above.
In androidmanifest. XML, the shareduserid attribute is used to allocate the same userid to different packages. In this way, two packages can be treated as the same program,
The system will assign the same userid to the two programs. Of course, based on security considerations, the two packages must have the same signature, otherwise it makes no sense to do so without verification.

(Add one point here: it does not mean that the same userid is assigned, and the two programs run in the same process. The following command is extracted from the ps command,
Obviously, the PID of the two processes corresponding to system and app_2 is different. I don't know how Android implements its mechanism)

User PID ppid
System 953 883 187340 55052 ffffffff afe0cbcc s system_server
App_2 1072 883 100264 19564 ffffffff afe0dcc4 s com. Android. inputmethod.
System 1083 883 111808 23192 ffffffff afe0dcc4 s Android. process. omsservi
App_2 1088 883 156464 45720 ffffffff afe0dcc4 s Android. process. acore

(3) The data generated by the default APK is invisible to the outside world.
The implementation method is: Android will allocate the userid of the program for the data stored in the program.
By virtue of Linux's strict File System Access Permissions, the mechanism that APK cannot access each other seems to have data.
For example, the default permission for a file created by my application is as follows. You can see that only programs with userid app_21 can read and write the file.
-RW ------- app_21 app_21 87650 2000-01-01 09:48 test.txt

How can we open it to the outside world?
<1> use the mode_world_readable and/or mode_world_writeable flag.
When creating a new file with getsharedpreferences (string, INT), openfileoutput (string, INT), or openorcreatedatabase (string, Int, sqlitedatabase. cursorfactory), you can use the mode_world_readable and/or mode_world_writeable flags to allow any other package to read/write the file. when setting these flags, the file is still owned by your application, but its global read and/or write permissions have been set appropriately so any other application can see it.

(4) explicit permission declaration in androidmanifest. xml
Android applications do not have any permissions to operate other applications or system-related features by default. Applications must explicitly apply for corresponding permissions when performing certain operations.
You must apply for the following permissions:

A participating permission may be enforced at a number of places during your program's operation:

• At the time of a call into the system, to prevent an application from executing certain functions.
• When starting an activity, to prevent applications from launching activities of other applications.
• Both sending and broadcasting ing broadcasts, to control who can receive your broadcast or who can send a broadcast to you.
• When accessing and operating on a content provider.
• Binding or starting a service.

During application installation, the package installer detects the application request permissions and assigns the corresponding permissions based on the Application signature or prompts the user.
Permissions are not checked during the program running. If the permission fails to be obtained during installation, the execution will fail, and the insufficient user permissions will not be prompted.
In most cases, failure due to insufficient permissions will cause a securityexception, which will have related records in the system log.

(5) Permission Inheritance/userid inheritance
When we encounter an APK with insufficient permissions, we sometimes consider writing a Linux program, and then the APK calls it to do something that it has no permissions to do. Unfortunately, this method does not work.
As mentioned above, Android permissions are run at the process level. That is to say, the permissions of a sub-process started by an APK application cannot exceed the permissions of its parent process (that is, the permissions of the APK ),
Even if an application runs independently and has the permission to do something, if it is called by an APK, the permission will be limited.
In fact, Android implements this mechanism by assigning the userid of the parent process to the child process.

(3) Analysis of Common insufficient Permissions

First, you must know that the common APK program runs at a non-root or system level. That is to say, when you view the permission of the file to be accessed, you can view the last three digits.
In addition, the permission for APK installed through system/APP is generally higher than that for APK installed directly or ADB install.

To put it bluntly, when running an Android Application, you may encounter insufficient permissions. Generally, there are two scenarios:
(1) the error message about insufficient permissions is displayed in the log.
In this case, androidmanifest. XML does not have the corresponding permission settings. It is the easiest to handle this problem to find the permission list.

Sometimes the permission is added, but the permission is still insufficient. What is the situation?
The Android system requires a certain level of APK to run APIs and permissions.
For example, if systemclock. setcurrenttimemillis () is used to modify the system time, the write_secure_settings permission seems to require system-level permissions.
That is to say, userid is system.

(2) logs do not report insufficient permissions, but some other exception prompts, which may also be caused by insufficient permissions.
For example, if you want to read/write a configuration file or other files that are not created by yourself, the Java. Io. filenotfoundexception error is often reported.
Generally, files that are considered important have strict permission settings, especially important (configuration) files or directories.
For example
-R -- r ----- Bluetooth 935 2010-07-09. conf
Drwxrwx -- X system 2010-07-07 data

The metadata. conf file seems to be a Bluetooth configuration file. In terms of permissions, it cannot be changed at all. Non-Bluetooth users do not have the right to read the file.

The/data directory stores private data of all programs. By default, Android does not allow normal APK access to the/data directory. You can see through the permission settings of the data directory, other users do not have the read permission.
Therefore, if you press the LS command in the data directory under the general permission of ADB, you will get the opendir failed and permission denied errors. You cannot get the content in the data directory through the code file. listfiles.

In the above two cases, you generally need to upgrade the APK permission.

 

 

Systemclock is provided in the android API. setcurrenttimemillis () function to modify the system time. Unfortunately, no matter how you call this function, it is useless. No matter whether it is a simulator or a real machine, you will always get "unable to open alarm driver" in logcat: permission denied ". this function can be used only after the root permission or running and system processes. I thought there was no way to change the system at the application layer for a long time. Later I searched the internet for a long time and knew that this goal could still be achieved. The first method is simple, but it needs to be compiled using make in the environment of the Android system source code: 1. Add the Android: shareduserid = "android. uid. System" attribute to the manifest node in androidmanifest. xml of the application. 2. Modify the Android. mk file and add local_certificate: = platform. 3. Use the MM command to compile the generated APK and you will have the permission to modify the system time. The second method is troublesome, but you do not need to run the virtual machine to the source code environment and use make to compile it: 1. Similarly, add the Android: shareduserid = "android. uid. System" attribute. 2. Compile the APK file using eclipse, but this APK file cannot be used. 3. Open the APK file with the compression software, and delete the CERT. SF and cert. RSA files under the META-INF directory. 4. Use the platform key of the target system to re-sign the APK file. This step is troublesome. First, find the key file. The location in my android source code directory is "build/target/product/security", and the following two files are platform. pk8 and platform. x509.pem. Then, use the signapk tool provided by Android to sign it. The source code of signapk is under "build/tools/signapk" and its usage is "signapk platform. x509.pem platform. pk8 input.apk output.apk ", it is best to use an absolute path for the file name to prevent it from being found. You can also modify the source code to use it directly. In this way, the final APK is the same as the first method. The following explains the principle. First, add the Android: shareduserid = "android. uid. System" attribute. With the shared user ID, multiple APK with the same user ID can be configured to run in the same process. Then, assign the UID of the program to Android. uid. system, that is, to allow the program to run in the system process, so that you have the permission to modify the system time. It is not enough to add the UID. If the APK cannot be installed at this time, the system prompts that the signature is inconsistent because the program wants to run in the system process and the platform key of the target system is required, the platform mentioned in the second method above. pk8 and platform. x509.pem files. The APK can be put into the system process only after the two keys are signed. Adding local_certificate: = platform to the first method is actually using the two keys for signature. There is also a problem, that is, the program generated in this way can only be used in the original Android system or a self-compiled system, because such a system can get the platform. pk8 and platform. x509.pem files. If other companies do not even install Android. Try the original Android key for signature. The program runs OK on the simulator, but the prompt "package... has no signatures that match those in shared user android. UID. system ", which also protects the system security. Finally, the Android: shareduserid attribute can not only put the apk in the system process, but also configure multiple APK to run in one process to share data, it should be very useful. Added by the blogger: After signapk compilation is complete, in the android directory/out/host/linux-x86/framework/signapk. Jar Usage: Java-jar signapk. Jar platform. x509.pem platform. pk8 test.apk test_signed.apk Practice has proved that the second method does not need to delete the CERT. SF and cert. RSA files under the META-INF directory, just signapk.   Write an Android Application with the root permission. How does one execute the su command? public static boolean runRootCommand(String command) { Process process = null; DataOutputStream os = null; try { process = Runtime.getRuntime().exec("su"); os = new DataOutputStream(process.getOutputStream()); os.writeBytes(command+"/n"); os.writeBytes("exit/n"); os.flush(); process.waitFor(); } catch (Exception e) { Log.d("*** DEBUG ***", "Unexpected error - Here is what I know: "+e.getMessage()); return false; } finally { try { if (os != null) { os.close(); } process.destroy(); } catch (Exception e) { // nothing } } return true; }}