Programmatically alter Manifest - Android custom p

Question

The current Android Permission System causes the following issue:

App A defines the custom permission of:

com.package.permission.READ_APP_DATA

When app B is installed declaring the custom permission, it is granted.

However, if app A is installed after app B, then the permission is not granted to app B.

Whilst this may not be a common occurrence, due to app B often being a plugin of app A, it of course can occur and does for my application.

With SuperUser applications agreeing to introduce the global custom permission of android.permission.ACCESS_SUPERUSER this may well be a big problem should a user decide to switch SuperUser app.

In order to handle the issue, I intend to use the following code in my application for the custom permission I am about to start declaring:

checkPermissions(this, getCallingActivity().getPackageName()); // get the package name from the sender first

private boolean checkPermissions(Context context, String callingPackage) {

    final List<PackageInfo> apps = context.getPackageManager().getInstalledPackages(PackageManager.GET_PERMISSIONS);

    for (PackageInfo pi : apps) {

        if (pi.packageName.equals(callingPackage)) {

            String[] permissions = pi.requestedPermissions;

            if (permissions != null) {
                for (String permission : permissions) {
                    if (permission.equals("com.package.permission.READ_APP_DATA")) {
                        return true;
                    }
                }
            }
        }
    }
    return false;

As per the title of this question: Is this method 'safe'? Or is there a way/root-hack that an application's manifest could be altered after it is installed and the permission programmatically 'added' to app B?

Answer 1

I'm not sure if I'm getting the question right, as I don't know how hacking a permission into the manifest after install connects to the code you posted above. But to answer your last paragraph:

Not in an easy way. The user has to have a mod installed on his device, that can grant arbitrary permissions on the fly while the app is requesting them. IIRC the manifest file itself is parsed just at install time.

So what we used in a mod is altering the method grantPermissionsLPw in class com.android.server.pm.PackageManagerService.

It is used to grant a launcher the permission android.permission.EXPAND_STATUS_BAR, which it didn't declare in its manifest.

I am not sure though, if this would ever be used for your app. But to sum it up: If the user wants to grant an app an arbitray, custom permission: Yes, it is possible.

UPDATE

I can elaborate a bit more, of course. I can see two scenarios happening

1. Static mod

The above mentioned class resides in services.jar. As we know, files like this can be decompiled, altered, and recompiled. Actually, it's a fairly easy edit on this file. I don't know about a way to do this on the phone directly, but I would consider it possible. It's just not that feasible, that widespread solutions are available, as it needs a good amount of processing power. An attacker can't just supply an universal file. These files change from device to device, and also between firmware versions. Either, the attacker would need to supply a huge amount of patched files, or do the patching live, by uploading it to a server, patch it, redownload and install it. This scenario is not very likely if you ask me.

2. dynamic mod

There are more than one frameworks available, that allow altering processes while they opertae. The most popular of them is the Xposed Framework. Basically, it is a patched app_process and a corresponding API that leverages Reflection to alter running processes. Now an attacker can ship his app with this framework, and having root access, install it silently. With root access, he can even enable the module by himself, which normally requires user interaction. Once a module like that is enabled, the attacker can hook into the above mentioned method and alter the requested permissions. He would be doing this by getting the object field, which holds the requested permissions, add the one he requires, THEN run the original method, which adds the originally defined permissions.

Please note that both scenarios require the user to install the malicious app himself. You didn't mention what your app is for, so I can't really help you more with evaluating the risk. All I can say is, that an attacker CAN do things like that.

Answer 2

I do see an issue where if App A is installed before App B and the <permission> element isn't declared in App A, the user will never see the permission request. If you do require the use of the <permission> element in App A, though, a similar approach could be used to verify that the label and description shown to the user were accurate.