Android Permissions Problem analysis

Android system is running on the Linux kernel, Android and Linux have their own set of strict security and authority mechanism,

A lot of newbies like me, especially those accustomed to Windows low security restrictions, are easily confused in this respect, here is what I summarize about the Android system permissions related content,

As this period of time on the Android permission to learn the summary, but also hope to be helpful to everyone, the incorrect point please indicate.

First distinguish between two concepts:

To differentiate between the permissions that are owned by the APK runtime and the permissions that are accessed on the file system (read and write execution), the two concepts.

APK program is run on the virtual machine, corresponding to the unique Android permissions mechanism, only to reflect the file system on the use of Linux permissions settings.

(i) Permissions on the Linux file system

-rwxr-x--x System System 4156 2010-04-30 16:13 test.apk

Represents the appropriate user/user group and other people's access to this file, which is completely unrelated to the permissions that the file has to run.

For example, the above example can only show that the system user has read and write permissions to the file, the system group's users have read and execute permissions on the file, and others have only execute permissions on the file.

And what test.apk can do when it runs up is irrelevant.

Do not look at the APK file system belonging to the System/system users and user groups, or root/root users and user groups, it is assumed that the APK has system or root permissions.

(ii) Android's permission rules

(1) The APK in Android must be signed

This signature is not based on an authoritative certificate, and does not determine whether an app is allowed to install, but a self-signed certificate.

It is important that the permissions on the Android system are based on signatures. For example: The system level of permissions have a specific signature, the signature is not correct, the permissions will not be obtained.

The default generated APK file is the debug signature.

The signature used to get the system permissions, see: How to get the Android app permissions

(2) UserID-based process-level security mechanisms

As we all know, the process has a separate address space, the process and process between the default is not mutual access, is a very reliable protection mechanism.

Android is implemented by assigning a unique Linux userid to each package installed on the device (APK), with the name "App_" plus a number, such as app_43

Different userid, running in different processes, so the apk between the default can not access each other.

Android offers one of the following mechanisms that allows two apk to break the aforementioned barrier.

Using the Shareduserid attribute in Androidmanifest.xml to assign the same userid to different packages, by doing so, the two package can be used as the same program,

The system assigns the same userid to two programs. Of course, for security reasons, two of the package needs to have the same signature, otherwise there's no point in verifying it.

(Add this: not that the same userid is assigned, the two programs run in the same process, the following are extracted by the PS command,

Obviously, the system, app_2 respectively corresponding to the two process PID are different, I do not know how the Android is how to implement its mechanism.

User PID PPID

System 953 883 ffffffff afe0cbcc S system_server

App_2 1072 883 ffffffff afe0dcc4 S Com.android.inputmethod.

System 1083 883 ffffffff afe0dcc4 S Android.process.omsservi

App_2 1088 883 ffffffff afe0dcc4 S Android.process.acore

(3) The default APK generated data is not visible to outsiders

By doing this, Android assigns the program's userid to the data stored by the program.

With Linux's strict access to the file system, there is no mechanism for the APK to have access to each other like data.

Example: A file created by my app with the default permissions as follows, you can see that only a program with UserID App_21 is able to read and write to the file.

-RW-------app_21 app_21 2000-01-01 09:48 test.txt

How to open?

<1> use mode_world_readable and/or mode_world_writeable markers.

When creating a new file with Getsharedpreferences (string, int), Openfileoutput (string, int), or openorcreatedatabase (Str ing, int, sqlitedatabase.cursorfactory), you can use the mode_world_readable and/or mode_world_writeable Y other package to read/write the file. When setting these flags, the file was still owned by your application and its global read and/or write permissions had B Een set appropriately so any other application can see it.

(4) explicit permission declaration in Androidmanifest.xml

The Android default app does not have any permissions to manipulate other apps or system-related features, and the app needs to explicitly apply the appropriate permissions when doing certain things.

The following actions are generally required to apply the appropriate permissions:

A particular permission is enforced at a number of the places during your program ' s operation:

When the app is installed, package installer detects the permissions requested by the app, depending on the app's signature or prompting the user to assign the appropriate permissions.

The permission is not detected during the run of the program. If permission acquisition fails during installation, execution will go wrong and the user will not be prompted for insufficient permissions.

In most cases, a failure caused by insufficient permissions will cause a SecurityException to be logged 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 complete something that it does not have permission to complete, unfortunately, this method is not feasible.

As mentioned earlier, Android permissions are operating at the process level, that is, an APK app starts the child process permissions can not exceed its parent process permissions (that is, the rights of the APK),

Even if running an app alone has permission to do something, if it is called by an APK, then the permissions will be limited.

In fact, Android implements this mechanism by assigning the userid of the parent process to the child process.

(iii) Analysis of the problem of common authority insufficiency

The first thing to know is that the normal APK program is run on a non-root, non-system level, that is, to see the permissions of the file to be accessed, looking at the last three bits.

In addition, the permissions of the APK installed through System/app are generally higher than the permissions of the APK installed directly or adb install.

To get to the problem, running an Android application is not a sufficient privilege to run, generally in two situations:

(1) Log can clearly see the prompt for insufficient permissions.

This situation is generally missing the appropriate permission settings in the Androidmanifest.xml, well find a list of permissions, should be resolved, is the most easy to handle the situation.

Sometimes the permissions are added, but still reported insufficient authority, what is the situation?

The Android system has some APIs and permissions that require the APK to have a certain level to run.

such as Systemclock.setcurrenttimemillis () modify the system time, write_secure_settings permissions seem to need to have system-level permissions.

This means that the UserID is System.

(2) Log does not report the lack of authority, but some other exception hints, this may also be due to insufficient permissions.

For example: We often want to read/write a configuration file or some other files that are not created by ourselves, often reported java.io.FileNotFoundException errors.

The system thinks that the more important file general permission settings will be more stringent, especially some very important (configuration) files or directories.

Such as

-R--R-----Bluetooth bluetooth 935 2010-07-09 20:21 dbus.conf

Drwxrwx--x System system 2010-07-07 02:05 data

Dbus.conf seems to be the configuration file of Bluetooth, from the rights point of view, it is impossible to change, non-Bluetooth users even read the right to not.

/data directory is stored in the private data of all programs, by default, Android does not allow the normal apk to access the contents of the/data directory, the permissions set through the data directory, other users do not have Read permissions.

So the ADB normal permissions under the data directory to knock the LS command, you will get Opendir failed, Permission denied error, through the code file.listfiles () can not get the contents of the data directory.

The above two cases, generally need to elevate the APK permissions, the APK can be elevated to the right is the system in the Android API provides the Systemclock.setcurrenttimemillis () function to modify the systems time, Unfortunately no matter how you call this function is useless, regardless of the emulator or the real machine, in the Logcat will always get "unable to open alarm driver:permission denied". This function requires root privileges or runs and system processes.

Originally thought there is no way in the application of this layer to change the system time, and later on the internet search for a long, know that the purpose can still be achieved.

The first method is simple, but it needs to be compiled with make in the context of the Android system source code:

1. Add the android:shareduserid= "Android.uid.system" attribute to the manifest node in the application's androidmanifest.xml.

2. Modify the Android.mk file, add local_certificate: = Platform this line

3. Using the MM command to compile, the generated apk will have the ability to modify the system time.

The second method is troublesome, but do not need to open the virtual machine to the source environment with make to compile:

1. Ibid., add the android:shareduserid= "Android.uid.system" attribute.

2. Use eclipse to compile the apk file, but this apk file is not available.

3. Open the APK file with the compression software, delete the cert.sf and cert.rsa two files in the Meta-inf directory.

4. Use the target system's platform key to re-sign the apk file. This step is more troublesome, first find the key file, the location in my Android source directory is "Build\target\product\security", below the Platform.pk8 and Platform.x509.pem two files. Then use Android to provide the signapk tool to sign, signapk source code is under "build\tools\signapk", the use of "signapk Platform.x509.pem platform.pk8 input.apk output.apk ", the file name is best to use absolute path to prevent not found, you can also modify the source code to use directly.

This way the last apk is the same as the first one.

Finally explain the principle, first add android:shareduserid= "Android.uid.system" this attribute. With the shared user ID, multiple apk with the same user ID can be configured to run in the same process. Then the UID of the program into a android.uid.system, that is, to let the program run in the system process, so that there is permission to modify the system time.

Just adding UID is not enough, if you install the APK at this time found unable to install, prompt signature does not match, because the program wants to run in the system process and the target system platform key, The second method mentioned above is the PLATFORM.PK8 and Platform.x509.pem two files. Using these two keys to sign the APK before it can actually be put into the system process. The first method adds Local_certificate: = Platform is actually signed with these two keys.

There is also a problem, that is, the generated programs can only be used in the original Android system or in their own compiled system, because such a system can get platform.pk8 and Platform.x509.pem two files. If the other company does not have the Android installed on the installation. Try the original Android key to sign, the program runs OK on the emulator, but put on the G3 to install the direct prompt "package ... has no signatures that match those in shared user Android.uid. System ", which also protects the security of the systems.

Last but not least, this Android:shareduserid property can not only put the APK into the system process, you can also configure multiple apk running in a process, so that the data can be shared, it should be useful. Blogger Supplement:

SIGNAPK after compilation is finished in Android directory/out/host/linux-x86/framework/signapk.jar

How to use: Java-jar signapk.jar platform.x509.pem platform.pk8 test.apk test_signed.apk

Practice proves that the second method does not need to delete the Meta-inf directory of CERT.SF and cert.rsa two files, direct signapk can.

Write an android application that uses root permissions this is how to perform the use of the SU command