[Toybox] Android API 29 and custom Toybox upgrades

[enh]

the official security answer was given on
https://b.corp.google.com/issues/128554619#comment4 with the most
relevant bits being:

"""
The change to block exec() on application data files for targetAPI >=
Q is working-as-intended. Please see
https://android-review.googlesource.com/c/platform/system/sepolicy/+/804149
for background on this change. Calling exec() on writable application
files is a W^X (https://en.wikipedia.org/wiki/W%5EX) violation and
represents an unsafe application practice. Executable code should
always be loaded from the application APK.

While exec() no longer works on files within the application home
directory, it continues to be supported for files within the read-only
/data/app directory. In particular, it should be possible to package
the binaries into your application's native libs directory and enable
android:extractNativeLibs=true, and then call exec() on the /data/app
artifacts. A similar approach is done with the wrap.sh functionality,
documented at https://developer.android.com/ndk/guides/wrap-script#packaging_wrapsh
.
"""

that link to the specific sepolicy change is worth following for the
commit message there too.

On Tue, Sep 10, 2019 at 10:46 AM Denys Nykula <nykula at ukr.net> wrote:
>
> Hi Elliott, maintainers of Android apps with native executables are tweeting to
> Rob but Android is your area of work so please comment:
> https://twitter.com/topjohnwu/status/1171308880904646656
>
> > I'm curious about @landley's (author of toybox) thoughts on the direction
> > Android is heading. He had mentioned the goal to make Android fully self
> > hosting, however ever since Android 10 it is not even possible to run
> > downloaded executables if an app is targeting API 29.
> >
> > Magisk Manager is hit by this restriction, and my current workaround is to
> > simply target API 28. However someday in the future Google *will* eventually
> > force all apps on Play Store to target 29 or higher, making apps such as
> > @termux very hard to survive.
> >
> > If even harmless apps like @termux that provides an isolated shell and a
> > package manager aren't allowed, I think it's clear that making Android a self
> > hosting platform is pretty much a pipe dream at this point.
> >
> > P.S. I'm aware of the tool PRoot, however the technique it uses comes with
> > significant overhead. It is fine in the case of running a few executables as
> > in Magisk Manager, however I don't think it counts as a feasible solution for
> > a so-called "self hosting platform".
>
> What's new in API 29 for user's executables?

see above.

> If I adb shell and wget new builds
> of Toybox and Dropbear, a) will they run in adb,

yes. (at least to the extent they have in previous releases.) the
shell uid and selinux domain are unrelated to app uids and untrusted
app selinux domains, which is why a lot of toybox commands work via
`adb shell` but don't if you're doing fork/exec from an app.

> b) will terminal emulators on
> phone continue giving access to Android's builtin mksh and toybox and let me
> run my own builds without root,

yes. those binaries are on a read-only partition.

> c) will GNU/overlays such as Termux work that
> give way to shell-scripting Android APIs for sound playback, camera etc?

probably not... downloading arbitrary code that you then execute is
more challenging. (which was the point of the security change.) the
workaround would be to include everything in your apk. but obviously
if your goal is to be "basically apt-get" and pull stuff in on demand,
that's not going to work...