I'd like to grant Android permissions (e.g. android.permission.DELETE_PACKAGES, which has protectionLevel=system|signature) to apps signed by a given signature and/or with a given package name from SELinux policies, but so far I haven't found a way that works. The mac_permissions.xml file used to accept an allow-permission tag that accepted Android permission strings, but based on the Lollipop code that parses it, that tag doesn't seem to be supported anymore. I tried using it anyway, and it definitely seemed to be ignored by the system.
Ideally, I'd only have to add/modify SELinux policy files as opposed to core AndroidManifest files that declare the restricted permissions and specify their protection levels. Assume that apps with the given signature/package wouldn't otherwise be granted said permissions by PackageManager because they lack any of the special privileges that Android permission protection levels recognize (signed by platform cert, installed in /system, etc.), and that the permission is a system permission (i.e. declared by the frameworks/base/core/res AndroidManifest) that is declared at OS build time.
Is there a way to allow a given app signature/package to use a given Android permission from SELinux?
All the MMAC work was abandoned by the SE for Android project as none of it was accepted upstream. Currently, there is no supported mechanism for associating package permissions to SE Linux policy. If your building Android, one could restore that work in their tree, the branches to start with are the seandroid branches here: https://bitbucket.org/seandroid/frameworks-base/branches/
However, the most up-to-date branches with the code are over a year old. So you may have porting issues.
Also, that code uses the mac_permissions.xml file for controlling access, but the EOPS, extended operations changes would also be of use, you can read up about it in its config file:
https://bitbucket.org/seandroid/external-sepolicy/src/ccb97c52cda2bac69c0499b3c76bc8e0d28d636c/eops.xml?at=seandroid-5.1.1&fileviewer=file-view-default
Bear in mind, the install time permission checks and the eops changes, while providing a form of mandatory access controls, don't really use core SE Linux technologies. By that, it can be used with or without an selnux enabled kernel.
If one really wanted to couple SE Linux to permission strings, it would require significant effort to label the permissions, and have Package Manager Service (PMS) and Activity Manager Service (AMS) compute whether or not access is allowed.
However, now that per-application android permission controls are available, most of the work is no longer needed.
Related
I am getting very conflicting information regarding the use of android.permission.READ_LOGS Android permission. Firstly, the Android Documentation website does not specify the protection level of this permission. It is neither classified as normal, nor dangerous. They do specify the following:
"Not for use by third-party applications, because Log entries can
contain the user's private information."
Some websites say not to use it for the same privacy concerns.
However I have some issue with that:
When I tested this permission in my app on Android 7.1.1 (Nexus 5X) and Android 4.4.2 (old Samsung 8" tablet), neither of them prompted me that the app required this permission. Both said that the app requested "no special permissions". This only happens if the permission is deemed "normal", in which case it is automatically granted.
Secondly, using this permission, I can only view logs from logcat pertaining to my app, which does not log any personal information. Hence, I don't violate any privacy either. I thought this permission may allow me to see other app's logs, causing privacy issues.
So, if this is the case, then is it deemed safe to use this permission in a production version of the app? It would help me a lot in debugging strange bugs users face if they can send me a logcat by the press of a button.
EDIT: Ok, now I am quite confused. It appears that I don't need to explicitly specify this permission in the manifest either.
Is READ_LOGS a normal or dangerous Android permission?
Neither. As of Android 7.1, it is signature|privileged|development. That basically means that apps signed as part of the firmware build or installed on the privileged partition can hold the permission, but nothing else can.
the Android Documentation website does not specify the protection level of this permission
Correct. READ_LOGS is still in the SDK, for backwards-compatibility reasons, but ordinary apps have not been able to hold it since Android 4.1, which came out five years ago.
This only happens if the permission is deemed "normal", in which case it is automatically granted.
No.
I thought this permission may allow me to see other app's logs, causing privacy issues.
It did, on Android 4.0 and earlier.
then is it deemed safe to use this permission in a production version of the app?
Well, bear in mind that there has never been a documented and supported way for apps to access LogCat contents. Most likely, you're using one of the script-kiddie solutions that have been posted, such as running the logcat command and capturing its output. So, it is entirely possible that there are devices, now or in the future, that will not support your particular approach towards accessing LogCat. So, the permission is not your problem; the lack of a supported API for LogCat access is your problem.
Personally, I'd use a logging library to log the content to both a file and to LogCat, using the file for whatever your app needs it for.
I have been trying to get an app install on my phone. Its compatibility page http://www.goqii.com/devices.html doesn't specify my phone.
I wanted to know how this compatibility is locked to specific phones.
Trying to reverse engineer the apk (using simple apktool), I thought about modifying the minimum/target sdk versions. These two strings show that the apk is already above the Android version on device (4.2.2 or 19)
android:minSdkVersion="12"
android:targetSdkVersion="14"
As this isn't the problem, I am thinking about how to make it work. Any ideas if this compatibility is set elsewhere? I don't see any hardware differences between the compatible phones and mine (a chinese make called Gionee).
I think you should look into uses-feature tag in the manifest. If you go through the doc:
The purpose of a declaration is to inform any external entity of the set of hardware and software features on which your application depends. The element offers a required attribute that lets you specify whether your application requires and cannot function without the declared feature, or whether it prefers to have the feature but can function without it.
So it could be NFC or Bluetooth LE or Camera etc which is required for app to run and developer has made required=true for those features in manifest.
If you're trying to download the app from the Play Store, it is very likely that the developer has defined filters on that app (http://developer.android.com/google/play/filters.html). These filters are not part of the Android Manifest and so, they cant be changed. This has been answered here already: How to restrict android app to specific device make?
I want to enable android.permissions.STATUS_BAR in my app. Is it possible to do so, given that I am targeting possibly non-rooted phones?
From what I understand, android.persmissions.STATUS_BAR is a System persmission and can't be used.
In android terms it falls under signatureOrSystem permission. The meaning is (taken from Android Manifest DOCS)...
A permission that the system grants only to applications that are in the Android system image or that are signed with the same certificate as the application that declared the permission. Please avoid using this option, as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed. The "signatureOrSystem" permission is used for certain special situations where multiple vendors have applications built into a system image and need to share specific features explicitly because they are being built together.
Have a look at the following links as well. They might help you find a workaround...
How to disable statusbar in android
Why are these permissions being refused?
Preventing status bar expansion
Is there a way to tell if a certain Android permission is required by which Android APIs? For example, which APIs will require the GET_TASKS or REBOOT permissions? My app, inherited from someone who's long gone, has these permissions listed in the manifest. I don't think we are using them, but I'm also afraid that if I remove them, there will be bad consequences. Any ideas on how to deal with this?
Both of these permissions are quite specialized, and only have a few uses.
android.permission.REBOOT
First of all, this permission has a protection level of signatureOrSystem, so unless your application is part of a custom ROM or you have access to the signing keys for the platform you are installing it on, the application won't even be granted the permission.]
It is required to call PowerManager.reboot()
android.permission.GET_TASKS
This permission is only marked dangerous, so your app can actually obtain this one.
There are two calls in ActivityManager that require this permission, getRecentTasks() and getRunningTasks() to get information about the current application tasks in the system. It's often used by custom Launcher applications to populate task lists.
HTH
PScout was a tool that analysed Android SDK and generated a map that maps Android permissions to methods that require those permissions.
Original PScout website doesn't work anymore but I extracted the mapping from original PScout and pushed it to Github. You can easily check it out and parse it if you need it.
Here you can find all methods that PScout found which require Android permissions.
PScout results- map of Android permissions and methods that require those permissions
Take out each piece then run in. If it continues to work keep what is deleted and move down the list of permissions.
Can somebody explain to me what are the benefits of Android System App over a "normal" app
(besides that fact that a system app cannot be uninstalled)?
Special permissions?
There is some confusion here.
First, if you are talking about "system app" as just being one with FLAG_SYSTEM set, all this means is that the app is located on the /system partition, which is the read-only partition that is basically the firmware of the device. (It can only be modified as part of an OTA firmware update.) These apps can't be removed simply because they are on a partition that can't be modified.
The only thing special about a system application beyond this is that there are a handful of signature permissions that can also be granted to any app on the system image. For example there is a permission to directly talk with the package manager to install an app (without going through the system UI) that such an app can have; this is useful for any app store / market pre-loaded on a device.
Being signed with the platform certificate is an orthogonal concept -- such an app can be either on the system image or installed as a third party app (though obviously in almost all cases these come pre-installed). Such apps have access to a whole suite of low-level permissions for interacting with the platform. Very few apps are signed with this certificate; it is only for core platform applications. Unless you are working with a hardware vendor on a device, you won't have access to this.
All of the platform's certificates (whether they be available to all apps, require an app be signed with the platform cert, or are available to apps installed on the system partition) are declared by the platforms manifest, just like any other app:
https://android.googlesource.com/platform/frameworks/base/+/master/core/res/AndroidManifest.xml
There are permissions that can only be obtained by systems apps. For example the permission brick can be requested by every app but it is only granted to apps that are signed as system apps. There are some other features that make more sense I think directly installing and removing apps would be a system only permission too.
From your explanation I guess you mean the the pre-installed applications (like the Browser or the Messages app). You can take a look in these apps at https://android.googlesource.com. (search for platform/packages/apps/...).
You will find that these application are no difference to your own custom developed Apps, except you can't remove them. They cannot be removed as they provide the basic functionality to operate your phone / device. So, same security constraints apply there.