Avoid executing ELF files directly

[fornwall]

This is change to work around the Android 10 R^W violation (execution of binary files are not allowed).

See the README for more information.

Helping with testing

Help to test this would be great! For context and more information, see Problem 1 and Solution 1 in the updated README.

NOTE: May totally break your system and need a reinstallation (or require a manual repair in a failsafe session - see below).

Steps (on aarch64 - let me know if you want to test on some other arch):

• Be sure you have updated packages:
  • pkg up
• Take a backup (if this is not a installation that you can reinstall termux quickly):
  • cp $PREFIX/lib/libtermux-exec.so $PREFIX/lib/libtermux-exec.so.bak
• Download and install a test build of termux-exec containing this code:
  • curl -o ~/te-997.deb https://fornwall.me/te-997.deb && apt install --reinstall ~/te-997.deb

After this, new terminal sessions will be using the updated termux-exec version. A way to check this is by running ls -l /proc/self/exe - it should show a symlink pointing to a path ending in bin/linker64, since the linker is what is being executed.

Try things out (run scripts, compile programs, etc) and report if something does not work as a comment in this issue!

This should only affect behaviour on Android 10+ devices, but if you have an old Android version you are welcome to test that as well - that nothing has changed there.

Helping with testing: Debugging tools

• export TERMUX_EXEC_DEBUG=1 to get verbose logging to stderr
  • This log output may interfere with programs
• export TERMUX_EXEC_OPTOUT=1 to opt out from termux-exec - it will not do any modification to execve calls

Helping with testing: Known issues

• Statically linked executables such as zig does not work (linker errors with has unexpected e_type: 2)

Helping with testing: To restore

If things are not completely broken, apt install --reinstall termux-exec=1:1.0 will install the stable version of termux-exec.

If the installation is completely broken, so you can't even start a shell:

• Start a failsafe session by dragging out the drawer from the left, long press on the NEW SESSION button, and click FAILSAFE in the dialog that shows up.
• cd $PREFIX/lib && cp libtermux-exec.so.bak libtermux-exec.so
• You can now start a normal shell session again
  • Restore the termux-exec package properly with: apt install --reinstall termux-exec=1:1.0

Updates

• 2023-10-17 (file te-997.deb, apt show termux-exec should show version 9:9.7):
  • Various fixes to edge cases and logging
  • Introduce TERMUX_SELF_EXE, the absolute path to the executed file, which can be used as a /proc/self/exec replacement.
• 2023-10-05
  • Various fixes to edge cases and logging

[agnostic-apollo]

Very interesting solution. But yeah, it likely won't be acceptable by play store policies, but could be tried. Although not sure if android could add further selinux restrictions to prevent this.

Btw are you sure in testing, you uninstalled all termux apps, rebooted, and reinstalled, since otherwise untrusted_app_27 selinux process would still be assigned to the app, you can confirm with Termux in-app settings -> About, just making sure.

The executable being /system/bin/linker64 issues may be significant though.

[agnostic-apollo]

Do not use hardcoded com.termux values here and elsewhere, it affects termux forks. To get prefix, first check TERMUX__PREFIX env variable, then PREFIX, otherwise default to package build time path @TERMUX_BASE_DIR@. In future, multiple rootfs support may also be added and $PREFIX has been deprecated in favour of TERMUX__PREFIX (note double dash as scope), as it conflicts with other packages like npm, etc. Haven't pushed change to termux-app yet.

[fornwall]

Thanks - I'll update!

[fornwall]

Changed to look at TERMUX__PREFIX now, with a TERMUX_BASE_DIR value given at compilation time as fallback.

I think PREFIX is too dangerous to use, as you say it can totally break when reused for other purposes.

[agnostic-apollo]

Thanks. But do not use literal com.termux value. The whole path @TERMUX_BASE_DIR@ should be replaced during build time in the source by value set in properties.sh. Possibly tests should use this too.

https://github.com/termux/termux-packages/blob/26b05538619ffd93cfd52f252f34d1c025d51be7/scripts/properties.sh#L34

For inspiration, check termux-tools design by grimler.

https://github.com/termux/termux-tools/blob/master/configure.ac

https://github.com/termux/termux-tools/blob/master/Makefile.am

Also do not limit prefix length to 48, package names can be much longer. For example /data/user/10/net.dinglisch.android.taskerm/files will fail with length 49. Even /data/data paths can be longer. Package name alone on playstore can be of length 50. Probably just check if it starts with / since technically packages can be compiled for any prefix, even /data/local/tmp for adb or /mnt paths for external sd.

[agnostic-apollo]

Yeah, good idea not to use $PREFIX, will have to push TERMUX__PREFIX export to termux-app as well.

[fornwall]

But do not use literal com.termux value

With the current version (I made changes and squashed commits): We start by using the TERMUX__PREFIX env variable now. If that does not exist, we fall back to TERMUX_BASE_DIR.

TERMUX_BASE_DIR is given at compilation time, as in make TERMUX_BASE_DIR=/a/path/to/package/prefix (the
It's not really hardcoded any longer, but supplied at compile time (the existing package already supplies that at build time: https://github.com/termux/termux-packages/blob/master/packages/termux-exec/build.sh#L10).

Remaining usage of com.termux are ok I think:

• In Makefile, as a default value if make is executed without any argument
• In termux-exec.c, but only inside #ifdef UNIT_TEST, so only used for testing. We also test with other prefixes as well in the tests.
• In test-program.c, which is just a utility test program that can be run manually, not part of the package

[fornwall]

Thanks for your thorough review and feedback @agnostic-apollo !

[agnostic-apollo]

Will check code in detail later, outside, but if app is installed on adoptable external sd, then its app data parent directory prefix will be /mnt/expand/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/user/0, which alone has length 55, so 100 is not going to be enough, especially if multiple sub dirs under package name.

You are very welcome. :)

[fornwall]

so 100 is not going to be enough

Thanks again! So what about 200, that should be enough for everyone perhaps :)? That allows a path such as /mnt/expand/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/user/0/yyyyyyyyyy-yyyyyyyyyy/yyyyyyyyyy-yyyyyyyyyyyyyyyyyyyy/yyyyyyyyyyyyyyyyyyyy/yyyyyyyyyyyyyyyyyyyy-yyyyyy yyyy/xxxxx-xxxxx/yyyyy-yyyyy/zzzzzz-zzzzz/.

The reason I don't want an arbitrary big length is that it would be good to have a reasonable tight limit - this code is going to be injected in a lot of places, so not taking up more stack or heap space than necessary would be great, to decrease risks of interfering with the surrounding problem.

[agnostic-apollo]

lolz technically the only valid length is PATH_MAX(4096 bytes), but that would be for the full path, not just the prefix. That is also what libraries including mine use as the standard for passing to sys calls. You could reduce it if necessary, but couple of hundred bytes won't matter, but at least log a warning if value is ignored.

[sylirre]

But yeah, it likely won't be acceptable by play store policies, but could be tried.

As Play Store accepts apps that run binaries by proot and have target SDK 29+, I doubt that would be an issue. Maybe they consider the whole purpose of app (e.g. terminal emulators run binaries and need exec but games do not), who knows...

[agnostic-apollo]

I think it may be more likely that they don't know proot is being used, otherwise if someone took interest, proot and this clearly does violate the policy.

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 (such as dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser).
Apps or third-party code, like SDKs, with interpreted languages (JavaScript, Python, Lua, etc.) loaded at run time (for example, not packaged with the app) must not allow potential violations of Google Play policies.

https://support.google.com/googleplay/android-developer/answer/9888379?hl=en#zippy=%2Cexamples-of-common-violations

[fornwall]

Btw are you sure in testing, you uninstalled all termux apps, rebooted, and reinstalled, since otherwise untrusted_app_27 selinux process would still be assigned to the app, you can confirm with Termux in-app settings -> About, just making sure.

The executable being /system/bin/linker64 issues may be significant though.

Thanks, I noticed the behaviour you described as well, was really confusing first! But now I can confirm that I am indeed testing with effective targetSdk of 34! I'll share a branch of termux-app for testing shortly.

[fornwall]

I think we should focus on the technical issue here, and leave Google Play policy out of the discussion, since I think that's a separate one. This change is hopefully good on its own, for bumping targetSdk also for distribution outside of Google Play.

[agnostic-apollo]

Thanks, I noticed the behaviour you described as well, was really confusing first! But now I can confirm that I am indeed testing with effective targetSdk of 34! I'll share a branch of termux-app for testing shortly.

Welcome. Android also sometimes assigns latest target sdk SE_INFO, even if using older target sdk, and requires a reboot to fix. Have added checks for that too locally. I am far ahead of termux-app master locally, most of the non-terminal stuff has been rewritten/refactored, will be pushing in coming weeks when I manage to complete the changes.

leave Google Play policy out of the discussion

Fair enough. targetSdkVersion is far important, I also don't care too much about playstore either.

[twaik]

That solution may be problematic. Linker on old Android version does not allow to do this. But I am not sure when it starts.

[chenxiaolong]

That solution may be problematic. Linker on old Android version does not allow to do this. But I am not sure when it starts.

Looks like it was introduced in https://android.googlesource.com/platform/bionic/+/8f639a40966c630c64166d2657da3ee641303194, which was first included in Android 8.

[Grimler91]

That solution may be problematic. Linker on old Android version does not allow to do this. But I am not sure when it starts.

Looks like it was introduced in https://android.googlesource.com/platform/bionic/+/8f639a40966c630c64166d2657da3ee641303194, which was first included in Android 8.

Only supporting android >= 8 (or even a version or two higher) for an app re-introduced to google play seems reasonable to me

[sylirre]

Android 10+ solution is not needed to be used on older versions. It can be enabled on-demand, possibly with letting user to opt-out from this solution. Don't forget that:

• Not everyone uses Android 10 or higher there. Some people actually use Termux to make obsolete devices useful, e.g. to run home server.
• Some people have SELinux in permissive mode, whether intentionally or because custom ROM doesn't support enforcing. In this case exec restriction doesn't work.

Though I found one problem with this solution: users will no longer be able to run static binaries. When I attempt to run static binary, I get error unexpected e_type: 2. Can't remember any Termux package using static binaries, but sideloaded third-party prebuilt software definitely will no longer run without proot.

[agnostic-apollo]

Yeah, makes sense what you say, a user can unset LD_PRELOAD and export custom value for $TERMUX_EXEC__PROC_SELF_EXE, but we can always compare owner of file by running stat against current process owner. If user tried to export a prefix for a different app than their own, then stat would fail and we do not use fallback in that case either.

But I am fine with dropping the patch too.

[0-Whoami]

Steps (on aarch64 - let me know if you want to test on some other arch):

I want to test this on x86-64 and arm

[twaik]

@0-Whoami

1. No need to quote the whole post.
2. It will be available when it is good and ready.

[yujincheng08]

1. Instead of LD_PRELOAD, we can use seccomp to hook execve, which can preserve across fork, clone, and execve, and is useful for static elf as we cannot LD_PRELOAD them.
2. For static elf, do linker static_helper, where the static_helper is a simple linker to mmap the static elf according to its elf header and then call its entry point.
3. For /proc/self/exe, we can use PR_SET_MM_EXE_FILE; in detail, unmap all x memories of the linker while backup their addresses, offsets, and lengths, map some anon memories to these address to occupied their place, call PR_SET_MM_EXE_FILE, and then mmap the linker to their old addresses with MAP_FIXED.

[SomeDevHere]

3. For `/proc/self/exe`, we can use `PR_SET_MM_EXE_FILE`; in detail, unmap all `x` memories of the linker while backup their addresses, offsets, and lengths, map some anon memories to these address to occupied their place, call `PR_SET_MM_EXE_FILE`, and then mmap the linker to their old addresses with `MAP_FIXED`.

PR_SET_MM_EXE_FILE requires the CAP_SYS_RESOURCE capacity so it likely cannot be used.
An incomplete workaround would be to have any syscall that opens a file descriptor from a path would need to be wrapped with seccomp/ptrace and override the result if it points to '/proc/self/exe'.

[twaik]

It seems like overwriting the content of __progname variable changes contents of /proc/$PID/cmdline so we can use it to make programs think they are executed without linker as first (zero?) argument.
I do not think we can do it via LD_PRELOAD since I did not find direct way to obtain pointer to original argc using only __progname pointer. Also it seems like __progname pointer and address of argv[0] are not the same.
Probably we should modify the crtbegin.c to invoke some code allocating some memory for new raw_args (of type KernelArgumentBlock), and fill it with data from original raw_args without linker path and with argc decreased by 1 and overwrite original raw_args. It will not change the symlink of program in /proc/$PID/exe but at least will let programs like top or ps show correct cmdline.
I am not sure how exactly we can distribute and use modified crtbegin code.

[SwuduSusuwu]

This can cause anomalous results for programs which expect that /proc/self/exe is argv[0]: SwuduSusuwu/SubStack#26
In this case all it does is alter the offset+hash which a unit test prints (but does not alter the return value).