How to Restrict Content Provider Data Across Applications

How to restrict content provider data across applications

The easiest way is to protect the content provider with a permission you define. Make it a signature a permission so only apps signed with your certificate are allowed to get it.

See:

http://developer.android.com/guide/topics/security/security.html

http://developer.android.com/reference/android/R.styleable.html#AndroidManifestProvider

http://developer.android.com/guide/topics/manifest/provider-element.html

If doing this based on certificates is not sufficient, you will need to write the permission checks yourself. This is done by calling Binder.getCallingUid() for incoming calls to your applications, and deciding whether the given uid has permission to access your provider. Actually implementing a different policy that is actually secure requires a lot of careful thought and design, though.

Restrict access to content provider

Define a permission like below with protectionLevel signature, this WRITE permission will restricted to only apps which are signed with same private key

<permission android:name="com.yourapp.WRITE.PERMISSION"
    android:protectionLevel="signature"
        android:label="@string/permission_label"
        android:description="@string/permission_desc">
</permission>

<permission android:name="com.yourapp.READ.PERMISSION"
        android:label="@string/permission_label"
        android:description="@string/permission_desc">
</permission>

Then in contentprovider tag use read and write permission tags.
You can either enforce read permission or you could altogether remove it

android:readPermission="com.yourapp.READ.PERMISSION"
android:writePermission="com.yourapp.WRITE.PERMISSION"

So only apps that are signed by same signature can use your content provider

Edit:

Maybe you could use this

 private Collection<String> getCallingPackages() {
     int caller = Binder.getCallingUid();
     if (caller == 0) {
         return null;
     }
     return Lists.newArrayList(mContext.getPackageManager().getPackagesForUid(caller));
 }

And check if your packagename is present in this list. I think it is safe

Android Content Providers - Is it possible to restrict the provider to a set of applications not written by me?

I do not know precisely but I think that you can use Binder.getCallingUid() function in your ContentProvider. Using this method you can check the Uids of the calling applications and restrict the usage of your CP basing on application UID.

Update: During the installation Android OS assigns UID to the installing application. So UIDs can be different on different devices. But the package name of the application is the same across all devices. But if I know which package can read your data I can simply spoof it.

How do I restrict access to my ContentProvider to only my apps?

If I use an android:permission attribute, can't 3rd party apps just apply that permission to their app?

Well, you can use a signature-level custom permission (android:protectionLevel="signature"). Then, the app holding the permission and the app defending itself with the permission have to be signed by the same signing key.

There's a bug/limitation in Android that can allow an attacker, installed before your app, to hold this permission even though the attacker is not signed by your signing key. I go into that in more detail in this report (as it's a bit complex for an SO answer) and have a PermissionUtils class to help you detect that case.

Content Provider vs SharedUserId vs Global Process for sharing data across applications

I found three ways to share data across applications.

#2 and #3 are the same, insofar as #3 (shared process) requires #2 (sharedUserId).

You also missed all other forms of standard Android IPC, including:

• starting activities
• starting services
• binding to services
• sending broadcasts

I am confused what to use when

Ordinary app developers should use #1 (ContentProvider) or one of the other standard Android IPC mechanisms that I outlined above. You have no control over when users update apps, and using formal IPC enforces a clear separation between the apps, forcing you to think through things like API contracts, API versioning, and related concerns.

sharedUserId and shared processes are really there for device manufacturers, where apps are pre-installed and then updated in unison via a firmware update. Personally, I recommend to device manufacturers that they too use standard IPC, for most scenarios. For example, if App A modifies App B's files directly, how does App B find out? What if App B then overwrites App A's changes, because App B did not know about those changes? In many other areas of computer programming, we have gotten away from having multiple processes from multiple apps work with each others files directly.

which is more efficient?

Efficiency should not be an issue in this case, as you should be using any of these techniques infrequently. If you have two apps that need to communicate with each other frequently, then you really have one app, and you should implement it that way.

Apply access restriction on Content Provider

Is there any way to implement local search without content provider?

Don't integrate with the search framework. There is nothing stopping you from having your own separate search mechanism within your app (e.g., an activity that is opened from a Search menu item).

OR is is possible to apply restriction so that except my own app no other app can use my
content provider?

Your app isn't the one using the content provider -- the operating system is the one using the content provider. That's why trying to apply this sort of security is tricky. C2DM uses some related techniques, and it is possible that the core Android team will apply the same techniques to the search integration in the future, but I wouldn't hold my breath.

In the interim, either sanitize your search suggestions such that they are safe for publishing through a regular content provider, or implement your own search activity.

Protect/restrict content provider in android

Add android:exported="false" to the <provider> element in the manifest.

---

Related Topics