Play Store now forbids downloading executable code
thestinger opened this issue · 17 comments
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 remain in compliance with the guidelines, Termux would need to put each package into an apk installed from the Play Store instead of doing package management internally.
I thought you might appreciate a heads up about this.
I think the only thing that might be a problem is the bootstrap package. All other dowloads are user initiated. User initiated downloads have to be fine otherwise things such a s browsers wouldn't be allowed to exist, because they could also download code. Also this rule has been in place for a long time now. I remember talking about this months (years?) ago and nothing has happened.
so include the bootstrap in apk itself?
Yeah. It would be a bit annoying but it would probably solve any issues. But I don't think we need to do anything right now. Again this has been in effect for some time. And our app isn't malicious in the slightest. But IANAL. To me it looks like Termux is fine. Especially because it doesn't execute any downloaded java code. "This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a WebView or browser)." I think what Termux does falls into this category. Programs from Termux definitely have only limited access to the Android API and basically run inside the normal jail that Android invokes. And except the bootstrap package everything is user initiated anyway to which this rule must not apply.
Downloading native code and running it in the usual Android app sandbox is a clear violation of the policy.
They rewrote the policy to be much more explicitly about this being disallowed, and it can be expected that they'll not only act on it for the Play Store but via SELinux policy.
They intend to support cases like Termux by having apps like Termux upload their packages as separate apps to the Play Store, with it initiating user installs / uninstalls of those apps.
Staying ahead of the game (i.e. future SELinux policy enforcement) would involve not extracting the executables manually but rather running them from where the apk package installer extracts libraries. Being able to execute app_data_file either as an executable or a library is on the way out in the long term.
Downloading native code and running it in the usual Android app sandbox is a clear violation of the policy.
Where are you getting this from? The spirit of the policy is spelled out clearly at the top: "We don’t allow apps that steal data, secretly monitor or harm users, or are otherwise malicious." They want to be able to ensure that users download what was advertised and tested in the Play store.
Termux doesn't modify itself (you can't replace the terminal app with apt), and it doesn't allow automatic downloading or installation of APKs. I'm not sure how you expect a user to manually install every dependency, or why Google would see that as a sensible thing for them to police.
Where are you getting this from? The spirit of the policy is spelled out clearly at the top: "We don’t allow apps that steal data, secretly monitor or harm users, or are otherwise malicious." They want to be able to ensure that users download what was advertised and tested in the Play store.
A very deliberate / explicit misreading of the rules isn't going to stop them from taking action.
It says, first of all:
An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play’s update mechanism. Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a webview or browser).
Followed by this:
The following are explicitly prohibited:
- Apps or SDKs that download executable code, such as dex files or native code, from a source other than Google Play.
It's very clear that they intend to enforce similar rules as Apple does for iOS, they simply haven't cracked down yet and they only very recently reworded it to have much stronger wording.
Doing this with knowledge that it's not permitted is considered malicious.
Termux doesn't modify itself (you can't replace the terminal app with apt), and it doesn't allow automatic downloading or installation of APKs.
That doesn't matter. It's violating the rules by downloading native code from a source other than Google Play and running it.
I'm not sure how you expect a user to manually install every dependency, or why Google would see that as a sensible thing for them to police.
I didn't say I expected that. I just pointed out that it's explicitly violating the rules. They've made these rules much more explicit and will be finally starting to enforce them.
It's a sensible thing for them to police because they want to move to having comparable security as iOS and they can't do that as long as the SELinux policies and Android Runtime permit executing code from the app_data_file label.
deleted : why?
Executable code running in the same SELinux domain as the app have full access to the Android APIs, etc. just like an app and isn't permitted unless it came from the apk. The rules are very clear now, with the expectations very explicitly spelled out.
The rules can be worked around in a few different ways like using apks shipped via Google Play which doesn't mean needing to manually search for them and install them. It seems less realistic to take the approach of fully virtualizing the environment. Maybe it would be permitted to run native code in an isolatedProcess as long as it was still properly contained without access to Android APIs like an executable / library running alongside app_process in the main SELinux domain.
I'm only communicating the changes to the rules that made this much more explicit. I didn't write the rules and have won't have any involvement in the upcoming enforcement. I don't know when they're going to start enforcing it but it appears to be coming soon, alongside changes like forcing apps to use targetSdkVersion 26+, etc. They have some major security issues in the app ecosystem compared to iOS and they're addressing them. There's no reason to think that the rules don't apply to everyone.
Let's wait and see what happens. Feels kinda impossible to distribute ≈900 packages through apk's.
In the worst case scenario we still have F-droid.
Feels kinda impossible to distribute ≈900 packages through apk
It's not only that. It's also package managers like pip and gem that add a myriad of available software to termux. Hell curl example.com/script.sh | bash downloads and executes code. If these rules are truly enforced upon Termux, Termux as such can't exist. And if we start to run the app in some kind of virtual machine or it would stop making sense at all as we might as well run debian or archlinux at this point.
worst case scenario
does NOT exist
Either thestinger is right, and Google interpret their policy harshly and remove Termux from the Play store, or there's nothing to do. I don't see how it can be pre-empted. This seems like concern trolling to me.
I don't see how it can be pre-empted
By considering if the package manager could install packages (apps) from Google Play to conform to the policy. If that's not realistic, then I expect it will be a victim of their policy and then of SELinux policy hardening. I use it and I'm interested in keeping in working without rolling back future security features.
The discussion is treating me as if I'm the one that came up with this policy and it doesn't seem very productive, so we'll just see what happens as they start enforcing stricter Play Store policies. shrug
Not aiming to reopen this thread, but I should apologise for my tone in my last comment. @thestinger, I didn't realise you were making a point based on badly designed apps in the wild, and jumped to the wrong conclusion that you were relying solely on the wording of the terms. Sorry about that.