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
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
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
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.
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
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.
1
1
Show replies