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 <nyk...@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... _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
