5 ms·

Termux allows you to apt install thousands of packages. The options in that issue aren't nearly as good. Bundling every binary in the apk? That would be a breac

Termux allows you to apt install thousands of packages. The options in that issue aren't nearly as good. Bundling every binary in the apk? That would be a breach of licenses, let alone the amount of storage that would take up to have gimp, libreoffice, Firefox, etc installed. As mentioned, proot is a temporary hack (why wouldn't any app just stick proot in their lib Dir?). Even if the workaround works, this would break apt install from non-termux repos, compiling and running with gcc, maybe Python packages installed with pip. Google's intent here is to block code execution in the app home Dir. Any workaround would be a security violation and eventually stopped. How is this not killing Termux?

kllrnohj 6y ago
> Google's intent here is to block code execution in the app home Dir Google's actions are to block exec of writable code. What their _intentions_ are is pure speculation and detracts from the actual issue. Your claim is largely unsubstantiated & lacks evidence, particularly as Google recommended ways to continue to do exactly what you claim they are intending to block. > The options in that issue aren't nearly as good. How is using a PROT_EXEC mmap "not nearly as good"? It's the same end result. There's no technical banning of executing downloaded code. That's not what was done, and doing that would also break Chrome which should be glaringly obvious that Google isn't intending or going to do. It takes a bit more effort, and it's not as "simple" as just exec'ing random stuff, but it's not without its own upsides as well (like not violating W^X, which is a _well_ proven security design)
- AshamedCaptain 6y ago
  That is not at all what happens. W^X is not the problem. W^X is already enabled by default. Executable pages are not mapped in as writable even if the image file is writable. The security argument is bullshit. The problem is that they don't want you mapping code from anywhere other than your strictly read only .apk. There is no workaround proposed there other than shipping every single piece of executable code with the .apk. Sure, you can workaround right now with proot or the like by creating your own executable loader, but who guarantees this works with Android 11? It is also a violation of their policy. In fact, what they are saying there is that eventually fork and exec are going to be deprecated because they disalign with the Android process model.

kllrnohj 6y ago

> Google's intent here is to block code execution in the app home Dir Google's actions are to block exec of writable code. What their _intentions_ are is pure speculation and detracts from the actual issue. Your claim is largely unsubstantiated & lacks evidence, particularly as Google recommended ways to continue to do exactly what you claim they are intending to block. > The options in that issue aren't nearly as good. How is using a PROT_EXEC mmap "not nearly as good"? It's the same end result. There's no technical banning of executing downloaded code. That's not what was done, and doing that would also break Chrome which should be glaringly obvious that Google isn't intending or going to do. It takes a bit more effort, and it's not as "simple" as just exec'ing random stuff, but it's not without its own upsides as well (like not violating W^X, which is a _well_ proven security design)

AshamedCaptain 6y ago
That is not at all what happens. W^X is not the problem. W^X is already enabled by default. Executable pages are not mapped in as writable even if the image file is writable. The security argument is bullshit. The problem is that they don't want you mapping code from anywhere other than your strictly read only .apk. There is no workaround proposed there other than shipping every single piece of executable code with the .apk. Sure, you can workaround right now with proot or the like by creating your own executable loader, but who guarantees this works with Android 11? It is also a violation of their policy. In fact, what they are saying there is that eventually fork and exec are going to be deprecated because they disalign with the Android process model.