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.
Related
Goal: Have an app that can update itself on a custom/rooted ROM in Android 13 by saving the APK locally, then having an app install it without user interaction.
Solution: Use an intention as described in the second answer here.
What no longer works:
Originally this was a question because after a lot of time I only found out-of-date answers. Android keeps on increasing security and deprecating old APIs. Here's a list of rabbit holes to avoid.
Install with exec(), su, and pm install
Granting the app android.permission.ACCESS_SUPERUSER and similar permissions
Forcing ROM into permissive mode at compile to avoid SELINUX blocking access
Approach 1 fails because you will get Caused by: java.io.IOException: error=13, Permission denied. First you need to move the APK into a tmp dir. However when you try to run su you get the exception. You need to be su for pm install -r -d foobar.apk to work. This used to be the most common way that people installed a new apk. Even if there were no issues with it I would recommend using the answer above as its less of a hack.
Approach 2 seems to be just out of date and Android has moved on.
Approach 3 is an attempt to get around the su issue. It's unclear if SELINUX is really what was causing the exception to be thrown and maybe someone can clarify what's going on. SELINUX is what was blamed and a lot of people spent a lot of time trying to create custom rules.
To get something that worked I attempted to force the device into permissive mode. Using compile time flags doesn't work BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive and Google needs to update the instructions. I could write more here, but it's a black hole. Looking at logs there was no indication SELINUX was blocking 'su'.
I am working on custom Android build, where prebuilt should be included as a system app. Simply, this app adds VPN profile and open links after it.
I've done the following with no result. I left no stones unturned.
First, I add the APK to packages/apps/<app name>, and include its module name in build/make/target/product/base_system.mk to be include in the /system. It successfully included in /system/priv-apps/. Reference
Following these steps, I re-signed the APK as a system apps & added android:sharedUserId="android.uid.system" to application. Successfully done and checked it with adb shell ps -Z | grep system_app.
Selinux policy denied most of operation used audit2allow and added the allow statements to system/sepolicy/public/init.te.
Result: the app installed but seems the OS blocked some of its services/processes or something and cannot operate properly, I also found this I/system_server: oneway function results will be dropped but finished with status OK and parcel size 4.
AFAIK, System apps gain access to an extremely high level of system. But this is not what is happening.
Why does Sepolicy denies a system_app request?
Is there any wrong with these steps? What should I do in order to make the app work properly?
Update.
the app include prebuilt .so files and now the error is that the app cannot run these files.
Cannot run program "/system/priv-app/****/lib/arm64/libovpnexec.so": error=2, No such file or directory
I am having an app which is targeting android 27 API. I am testing this app from playstore on device Android Q which work managed device.
Steps i followed on device Android Q having build build 6-
Installed app and allowed all the permissions(additional permission also which are custom permissions).
Uninstalled app from device.
Installed again app from playstore and found that app is asking custom permission only instead no permission.
Is it the expected behavior? Anyone know how this is?
This is something called Auto Backup.
Files that are backed up
By default, Auto Backup includes files in most of the directories that
are assigned to your app by the system:
Shared preferences files.
Files saved to your app's internal storage, accessed by getFilesDir() or getDir(String, int).
Files in the
directory returned by getDatabasePath(String), which also includes
files created with the SQLiteOpenHelper class.
Files on external
storage in the directory returned by getExternalFilesDir(String).
Auto Backup excludes files in directories returned by getCacheDir(),
getCodeCacheDir(), or getNoBackupFilesDir(). The files saved in these
locations are only needed temporarily, or are intentionally excluded
from backup operations.
You can manage it by AndroidManifest.xml. See android:allowBackup
<manifest ... >
...
<application android:allowBackup="true" ... >
...
</application>
</manifest>
EDIT
android:fullBackupContent="false"
android:fullBackupOnly="false"
There are 2 more rules available to set.
EDIT 2
I just found more useful information at the android official website. see here
Note: Any permissions a user grants to your app are automatically
backed up and restored by the system on devices running Android 7.0
(API 24) or newer. However, if a user uninstalls your app, then the
system clears any granted permission and the user must grant them
again.
My best guess is there should be some difference(like 24hours) until the user settings/permissions will be deleted from the system device/cloud.
Hopes this will answer your query in some way.
Regarding whether this is an expected behavior in Android Q:
This issue does not reproduce on Android Q emulator. I guess it counts as a baseline.
More technical details:
Runtime permissions logic in Android is mostly located in PackageManagerService (mostly book keeping for each package) and ActivityManagerService (mostly request runtime permission logic)
When package gets deleted, the data cleanup method removePackageDataLIF
gets called. It is responsible for cleaning up everything including the app permissions. This logic hasn't changed Android Q.
The permissions info is stored in system data directory, not the application's so the app data backup doesn't affect it either.
But the question remains: How could this happen?
One of the possible explanations could be the flag PackageManager.DELETE_KEEP_DATA
You can easily delete package while keeping its data directory after uninstall:
$ adb shell cmd package uninstall -k your.app.id
(-k is for keep data)
Now to check whether the permissions are kept in place along with the data directory:
$ adb root && adb shell cat /data/system/users/0/runtime-permissions.xml | grep your.app.id -A 10
(this command requires a debuggable phone firmware build)
Looking at the source of removePackageDataLIF and trying it on my Pixel with debuggable firmware the application permission is kept intact if you kept its data.
Another explanation
PackageManagerService has an another interesting method setKeepUninstalledPackages Which basically forces android to keep all the data for specified apps even if they were uninstalled.
As you said the device is work managed. Usually management is done with DevicePolicyManager. One of the available policies is setKeepUninstalledPackages, which calls the mentioned above PackageManagerService method.
Please check your Device admin app code to verify.
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.
In my company, we would want total control for battery consumption in the field, using only 2g and gps could drain the battery awfully fast. What we decided is that we need to have root access to the mobile phone, So that when phone is idle, we would turn off those needless battery consumption.
And also we would not allow users to uninstall it and clear data to it.
My Question is :
Where do I get these signature key?
Is it going to like a root access If ever I successfully managed to
sign it?
What is the difference between Root vs Signed with key?
Answering your three questions:
1 - Where do I get these signature key?
From Android's own documentation in the section Release Keys
The Android tree includes test-keys under
build/target/product/security
But the next part is where you should really pay attention
Since the test-keys are publicly known, anybody can sign their own
.apk files with the same keys, which may allow them to replace or
hijack system apps built into your OS image. For this reason it is
critical to sign any publicly released or deployed Android OS image
with a special set of release-keys that only you have access to.
So basically unless you can somehow gain access to manufacturer's pvt keys it might be difficult to achieve this. This is why a user in a previous comment was saying this is usually achieved by producing your own build.
2 - Is it going to like a root access If ever I successfully managed
to sign it?
You will not get "root access" by doing it, but you will get access to an extremely high level of access. Specifically, what this achieves you is that you will be granted permissions with declared android:protectionLevel="signature" which is, arguably, the most exclusive one.
One other dangerous consequence (or fun, depending on how you look at it) of this is that you can now run your app under system user process android:sharedUserId="android.uid.system" - under android's "process sandboxed" security rules this would normally fail.
3 - What is the difference between Root vs Signed with key?
With an app signed with the platform key from your build, you can get the permissions mentioned above, or run your app with UID 1000 (system uid) which in android is much more powerful than the UIDs of other apps because of the permissions it can request, this is a behaviour specific of Android though.
In a rooted device, you can use UID 0 (root) which has the broadest access in linux based systems, you can bypass most of the security sandboxing/checks/fences on the OS.
Hope this helps ;)
Well below is your answer,
You can find platform keys from
HERE. The command to sign apk (for linux) is:
java -jar signapk.jar -w platform.x509.pem platform.pk8 APPLICATION.apk APPLICATION_sign.apk
onward Android 10 lib64 library path need to provided which can be found at android/out/host/linux-x86 after generating a successful build, one can copy folder or simply provide its path to generate sign APK
java -Djava.library.path="<path to lib64>" -jar signapk.jar -w platform.x509.pem platform.pk8
If you sign your apk with platform keys you won't required root access you can simply install it from "adb install" command, and yes in someway it is like root 'cos it can access all internal api but keep in mind if your app is system signed then you can't write external storage.
First of all don't combine both root is user where system app is application type which distinguish from normal application below link might clear your confusion regarding it.
what-is-the-difference-between-android-user-app-with-root-access-and-a-system-ap
For anyone coming to this question and even after reading the comments not being able to make it work, it might be because there're some things missing (specially if getting OPENSSL errors), here's everything you need.
Sign APK with test keys from the AOSP
git clone https://android.googlesource.com/platform/prebuilts/sdk.git - Careful it's ~6GB, or you can download what you need, the signapk.jar file and the libraries.
download the platform.x509.pem and platform.pk8 from https://github.com/aosp-mirror/platform_build/tree/master/target/product/security (or get your own keys corresponding to the image)
With java installed, change the following command with the right paths for the files, the lib64 in the sdk you just cloned, the signapk.jar file, the platform key files and the apk to sign
java -Xmx2048m -Djava.library.path="~/../sdk/tools/linux/lib64" \ # In the cloned sdk
-jar ~/../sdk/tools/lib/signapk.jar \ # In the cloned sdk
platform.x509.pem platform.pk8 \ # The keys for signing (from step 2)
app-prod-release.apk release.apk # The app to sign and the signed app