-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revisit the Android W^X problem #2155
Comments
On the one hand, we need to think about how we can still give the sandboxed code access to storage files. On the other hand, we can use this opportunity to explore support for containers and containerized applications (e.g. Docker, Flatpak, ...), possibly after figuring out how to resolve complications made by the SE Android policies. |
We would definitely risk being suddenly removed from play store if we try to circumvent the policy, but as you said I guess it is theoretically possible to comply in the same way as browsers with javascript. I think what we need is some people to feel strong enough about this "issue" to actually develop and experiment with possible solutions. The apk route has been shown to be possible, but needs much more work. Alternative ideas are great, but an idea is not really worth anything before it is implemented (as business people like to say). |
Yes and No! I studied the use of a boot loops concept and made good experiences. |
I agree with @iamahuman .. @xeffyr If we just use proot to solve this, it may become easier.. but it has its own problems... 1- This is a known fact- performance issues... 2- Usual termux users love the fact that these packages are run directly under the android system.. That's why most users ask for packages natively that adjust without them with proot 3- Any bugs or issues with proot upstream would also be an issue with Termux.... 4- The Build script would have to be modified.. I don't know to what extent.... The best approach, I think would be to modify termux-exec, which currently is a wrapper only for shebangs around execv(). This would mean more work.. but has its benefits... |
@suhan-paradkar We have only 3 variants of resolving the issue:
Variant 1 is current one, 3 - against Play Store policy.
To do so you need to inject a LD_PRELOAD into Dalvik/ART startup. This is not possible and therefore you can't use shared library approach. It also works on function level and not the system call - will cause troubles with non-C/C++ programs. You need a program which takes ELF executable, load its sections into memory and passes execution flow. A bare variant of |
What is that build script? It won't be hard to make Termux app build proot and bundle into APK. If you are talking about package scripts, then there no issues at all. It even possible to get rid of most of our packages with IMO, impact on user experience is inevitable. You can't keep quality, functionality, performance or application store availability on high level at same time. Even now this isn't possible, not saying about what will be after fixing |
@xeffyr I've a question: Is the existence of
Agree! My current build script support also: "1. Leaving everything as-is and continuting with SDK 28." |
https://support.google.com/googleplay/android-developer/answer/9888379:
Proot by itself doesn't violate anything. But it lets application to continue violate policy through downloadable packages. Yes, Termux already violates the policy and it doesn't matter whether proot is added or not. It still exists in Play Store, but there are risks. |
OK - very juristic formulation. Thus, play store as a distributor no longer suitable for a developing app like termux, when Google does not change that. In the bootloop, after the first version are always local |
The only "advantage" is being able to submit updates to Play Store. Not so many. Termux works on Android 11 and even on 12 beta. That's expected, because Android currently preserves backwards compatibility. Problems will be only if with specific update Google decides to drop it. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
These solutions wouldn't have to overall reduce usability: for example, if binaries could be installed to sdcard storage, that would be a huge plus elsewhere. |
Sorry for the dumb question but with the packaging everything into the apk does that mean it is no longer possible for users to compile and run programs? That would be unfortunate. |
@Vixeliz PRoot can be used to workaround that but: a. Any custom executable loader is technically against Play Store app publishing policy. - Matters only if we decide to continue Play Store updates. |
@xeffyr I see, if you were to try and get back on play store is it feasable to have two versions one with proot and one without? My main use case for termux is developing applications and im very worried it won't be possible going forward. |
I don't think 2 termux versions with and without proot would be a good idea. because it needs to maintain one for non-proot-ed termux app for target level 29 (assuming in-APK's for example) and for proot-ed termux app it also needs to maintain existing package implementation which is apt and would probably need much maintenance so preferably one choice is a choice |
I see well personally i am crossing my fingers for proot then. |
In the The more ELF in |
I suppose withdrawing from Play Store has one big problem: funding. |
Play Store is a just one of ways for funding and no one of maintainers except Fornwall shares it (both account & funding) anyway. While Termux can |
As an user, I think the best approach is the current one: don't use play store for publishing the app. Other ways to overcome this issue seem to have too many disadvantages and in future Google could tighten PS policies even more. There are already too much problems caused by wrong choices made by Google on Android done on the assumption that users are stupid, or for the sake of privacy and security (when instead those should be in a compromise with usability and comfort). You get two advantages by don't publishing the app to PS:
|
Well, so I have been an idiot thinking that for the APK packages design ( # Allow apps to read/execute installed binaries
allow appdomain apk_data_file:dir r_dir_perms;
allow appdomain apk_data_file:file rx_file_perms;
# Sensitive app domains are not allowed to execute from /data
# to prevent persistence attacks and ensure all code is executed
# from read-only locations.
neverallow {
bluetooth
isolated_app
nfc
radio
shared_relro
sdk_sandbox
system_app
} {
data_file_type
-apex_art_data_file
-dalvikcache_data_file
-system_data_file # shared libs in apks
-apk_data_file
}:file no_x_file_perms;
On top of that, since there is no PlayStore does not seem to have any restriction regarding loading native libraries of other apps, they only need to be inside APKs in PlaySore. All app builds outside PlayStore can use our own hosted repos and mirrors directly.
Although, not sure how one is supposed to protect against this for a general terminal app.
A drawback for APK design is that it will need Other normal files (
I have tested this design on Android $ getprop ro.build.fingerprint
google/sdk_gphone64_x86_64/emu64x:UpsideDownCake/UPP2.230217.004/9663077:userdebug/dev-keys
$ env | sort | grep TERMUX_
ENV__ROOT_SCOPE=TERMUX_
TERMUX_APP__APK_FILE=/data/app/~~Tn249ZOX-wa4kZT9uuKW-g==/com.termux-8Fo-uB5C2dL9xB9NIhQPlA==/base.apk
TERMUX_APP__APK_RELEASE=GITHUB
TERMUX_APP__BUILD_VARIANT=bootstrapVariant=apt.android-7;targetSdkVersion=34
TERMUX_APP__DATA_DIR=/data/user/0/com.termux
TERMUX_APP__IS_DEBUGGABLE_BUILD=true
TERMUX_APP__IS_INSTALLED_ON_EXTERNAL_STORAGE=false
TERMUX_APP__PACKAGE_NAME=com.termux
TERMUX_APP__PID=5071
TERMUX_APP__SE_FILE_CONTEXT=u:object_r:app_data_file:s0:c169,c256,c512,c768
TERMUX_APP__SE_INFO=default:targetSdkVersion=34:complete
TERMUX_APP__SE_PROCESS_CONTEXT=u:r:untrusted_app:s0:c169,c256,c512,c768
TERMUX_APP__TARGET_SDK=34
TERMUX_APP__UID=10169
TERMUX_APP__USER_ID=0
TERMUX_APP__VERSION_CODE=118
TERMUX_APP__VERSION_NAME=0.119.0-beta1
TERMUX_VERSION=0.119.0-beta1
TERMUX__AM_SOCKET_SERVER_ENABLED=true
TERMUX__AM_SOCKET_SERVER_PATH=/data/data/com.termux/files/apps/com.termux/termux-am/am.sock
TERMUX__APPS_DIR=/data/user/0/com.termux/termux/apps
TERMUX__CORE_DIR=/data/user/0/com.termux/termux/core
TERMUX__DATA_HOME=/data/data/com.termux/files/home/.termux
TERMUX__HOME=/data/data/com.termux/files/home
TERMUX__PACKAGE_MANAGER=apt
TERMUX__PACKAGE_VARIANT=apt.android-7
TERMUX__PREFIX=/data/data/com.termux/files/usr
TERMUX__ROOTFS=/data/data/com.termux/files
TERMUX__ROOT_DIR=/data/user/0/com.termux/termux
TERMUX__SHARED_USER_ID_APP_PACKAGES=com.termux
$ /system/bin/ls -lZh $PREFIX/bin/bash
lrwxrwxrwx 1 u0_a169 u0_a169 u:object_r:app_data_file:s0:c169,c256,c512,c768 124 /data/data/com.termux/files/usr/bin/bash -> /data/app/~~TjBAnoUJxGcSDGSDrK7-rQ==/com.termux.tapm.rootfs_0.termux_bootstrap-PbU_h-Q1BH4FonRHuVcNuA==/lib/x86_64/lib120.so
$ /system/bin/ls -lZh /proc/$$/exe
lrwxrwxrwx 1 u0_a169 u0_a169 u:r:untrusted_app:s0:c169,c256,c512,c768 0 /proc/7374/exe -> /data/app/~~TjBAnoUJxGcSDGSDrK7-rQ==/com.termux.tapm.rootfs_0.termux_bootstrap-PbU_h-Q1BH4FonRHuVcNuA==/lib/x86_64/lib120.so
$ /system/bin/ls -lZh /data/app/~~TjBAnoUJxGcSDGSDrK7-rQ==/com.termux.tapm.rootfs_0.termux_bootstrap-PbU_h-Q1BH4FonRHuVcNuA==/lib/x86_64/lib120.so
-rwxr-xr-x 1 system system u:object_r:apk_data_file:s0 806K /data/app/~~TjBAnoUJxGcSDGSDrK7-rQ==/com.termux.tapm.rootfs_0.termux_bootstrap-PbU_h-Q1BH4FonRHuVcNuA==/lib/x86_64/lib120.so
$ /system/bin/ls -lZhd /data/data/com.termux
drwx------ 7 u0_a169 u0_a169 u:object_r:app_data_file:s0:c169,c256,c512,c768 4.0K /data/data/com.termux
$ su -mm -c '/system/bin/ls -lZhd /data/data/com.termux.tapm.rootfs_0.termux_bootstrap'
drwx------ 5 u0_a171 u0_a171 u:object_r:app_data_file:s0:c171,c256,c512,c768 4.0K /data/data/com.termux.tapm.rootfs_0.termux_bootstrap
$ su -c 'dumpsys package com.termux 2>&1 | grep SharedUser'
sharedUser=SharedUserSetting{36d4d91 com.termux/10169}
SharedUser [com.termux] (36d4d91):
$ su -c 'pm list packages | grep termux'
package:com.termux
package:com.termux.tapm.rootfs_0.termux_bootstrap
$ apksigner verify --verbose --print-certs termux-app_apt.android-7.release_universal.apk
Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Number of signers: 1
Signer #1 certificate DN: CN=APK Signer, OU=Earth, O=Earth
Signer #1 certificate SHA-256 digest: b6da01480eefd5fbf2cd3771b8d1021ec791304bdd6c4bf41d3faabad48ee5e1
$ apksigner verify --verbose --print-certs termux-bootstrap-release.apk
Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Number of signers: 1
Signer #1 certificate DN: CN=Agnostic Apollo, L=Earth
Signer #1 certificate SHA-256 digest: d3be90deb8e1d9e4b8f2f397520f7e430788477e96d2f879eefdcf35518926a1
$ termux-am startservice com.termux/.app.TermuxService
Starting service: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.termux/.app.TermuxService }
$ am startservice com.termux/.app.TermuxService
Starting service: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.termux/.app.TermuxService } It was suggested in #1072 and internally to use on-demand features modules, but that ain't gonna work for PlayStore. When on-demand feature modules are requested to be installed with Play Core APIs (not
But since There is a
Moreover, using feature modules is not a good general solution for Android
Some additional interesting links |
I posted a proposal how to work around the "no exec() in data folder" problem using |
#1072 needs extra attention Fornwall is active again and work is already being done on #1072 for an alternate variant at termux/termux-exec#24 and the other alternate #2155 (comment) will be worked on in future.
The last time I checked, PyDroid offered a embedded terminal emulator on which Also I suggest that if any of the breaking changes is to be made to target Android 10 or later, it should be released under another app name, package name, and account. Therefore if it's succeeds, we'll have one more choice on Android 10+; if it fails, only the newer version will be removed from Google Play, and the current users are unaffected. The current app can be maintained until the day Android drops the backward-compatibility. |
@sls1005 You seem don't understand the issue with Play Store. The problem is that application on Google Play is outdated and that happened for a reason: no Termux update can be submitted until necessary requirements would be met. So in order to update the application on Play Store the app should integrate a fix for Android 10, no matter whether it is breaking or not. Otherwise the outdated app on Play Store has to be unpublished, though the current maintainer team can't do so because lacking access to Google Play console. Changing app package name is not easy task as would have a lot of consequences even if the old app would be kept. |
Per Nifty's request, was asked to drop in. I can (and have) presented some RFC patchsets on behalf of the LineageOS org that have been merged into AOSP With that said, seeing the general direction of this thread, if someone wanted to build out the permission "Allow application dynamic code execution" or whatever you choose to call it (I'd wire it us as a dev-settings toggle personally), you should topic the bare minimum changes to get it functioning, tag it [RFC], toss on AOSP Gerrit targeting |
Unfortunately, all developer options reset when you toggle the "developer options" switch in Settings. And while developer options are enabled, your build number annoyingly appears in the notification shade with no option to hide it. I prefer to keep developer options disabled most of the time. I think it would be awkward if there were certain apps on your phone that only work while developer options are enabled and stop working as soon as they're turned off. For these reasons, I would much prefer that it be a permission. More specifically, a |
that is also an option. permission only grantable over adb. |
Hi @npjohnson, Thanks for dropping in. Great to hear about the patches and connects, would be useful when the time comes. I plan on working on it after the next major app release, whenever that happens, don't have time currently. Apart from settings being reverted when developer options are disabled, it's unlikely that android team would accept a global toggle and technically they shouldn't, since all apps shouldn't be allowed to execute untrusted code and an app specific dev permission granted over adb would be the way to go and would have higher chances of actually being accepted. Will post some docs about all of this shortly. |
Here's an update to the Virtualization approach: there was a blog post just published by the Android Developers Blog called Virtual Machine as a Core Android Primitive, which shows some public movement on the Android Virtualization Framework. Android 14 will allow privileged applications to start and manage VMs; previously, only the platform itself could do so. The blog calls out a few specific use-cases for privileged applications, including Biometric computations as well as DRM, both of which they say will be easier to update and manage across Android devices (no longer requiring code specific to each vendor's "secure compute" systems). My understanding is that privileged applications can only spin up a VM image that is signed by Google or the device vendor. "Microdroid" is one such image, a stripped down version of Android and can be created on all Pixel devices from the Pixel 6 onwards. Microdroid retains the SELinux W^X policy which is sensible from the security standpoint. In my opinion, it's unlikely Google will allow unrestricted virtualization by third party applications any time soon. However, specific vendors might, in ways that give a competitive edge (think Samsung DeX). Not sure this will bear fruit for something like Termux but it is perhaps something to keep an eye on. |
@agnostic-apollo I'd really hate to see Android become so locked down that you can't even have a terminal emulator. Is there any way I can donate to you to support the development of the AOSP permission to execute dynamically loaded code? There are a surprising number of people who rely on Termux as part of their daily workflow, yet don't know that its prolonged existence is currently up in the air. Recently there was even an article on LWN about it: https://lwn.net/Articles/936953/ Any mention of Termux frequently gets highly upvoted on Hacker News. I'm down to create a blog post or GitHub gist attempting to rally up support for this change. I think it would receive much positive attention online. |
Docs have been added for android app data file execute restrictions at following links.
@DownrightNifty Hey, thanks for the offer. Check https://termux.dev/donate for how to donate to me or preferably other termux devs currently. I already have funding for next couple of months, and it's not as much a money issue, as it's a time issue. I have a gazillion things to do related to Termux and currently termux app updates and related work takes higher priority since they have been already been delayed for far too long (as LWN points out too) and more people are in greater need of the update with fixes and additions than any future breakage. I have been working on the updates full time for more than a year at this point, there is just so much work to do and everything is broken. Getting the permission added to AOSP is a priority for me too, just not the top priority and I do plan on looking into it after the releases like I have already said. Go ahead if you want to make a blog post, that would be great. However, I think after all this time, all the important people who may be able to actually get a real fix implemented already know about it, but then again funding could help motivate someone to take charge. Also a working hack is being worked on at termux/termux-exec#24 as mentioned above. |
This comment was marked as off-topic.
This comment was marked as off-topic.
as workaround (for termux-play-store/termux-issues#24 termux/termux-app#2155 termux/termux-app#4037 ). Fixes ``` ~/SubStack $ ./a.out cxx/Macros.hxx: pass execves(): pass execvex(): pass virusAnalysisTestsThrows(): pass assistantCnsTestsThrows(): /data/data/com.termux/files/usr/bin/sh: 1: wget: Permission denied /data/data/com.termux/files/usr/bin ``` , (to ``` conversationCnsTestsThrows(): --2024-06-15 18:22:01-- https://stackoverflow.com/robots.txt Resolving stackoverflow.com (stackoverflow.com)... 172.64.155.249, 104.18.32.7 Connecting to stackoverflow.com (stackoverflow.com)|172.64.155.249|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: ‘robots.txt’ robots.txt [ <=> ] 1.99K --.-KB/s in 0.07s 2024-06-15 18:22:02 (27.4 KB/s) - ‘robots.txt’ saved [2036] ``` , as was)
as workaround (for termux-play-store/termux-issues#24 termux/termux-app#2155 termux/termux-app#4037 ). Fixes ``` ~/SubStack $ ./a.out cxx/Macros.hxx: pass execves(): pass execvex(): pass virusAnalysisTestsThrows(): pass assistantCnsTestsThrows(): /data/data/com.termux/files/usr/bin/sh: 1: wget: Permission denied /data/data/com.termux/files/usr/bin ``` , (to ``` conversationCnsTestsThrows(): --2024-06-15 18:22:01-- https://stackoverflow.com/robots.txt Resolving stackoverflow.com (stackoverflow.com)... 172.64.155.249, 104.18.32.7 Connecting to stackoverflow.com (stackoverflow.com)|172.64.155.249|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/plain] Saving to: ‘robots.txt’ robots.txt [ <=> ] 1.99K --.-KB/s in 0.07s 2024-06-15 18:22:02 (27.4 KB/s) - ‘robots.txt’ saved [2036] ``` , as was)
Feature description
Termux should circumvent Play Store policy of restricting execution of arbitrary code from third parties, by imitating what Google Chrome does. Bundling packages into APKs is certainly not the way to go.
isolated_app
?), emulating forbidden system calls as needed. (Note that we already do this with execve to handle#!/usr/bin/...
shebangs)./system/bin/linker
).Reference implementation
N/A
Related
The text was updated successfully, but these errors were encountered: