Conversation

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.

Play Store now forbids downloading executable code · Issue #655 · termux/termux-app

https://play.google.com/about/privacy-security-deception/malicious-behavior/ Apps or SDKs that download executable code, such as dex files or native code, from a source other than Google Play. To r...

1

3

10

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.

No more exec from data folder on targetAPI >= Android Q · Issue #1072 · termux/termux-app

The ability to run execve() on files within an application's home directory will be removed in target API > 28. Here is the issue on Google bug tracker: https://issuetracker.google.c...

1

1

This Tweet was deleted by the Tweet author. Learn more

This Tweet was deleted by the Tweet author. Learn more

Replying to

It prevents whatever the policy is set up to prevent. It will fully prevent executing any new native code, whether it's regular anonymous memory, memfd, tmpfs or via the regular file system as long as the policy is set up to do that. That's what I did in my downstream changes.

1

This Tweet was deleted by the Tweet author. Learn more

Replying to

No, I think it counts as tmpfs. SELinux doesn't allow anything that the policy isn't specifically written to allow though. Removing execution of app_data_file involved removing a rule, not adding anything. Similarly, disabling mapping it as exec means removing execute for it.

1

Replying to

and

The policy in Android Q still permits apps to dynamically generate executable code in-memory or on storage and execute it. It only stops them from directly running it as an executable. They can still generate memory / files dynamically that is then mapped as executable.

1

Replying to

and

The purpose is primarily to protect apps from their own vulnerabilities, so it doesn't need to be a complete implementation like my downstream work fully preventing dynamic code for base system apps and for third party apps that aren't given an exception from the rules by users.

1

Replying to

and

Such as a file write vulnerability combined with the app putting their executables and/or libraries in app data instead of using the native library directory which is read-only for them. Same thing could happen with dex code or other interpreted code which isn't prevented at all.

1

Replying to

and

Since I'd already fully prevented it for native code, I was working on closing the ways for apps to accidentally execute attacker data via Java. The base system doesn't need any dynamic execution from data so it can be disallowed there. Third party apps sometimes use it though.

7:52 PM · Mar 18, 2019Twitter Web Client

Replying to

and

So you either need to flat out forbid it just like they're doing for executables in app data or you need a system for exceptions to be made, ideally with the apps requesting them as needed, not leaving it to users to figure out. Problem is apps devs will take the lazy route.

1

Replying to

and

If you provide a way to get an exception, 95% of developers will use that to whitelist extracting and running their executables / libraries from app data rather than moving to doing both via the native library directory which has always been the proper way to handle this stuff.