Analogue of LD_DEBUG for zygote-spawned process - android

I'm wondering if Android has an option for user to enable LD_DEBUG-style logs for Zygote-spawned processes. Probably we can not start app_process for Zygote with customized environment without being a root user. So maybe there is some system property or maybe kind of linker API that allow to get dynamic linker logs for some debuggable Android package that may contain native libraries.

aiui there isn't a way to do this on an un-rooted device until O.
Starting with O, you can add a wrap.sh to your (debuggable) APK to do things like this. I don't think we have any docs published for this yet, but it's sort of described here: https://github.com/android-ndk/ndk/issues/380#issuecomment-314223774

Related

Android APK signed with PLATFORM key not given system privileges?

I have access to an Android tablets' platform key and certificate. I'm attempting to build an app and install it with system level privileges by doing the following:
Create a Java KeyStore file with platform.pk8 and platform.x509.pem using the bash script called platform_import_keystore found on GitHub.
In AndroidManifex.xml add the following:
<uses-permission android:name="android.permission.READ_LOGS"/>
android:sharedUserId="android.uid.system"
Sign APK with PLATFORM key and certificate using a Java KeyStore file in Android Studio.
Install APK
When the app runs, the system denies READ_LOGS permission.
Why isn't my app running with system level permissions?
What #Mark mentions is correct to some extent, for system apps.
I think you are doing something else wrong.
I have tried this with system apps as well, and as long it was signed with the platform keystore, it works. Now this was on Android 8 and Android 9. You haven't mentioned the AOSP version running the device.
That changes things AFAIK, so if it's AOSP 10+, it might behave differently.
Also the other comments are missing another key thing SELinux. SELinux is not permissive for user builds. Verity is enabled, and you cannot have root access. So you cannot push the app into /system/priv-app/ or push it into /vendor/app/.
You cannot access system resources without proper SE Policy files. You can check the logs yourself, to see avc denied messages.
I think overall what you are seeing should be inline with AOSP's security ideals. An app signed with System keys should not be able to get system permissions. It also needs to be located in the correct place, either as a privileged app or vendor app. Such apps need to be whitelisted. There's a built in script in AOSP source to even generate the permissions for whitelisting (it produces the required xml)
There's two classes of system apps, /system/app/ and /system/priv-app/
The privileged apps are the only ones that get signature level permissions, and according to newer versions of android, you need to enable whitelisting in the /system/etc/priv_app-permissions_device_name.
If you make any changes to the system or vendor when verity is enabled, firstly they are mounted read only, but somehow if you do make a change, the device will brick itself. This is the security feature. All custom development needs to be done in userdebug builds with SELinux in permissive mode, and then all the permissions need to be predefined, SE Policies fine tuned to utmost minimal, only then the user build can function normally. User build is not at all suitable for AOSP development activities, even if it's just for testing or trying out a single app.
User build is production type build that the end user can use and is not for development. It's the most secure form of android, so if you have platform keys, it may never be enough.
All that being said, I'm sure you don't have the right keys. Just pull an app from system/priv-app/ and use keytool or similar to check it's signature, and then try to match with your release apk.
It's little complicated as it is, and kind of hard to explain and there are levels of permissions also in android, so if you aren't following a specific approach/path, you will not be able to get it to work.

Permission to read /cache/recovery/last_log

Which permission an app need to access the file /cache/recovery/last_log?
My app is signed with platform key, so I can provide system permissions. The app will be pre-built into a device, and the device will be non-rooted.
You can only access the cache directory for your app
getApplicationContext().getCacheDir()
Apparantly, you don't need any permission to READ from cache. But you do need permission if you want to write something in cache directory.
Documentation from http://developer.android.com/reference/android/Manifest.permission.html#READ_LOGS on logs:
Allows an application to read the low-level system log files.
Not for use by third-party applications, because Log entries can contain the user's private information.
Constant Value: "android.permission.READ_LOGS"
What do you mean by 'recovery'?
I found the solution some time ago, just posting here to help if someone else have the same problem.
The thing that was blocking me was SELinux. I'm posting the solution to the original question, but be aware that some things changed on Android since that, including the creation of the A/B system, where the recovery and cache partitions where removed from Android.
SELinux
I learned the hard way that one have to deal with SELinux in order to work on the Android source code. The important bits are:
On the device definition (makefiles under the device directory) there will be reference to SELinux policies. In one of the devices I work with I have a makefile that have:
BOARD_SEPOLICY_DIRS += path/to/sepolicy/dir
And on the directory all files with ".te" ending will be used as SEPolicy. I suggest adding a new directory for your custom policies, where you can use your own git repository.
Now you need to know what policies to write. I suggest reading Google's documentation here.
Personally, I first test the app on a userdebug build with SELinux in permissive mode (log only). These way SELinux will only log actions that violates the policies, what makes development substantially easier. Only after I know the app runs with SELinux off I start collecting the logs and set the "enforced" mode.
To collect the SELinux logs of actions that don't met the policies I use:
adb logcat | grep "avc: denied"
There is a tool called audit2allow that reads the logcat output and the device policy and outputs policies that are missing:
adb pull /sys/fs/selinux/policy
adb logcat -b all -d | python2 audit2allow -p policy
The output of the file are policies that can be added to the .te files.
This particular method I used with Android 8.1.
Sign app with platform key
I also had to sign the app with the platform key. For that I edited Android.mk to add:
LOCAL_CERTIFICATE := platform
System UID
Fixing SELinux policy might not be enough for some device. You might need to make the app run with the system user.
You must avoid using these method, because this user have access to some very sensitive device files. If you really need, you can do it by:
Sign the app with platform key;
On the app that will read the recovery, you have to make sure AndroidManifest.xml set android:sharedUserID to "android.uid.system".
<manifest package="my.app.name"
xmlns:android="http://schemas.android.com/apk/res/android"
android:sharedUserId="android.uid.system">
....
</manifest>
Other useful files
Other files of interest to diagnose boot and ota problems are documented here.

How to check if Android Permission is actually being used?

I am maintaining one existing (very-huge, very-sensitive) Android Application.
The other day, I have received an email from my client that, the Application might be declaring the Permissions that are not actively being used.
For example, they wants me to remove "WRITE_EXTERNAL_STORAGE" permission.
I have removed it and compiled it and run the App. There is NO error at all.
But, just because of that, I don't think I can assume that permission is not actively being used at all.
My question is "Is there anyway I can easily and simply check the permission if it is actively being used ?"
Frankly, I don't want to go through every little detail aspect of that application just to fine out the permission is required or not.
I just don't have time.
My goal is check if the permission is actively being used. If not, remove the permission.
Hope there is an less-time consuming way for that.
Regards
In Android Studio 1.3 & Android Support Library v7:22.2.0, you have solution for it.
Steps:
Update Android Studio to V1.3
Update your Android Support Library to v7:22.2.0
Run Android Lint (Analyse -> Inspect Code), In Lint Error see for Type "Android -> Constant & Resource Type MisMatch", Which shows all methods which requires permission.
Explanation
Android has introduced new annotation #requirespermission.
All SDK methods which requires permission are annotated with #requirespermission.
When we call any sdk method which requires permission without properly checking whether we have permission or not, Android studio will through lint error.
There is a group at Berkeley that wrote a paper about Android permissions. They talk about over-permissions and developed a tool called Stowaway that would analyze your APK for unused permissions. The analysis was based on the app's API calls and their own mapping of the permissions needed for each API call (see the paper for details). The tool throws a flag if there is a permission in the manifest that is not mapped to any of the API calls found in the APK.
For a while, a web-based version of the tool was available at http://www.android-permissions.org/, but it is from the Gingerbread era and was never updated. The page now suggests using PScout.
PScout does a better job than Stowaway at generating the permission maps. However, PScout does not include an APK analyzer, so you will have to manually compare the mappings they provide with API calls made by your app. Unfortunately, if you're interested in maps for versions beyond 5.1.1, you'll have to generate them yourself using the provided PScout code and your own Framework source.
You might also check out the various APK analyzers here to see if they include the functionality you are looking for.
I tried the method suggested by Vasanth but it doesn't work for me. In fact, because my project has flavors and Code Inspection doesn't work for the project with flavors. See https://code.google.com/p/android/issues/detail?id=210073.
But Running Lint from console works. So steps are simple:
Remove permissions from your manifest.
Run Lint for flavor as described here https://stackoverflow.com/a/32708435/1170154.
Open Lint result and find section Correctness > Error MissingPermission: Missing Permissions. It will contain all calls that require permissions.
As of Android Studio 3.3, running Analyze → Inspect Code will inform you of missing permissions under Android → Lint → Correctness → Missing Permissions

Permission is only granted to system app, in Manifest

I want to add this permission to my Android manifest:
<uses-permission android:name="android.permission.MODIFY_PHONE_STATE" />
But after I paste this permission in my manifest, it tests red underline and says:
permission is only granted to system apps
What can I do?
MODIFY_PHONE_STATE permission is granted to system apps only.
For your information, there are 2 types of Android apps: system & user
User apps are just all your normal app installations through the Google Play Store, Amazon Appstore or sideloading. These go into the /data partition of your Android phone, which is the part of the internal memory made available for user data and apps.
System apps are basically the apps that come pre-installed with your ROM. In a standard Android user environment, the user doesn’t have write access to the /system partition and thus, installing or uninstalling system apps directly isn’t possible.
In order to install an app as a system app on your Android device,
your device must either be rooted or have a custom recovery installed (or both).
That being said, that error is actually wrong because you have a valid code and compilation should work. It would be better if it gave a warning instead. In Eclipse you can easily fix it. Just go to:
Window -> Preferences -> Android -> Lint Error Checking.
Find ProtectedPermission from the list and set the severity to something other than error(info for example). This way your project will still compile.
MODIFY_PHONE_STATE is a system-only permission. System Apps are either pre-installed into a system folder or compiled by a manufacturer using their security certificate.
Hence, if you are trying to do this you are trying to use API which are no longer supported. With Android versions 2.3+ you can monitor incoming calls, but blocking is not allowed (i think from the link you posted thats what you're trying to do).
Android issues if you need to follow: Issue 15022 and Issue 14789
This error appears in SDK 19 onwards, when you change the manifest.
Do Project Clean and Build.
It should clear this error.
just clean your project it will be fine like this :
project > Clean...
There are four types of Permission
Regular
Dangerous
Signed
Signed or System
The first two can be used by Simple Apps Other two can only be used by the app which is build in framework
Because this is the system level permission device developer not grant this so application development tools also warn against this so you have to
Simply Clean project & Rebuild this is it
Find ProtectedPermission from the list in
Window -> Preferences -> Android -> Lint Error Checking.
and set the severity to something other than error(info for example). This way your project will still compile.

What's the difference between a regular Android APK and one included as part of a device's system image?

We have a manufacturer that wants to pre-install our application on their Android device. We sent them the APK and even though it installs fine when used by a user, it appears to not get installed correctly when included in the manufacturer's build image. FYI, our application uses the JNI layer and some libraries built with NDK. The exception we're seeing seems to indicate that the class loader cannot find the library and is unable to load it. They have verified that the library files are indeed present in the APK.
Since we dont make devices, its unclear why they are seeing this exception and what needs to be done differently when including a package as part of the Android build image.
Any Android folks here care to comment?
I have worked with pre-installed Android apps, that also uses library files, in my case jar files. I am assuming that you have added the appropriate lines to AndroidManifest.xml like <uses-library android:name..... I am also assuming that you have provided instruction on how to install your library files on handset, with instructions like adb push ... on the command prompt. If you havent, do provide them the instructions.
Another issue may be permissions, we had to get the library jar AND the permissions xml file installed, that may be the issue.
Also ensure that you are using the correct version of Android for testing. And if everything fails, ask them to send one of the handsets that is not working to you and you can then compare with the one in office and debug this. Good Luck, as all this can be pretty frustrating.
Besides moving the apk file into /system/app, you should ask the manufacturer to move the native libraries created by NDK (.so files) to /system/lib or the path specified by LD_LIBRARY_PATH.
Please refer to https://groups.google.com/d/topic/android-porting/r_Ao7_PWgKQ for more details.

Categories

Resources