4 ms·

I just want to be able to run Python scripts and whatnot on my phone; I don't care much about how it's implemented. I'm sure it's possible to have this without

I just want to be able to run Python scripts and whatnot on my phone; I don't care much about how it's implemented. I'm sure it's possible to have this without compromising security. As far as I know, the Android sandbox already provides pretty great protection against any programs running inside Termux, so there's not much reason to block exec()? It would at least be nice if they made W^X exec() into a permission (probably not toggleable from the Settings UI, perhaps only grantable through `adb shell pm grant`, if they want to make sure only powerusers can do this). For example, some poweruser apps like Tasker can be granted "WRITE_SECURE_SETTINGS" permission through adb to unlock more features. This permission is very powerful so it can't be granted through the Settings UI.

pjmlp 5y ago
Using adb is a feature only in developer mode, plugged into SDK tools. You can enjoy PyDroid for the time being, https://play.google.com/store/apps/details?id=ru.iiec.pydroid3 https://play.google.com/store/apps/details?id=ru.iiec.pydroi... But it might not be around for long, https://www.theregister.com/2021/07/29/google_play_python_javascript/ https://www.theregister.com/2021/07/29/google_play_python_ja...
- NotPractical 5y ago
  > Using adb is a feature only in developer mode, plugged into SDK tools. I'm aware. The difficulty in this process would act as a filter ensuring only powerusers can do it. It would certainly not be ideal to have to do this just to use Termux, but if Google wants to eventually enforce W^X exec(), it would be better than nothing. I'm honestly curious as to what the security implications of allowing exec() in writable directories really is. For example, GrapheneOS' top priority is security and it hardens the Android sandbox even beyond AOSP, and yet it still supports Termux (and I doubt its users would accept if it dropped support for this, even if in exchange for a little extra security). If anyone knows about this, I would appreciate your input.
kllrnohj 5y ago
> It would at least be nice if they made W^X exec() into a permission W^X is what Android is pushing people towards, there's no reason for a permission to guard what's recommended. And it doesn't restrict any useful behavior. It does require some design burden to do properly, though, which not everyone is willing to do. But eg Chrome & Firefox have no issues with their JavaScript JITs that still comply with W^X.
- NotPractical 5y ago
  I meant a permission to circumvent the W^X restriction. > And it doesn't restrict any useful behavior. It does require some design burden to do properly, though, which not everyone is willing to do. Do you know of any alternative approach to the gross APK packaging one? I would say it definitely restricts "useful behavior", unless you think Termux would be just as useful after API 29 compatibility were implemented (and I would disagree). Besides, when thinking about implementing a security feature, the question "does this restrict behavior?" is important (and I think it does in this case), but not quite as relevant as the question "what actual extra security does this provide?", and I'm not quite sure how much extra security this provides. Could someone provide a realistic attack scenario?

pjmlp 5y ago

Using adb is a feature only in developer mode, plugged into SDK tools. You can enjoy PyDroid for the time being, https://play.google.com/store/apps/details?id=ru.iiec.pydroid3 https://play.google.com/store/apps/details?id=ru.iiec.pydroi... But it might not be around for long, https://www.theregister.com/2021/07/29/google_play_python_javascript/ https://www.theregister.com/2021/07/29/google_play_python_ja...

NotPractical 5y ago
> Using adb is a feature only in developer mode, plugged into SDK tools. I'm aware. The difficulty in this process would act as a filter ensuring only powerusers can do it. It would certainly not be ideal to have to do this just to use Termux, but if Google wants to eventually enforce W^X exec(), it would be better than nothing. I'm honestly curious as to what the security implications of allowing exec() in writable directories really is. For example, GrapheneOS' top priority is security and it hardens the Android sandbox even beyond AOSP, and yet it still supports Termux (and I doubt its users would accept if it dropped support for this, even if in exchange for a little extra security). If anyone knows about this, I would appreciate your input.

kllrnohj 5y ago

> It would at least be nice if they made W^X exec() into a permission W^X is what Android is pushing people towards, there's no reason for a permission to guard what's recommended. And it doesn't restrict any useful behavior. It does require some design burden to do properly, though, which not everyone is willing to do. But eg Chrome & Firefox have no issues with their JavaScript JITs that still comply with W^X.

NotPractical 5y ago
I meant a permission to circumvent the W^X restriction. > And it doesn't restrict any useful behavior. It does require some design burden to do properly, though, which not everyone is willing to do. Do you know of any alternative approach to the gross APK packaging one? I would say it definitely restricts "useful behavior", unless you think Termux would be just as useful after API 29 compatibility were implemented (and I would disagree). Besides, when thinking about implementing a security feature, the question "does this restrict behavior?" is important (and I think it does in this case), but not quite as relevant as the question "what actual extra security does this provide?", and I'm not quite sure how much extra security this provides. Could someone provide a realistic attack scenario?