Android is disallowing execution of native library when running as system app - android

When I sign my app with the system certificate, I can no longer use an SDK that comes with a custom native library. The SDK executes code from that native library. All works fine when my app is not signed as a system app, but when signed, I get an error.
The error appears to come from an SELinux policy with this log message:
type=1400 audit(0.0:22): avc: denied { execute } for
comm=4173796E635461736B202331
path="/data/data/myapp/cache/librs.bitmap_to_argb.so" dev="mmcblk0p22"
ino=16791 scontext=u:r:system_app:s0
tcontext=u:object_r:system_app_data_file:s0 tclass=file permissive=0
Why would my app not be able to execute a library like this that is located in the app's internal storage?

System apps expect their native libraries to be in /system/lib or lib64 directory. Maybe you can avoid this if you set android:extractNativeLibs="false" in the application manifest.

Related

Copying to Android System Folder programmatically

I'm implementing a new feature on Android 10(10.0.0_r30) that has to copy files from the data folder to the system folder at runtime. I've tried to do it via 'su cp' in Zygote, since Zygote runs as root, but then I get this error:
type=1400 audit(0.0:61): avc: denied { getattr } for name="su" dev="dm-0" ino=3160 scontext=u:r:zygote:s0 tcontext=u:object_r:su_exec:s0 tclass=file permissive=1
SELinux is disabled and I have no clue where else to look for the resolution of this error. Also, the system folder is writeable(parameter given to the emulator)
Besides that, can anyone tell me how else I could implement this particular task without rooting?

avc: denied { connectto } when using uds on Android 10

I'm running 2 applications on Android 10 device which communicate each other via uds. Everything worked fine until I changed the apps settings to target android 10. I get following error in logcat:
09-07 13:33:18.136 14573 14573 W <myapp_name>: type=1400 audit(0.0:1461891): avc: denied { connectto } for pid=14573 comm=474C546872656164203134353530 path=005368617265644D656D6F727953657276696365 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:r:untrusted_app_25:s0:c512,c768 tclass=unix_stream_socket permissive=0
After some digging I found neverallow SELinux policy:
neverallow { all_untrusted_apps -mediaprovider } init:unix_stream_socket connectto;
Is there a way I can make it work on applications targeting Android 10?
UDS with abstract path doesn't work for API>=28 due to the following changes.
Per-app SELinux domains
Apps that target Android 9 or higher cannot share data with other apps using world-accessible Unix permissions. This change improves the integrity of the Android Application Sandbox, particularly the requirement that an app's private data is accessible only by that app.
To share files with other apps, use a content provider.
https://developer.android.com/about/versions/pie/android-9.0-changes-28#framework-security-changes

Can System App access /data/data of other apps

I am developing an app for the custom device. My app run from /system/priv-apps
I need to access /data/data for other apps to give a cloud backup functionality.
While searching I came across "android.permission.CONFIRM_FULL_BACKUP" permission but I couldn't find a way to get the content of that particular "/data/data/pkg_name".
I don't think that system apps have su permission so I can't call cp -R src dest
Can anyone tell me regarding this?
Being in the same scenario as you fellow, my system app cant read nothing inside /data/data
Logcat:
W type=1400 audit(0.0:121): avc: denied { read } for name="data" dev="vdc" ino=122881 scontext=u:r:system_app:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0

SELinux Unix Socket permission denied. How to fix?

I have modified bluedroid to include a small unix socket server for reasons.
When client starts, I see that SElinux doesn't like it, and throws out this:
05-26 18:01:41.072 6248-6248/? I/com.gps.uclient: type=1400 audit(0.0:20): avc: denied { connectto } for path=00236264726F696468696472617773727663 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:r:bluetooth:s0 tclass=unix_stream_socket permissive=1
This socket does not have a real path. How do I add SELinux rule to allow this socket?
Update
Tried audit2allow as mentioned by Google here
Got errors.
gps#gps-HP-ProBook-4540s:~$ audit2allow -i sedeny.txt -p ./andsrc/android-6.0.1_r25/out/target/product/flo/root/sepolicy
libsepol.policydb_read: policydb version 30 does not match my version range 15-29
libsepol.context_from_record: user u is not defined
libsepol.context_from_record: could not create context structure
libsepol.context_from_string: could not create context structure
libsepol.sepol_context_to_sid: could not convert u:r:untrusted_app:s0:c512,c768 to sid
I have no real experience in SELinux, so I am pretty much stuck here.
The error was:
policydb version 30 does not match my version...
This error was generated by audit2allow installed with apt-get.
It is resolved by using audit2allow found in the AOSP.

Loading an .so native library from android's obb folder

I have an .so file that I packed into an obb expansion. It's about 20 megabytes.
I'm trying to use
System.load("/storage/emulated/0/Android/obb/com.mypackage.myapp/libtest.so");
to load the library. But I get the error:
dlopen("/storage/emulated/0/Android/obb/com.mypackage.myapp/libtest.so", RTLD_LAZY) failed: dlopen failed: couldn't map "/storage/emulated/0/Android/obb/com.mypackage.myapp/libtest.so" segment 2: Permission denied
type=1400 audit(0.0:8): avc: denied { execute } for path="/storage/emulated/0/Android/obb/com.mypackage.myapp/libtest.so" dev="fuse" ino=367663176224 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:fuse:s0 tclass=file permissive=0
So I realized that we're not permitted to have an executable there.
So my question is,
1- Where should extract the file to be able to do this?
2- What function call should I make?
Thank you.
Copy the file to any location of your choice under your app's private internal storage folder, make sure it is marked read only and executable (not writable, especially by anyone else!). This is the only tree of locations typically writable by an application where executables are permitted.
You can determine the private folder location by calling getFilesDir() on an initialized Activity or Service Context.
There are a number of existing questions here which demonstrate mechanisms for file copying in Java.

Categories

Resources