I was recently reading up about custom permission for our application in android.
uses-permission is clear. It contains the permission that your application will need in order to access some of user data or device features, etc and to function properly.
Now, we come to permission element. It declares permissions that activities or services might require other applications hold in order to use your application's data or logic
Now, say I use permission tag in my application's manifest file such as:
<permission android:name="my.pkg.CUST_PER"/>
This will imply that my application may have this possible permission.
And enforce that permission using it in my Activity tag like this:
<activity
android:name=".MyApp"
android:permission="my.pkg.CUST_PER">
Now, as per my understanding, only applications that have requested my indicated permission will be able to access my application's secured components.
If other app tries to access those components without my custom permission, what will happen? I think it should crash, and will that be seen in logcat as:
SecurityException: Missing permission: my.pkg.CUST_PER
If so, isn't that a security breach?
How to protect application data in such a circumstance?
uses-permission is clear. It contains the permission that your application will need in order to access some of user data or device features, etc and to function properly.
<uses-permission> means that your app wishes to hold the permission named in the <uses-permission> element. What is defended by that permission is up to other developers. In some cases, it may be defending some things that allow you "to access some of user data or device features".
This will imply that my application may have this possible permission.
No, it does not. It simply defines a new permission. It does not state that your app, or any other app, has anything else to do with the permission.
Now, as per my understanding, only applications that have requested my indicated permission will be able to access my application's secured components.
More accurately, only apps with the <uses-permission> element could qualify to access the secured component. In addition, as Mr. Orlowski notes, the protectionLevel of the <permission> indicates if user acceptance is involved (a protectinoLevel of normal or dangerous), if the app needs to be signed by the same signing key as the app that is defending itself with the permission (a protectionLevel of signature), or if the app needs to be installed on the /system partition (a protectionLevel of system).
If other app tries to access those components without my custom permission, what will happen? I think it should crash, and will that be seen in logcat as: Requires this permission: my.pkg.CUST_PER
Correct.
If so, isn't that a security breach?
Not particularly.
How to protect application data in such a circumstance?
Don't expose it in the first place. The complete and entire point behind having android:permission is because you want other apps to have access to the data, subject to user acceptance, signature match, etc. If you do not want other apps to have access to the data, do not export the component. For activities, services, and manifest-registered receivers, this is usually accomplished by not having an <intent-filter>. For <provider> elements, you will want to manually have the android:exported attribute set to false.
How to protect application data in such a circumstance?
You should have read whole docs as android:protectionLevel exists exactly to address this problem and is explained here:
https://developer.android.com/guide/topics/manifest/permission-element.html#plevel
Related
I develop watchfaces for WearOS. I'm trying to modularize my code, by creating a base module that contains the common code for all my projects. Amoung other things, it should contain the code responsible for the in-app purchases. For this reason, I have to add <uses-permission android:name="com.android.vending.BILLING"/>. However, some projects don't have an in-app purchase. Therefore, these projects would inherit the BILLING permission, but actually woudn't need it.
So my questions are:
Is there a way around it? Like a way to conditionally specify aspects of the Manifest?
What are the consequences if I simply let this BILLING permission in, even if it's not required?
More generally, are there more "dangerous" permissions to let in when not required?
When uploading the app, you need to complete a Permissions declaration and the app goes through review. What you're seeking to do seems to explicitly run counter to the Play Store "Permissions policy" guidelines:
You may only request permissions that are necessary to implement current features or services in your app that are promoted in your Play Store listing.
I would expect your app to fail the review in light of this (or if it did pass the first time somehow, to possibly fail future reviews if it gets caught at a later stage).
Is there a way around it? Like a way to conditionally specify aspects of the Manifest?
I think there is no way of not declaring permissions in the manifest:
What are the consequences if I simply let this BILLING permission in, even if it's not required?
If it is a install-time permission the system will grant it automatically. But if it is a runtime-permission you must request the permission at runtime before usage.
So if you declare permissions that you do not need, in best case nothing happens. But I am not that much aware what kind of security issues can arrise from doing that.
Be aware that requesting permissions that you do not need in your App is against good practice:
Caution: Carefully consider which permissions you declare in your app's manifest. Add only the permissions that your app needs. For each permission that your app requests, make sure that it offers clear benefits to the user and that the request is done in a way that's obvious to them.
See also this post
Remove Permissions
You can also consider removing permissions in your (sub)modules that you declared in your base modules:
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" tools:node="remove"/>
I am implementing runtime permissions in my app. I have few questions though to understand them clearly.
Situation:
My application B is a child app of application A
That being said my application resides inside application A as part of it and, whenever needed I can launch it.
Question:
If a user has already granted all the necessary runtime permissions to application A (the parent app), then can the child app i.e. application B carry the same permission grant or it has to ask them again?
Do I need to ask the permissions again if I install a newer version of an app on top of the old? Let's say version 2 to 3.
Technically, yes. If app-A and app-B are two separate apps, they each need their own set of permissions and permission requests.
And no, if a permission was previously allowed, then an installation of a newer version does not reset that permission's state.
However, if you want app-B to retain the same permission states as app-A, you should look into something called android:sharedUserId. If app-A has the same sharedUserId as app-B, then app-B will have the same permission states as app-A, and vice versa.
I couldn't find any posts talking sufficiently about the shared permission states between apps with the same, but you can check out some of these posts for extra notes:
Two app with shared UserID
What is sharedUserId in Android, and how is it used?
https://stackoverflow.com/a/49492023/6668797
https://stackoverflow.com/a/8507761/6668797
I did a quick test myself and can confirm that two apps with the same sharedUserId do share permission states, so go try it yourself. Just setup a sample project/app that checks and requests a permission, clone it, give them the same sharedUserId, install both of them, allow the permission on one, and you'll see it's already in the allowed-state on the other.
I have made an application say "TestApp" which contains a content provider. Content provider shares the database access to all other application. Is there a mechanism in android which allows only few other application having a particular type of permission to access content provider of "TestApp"?
I don't want applications which do not have that specific permission to access the content provider of "TestApp".
Being a newbie i don't know the standard that a question asked should have.
Please help.
You could look at providing a custom permission in your application.
Custom permission question in stackoverflow
Developer.android.com
Please be aware that this could pose a security issue to your application.
The usual way to do this is to set android:protectionLevel="signature" on your permission. This will restrict access to only applications signed with the same certificate as the application which declares the permission. These applications may declare a <uses-permission> tag to gain access.
See also the general security tips article.
That said, be careful what you protect with this. It will prevent random applications the user installs from getting access to your data, but not if the user truly wishes to bypass these protections. If the user wants to give an application the ability to circumvent this, then the user can do so. This protects only against other applications gaining access when the usual security measures are in force.
My application define a permission with android:protectionLevel="signature".
<permission android:name="my.app.permission.EXAMPLE" android:protectionLevel="signature" />
My intention is make application modules that can be launched only by my signed app. These application modules have android:permission in its activities.
This works fine. but...
A third-party app can use the same permission name and changed the protection level to normal, like this
<permission android:name="my.app.permission.EXAMPLE" android:protectionLevel="normal" />
If my app is installed first, i can prevent others apps to override the permission. However, if one uninstalls my app and then installs his app it redefines the permission.
Is it possible prevent other application use the same permission name, for example, giving the permission a unique id like application package?
Although the Manifest is encrypted, anyone can read the permission name in log cat when it tries to start the activity that requires this permission (An exception is thrown having the required permission name).
There's no enforcement, only convention. Like the rest of the Java world, it loosely relies on domain name registration infrastructure. The idea is that you prefix your permission name with your public Internet domain name (e. g. com.myawesomecompany.myapp.MYPERMISSION) which you own.
Uniqueness of domain names is enforced by the registrar community, naturally.
Yes, the system is open for abuse.
EDIT: if you're securing a broadcast-based channel, you can add a two-way signature check if you feel like it. Call Context.sendBroadcast() with the permission name as a second parameter.
EDIT2: I feel you're overthinking this while closing your eyes at the bigger Android app security picture. Which is not impressive. Abusing the privilege infrastructure is not how one hacks into an Android app. If I set out to intercept your intents, I won't be putting together a fake intent receiver (activity, service). Instead, I'd connect with a debugger to the genuine receiver in your app, signature and all.
With publicly available tools, it takes minutes to put togther an Eclipse project for a given APK. Load it up into Eclipse, connect to a running process, set breakpoints in relevant system APIs (Android is open source, remember), voila. With a bit of extra effort, you can get decompiled Java sources for an APK and debug in terms of YOUR methods, as opposed to system ones.
copyed from Google Andorid Doc:
Note: The system does not allow multiple packages to declare a permission with the same name, unless all the packages are signed with the same certificate. If a package declares a permission, the system does not permit the user to install other packages with the same permission name, unless those packages are signed with the same certificate as the first package. To avoid naming collisions, we recommend using reverse-domain-style naming for custom permissions, for example com.example.myapp.ENGAGE_HYPERSPACE.
https://developer.android.com/guide/topics/permissions/defining
If you want to prevent other applications from changing your permission level, you can use system predefine permissions which have level "signature". No other regular app can define permission before system.
Use system permission to protect your resource doesn't mean your app have to sign with platform key.
example:
<service
android:name="xxx.xxx.xxx.exservice"
android:permission="android.permission.BROADCAST_PACKAGE_REMOVED" >
The only issue is AppStore would show which permission you use if below code shows in app's manifest.xml
<uses-permission android:name="android.permission.BROADCAST_PACKAGE_REMOVED" />
In this example, you can access you resource by the same sign key, but definitely you can't broadcast package remove.
I was under the impressions that two apps were sandboxed and unable to call each other (by intents or contentresolver etc) unless the callee declared and enforced specific permissions and the caller used appropriate uses-permission elements? However, I have developed two apps, one containing a content provider, and another with activities that use the content provider. Neither have permissions declared enforced or used. I deploy them directly from Eclipse to my phone and they are able to use each other.
I have checked that they really are running as separate processes and user ids, and they are. Why am I not seeing security exceptions? Should Linux underneath, by default, stop this communication? They will be signed by the default DEBUG certificate. Does this give them more rights to "talk" to each other, i.e. if I signed with an explicit certificate would the sandboxing kick in?
As soon as I declare and enforce a permission in the content provider app the other app does need the uses-permission to allow communication.
Cheers
Yes, if your apps have the same signature, then they have access to each other. It's similar to package level permissions in java.
http://developer.android.com/guide/topics/security/security.html