Last year, I filed an issue for Termux bringing up that it's in violation of the Play Store policy on downloading executable code: github.com/termux/termux-. I proposed implementing packages via apks and mentioned that SELinux policy would likely break their approach down the road.
Conversation
Surprise: Android Q breaks their approach for apps targeting API 29 or above.
github.com/termux/termux-
If you look at the original issue I filed, you can see that what I was saying was totally dismissed and ridiculed. I got called a "concern troll" for trying to keep it working.
1
1
Android provides a native library directory where the package manager extracts executables / native libraries bundled in the apk. It's read-only for the app itself. However, it's extremely common for apps to extract their executables / libraries to their data directory instead.
1
1
It's a common source of remote code execution vulnerabilities since a file write vulnerability trivially becomes RCE if an app is doing this. Removing native app_data_file execution was part of my past hardening work and it's nice to see a subset happening upstream for Android Q.
1
1
They're currently only forbidding direct execution for API > 28: android-review.googlesource.com/c/platform/sys. Mapping app_data_file as executable will generate an audit warning for API > 28 too. It will probably be forbidden next year to force usage of the native library directory for libraries too.
1
1
My changes removed app_data_file execute / execute_no_trans for the base system along with execmod/execmem. Dropping execmem requires using only ART's AOT compiler / interpreter, no JIT. My approach for 3rd party apps was allowing users to make exceptions for Termux, Firefox, etc
Replying to
These rules are about protecting apps from vulnerabilities, not protecting the OS / user from malicious apps installed on the system. An app can always ship their own interpreter including by disguising it as an accidental remote code execution vulnerability. It's not about that.
3