Termux:Sudo Addon proposal

[lars18th]

Hi,

I recently started to use Termux. And I find it very interesting. For years I have used other Linux-on-Android systems; but I think this project is superior: simple and effective.

After this short intro I propose a new idea around the “su” and “sudo” commands. Please, note that this isn’t a request of “how to use root in Termux” or “scripts for sudo”. I know about such tools, and this is a different proposal:

• The problem: If you grant the root permission to Termux, then any script running inside it can obtain root privileges (very bad!).

• The solution: Create a new Termux Add-on, called Termux:Sudo. This addon will be another different Android App. This new application will have an structure similar to Termux:API, so it can communicate with the Termux shell environment. But this new app focuses on running processes with elevated privileges. In consequence, this Termux:Sudo is the only app that needs to receive the root privileges.

• The implementation: The new Termux:Sudo will maintain an internal password for root (obfuscated) and a list of grant commands (or ‘*’ for all). So the function is very similar to the “sudo” command, and configured in the same way. Note that the data of Termux:Sudo App is inaccessible from the Termux environment, so the password and configuration is even secure.

• The use: When you call for example “sudo nano /system/build.prop” a password command is presented prior to execute the binary.

What you think about this idea?

[Grimler91]

Hi,

I'm not really an android app programmer but I'm not quite sure how communication similar to termux-api would work together with app data that is inaccessible from termux. Having it as a totally separate app would make the data inaccessible but communication between the apps would have to go through the android api. Or are you suggesting that the obfuscated password is readable only by root?

Sounds like an interesting idea,

Just for completeness: There was some discussion back in the day here which resulted in the tsu-script and termux-sudo.

[lars18th]

Hi @Grimler91 ,

Having it as a totally separate app would make the data inaccessible but communication between the apps would have to go through the android api.

The communication will be done using the same technique used in Termux:API: https://github.com/termux/termux-api See "How API calls are made through the termux-api helper binary" (that is using two sockets as PIPEs, one for STDIN and one for STDOUT).

Or are you suggesting that the obfuscated password is readable only by root?

No. Only the Termux:Sudo App has access to the password.

There was some discussion back in the day here which resulted in the tsu-script and termux-sudo.

Both runs in the same user space of the Termux process. My idea is to use another and different process.

Regards.

[michalbednarski]

Hi

Just a few random thoughts:

The problem: If you grant the root permission to Termux, then any script running inside it can obtain root privileges (very bad!).

I assume this means that threat model includes running malicious scripts inside Termux (as opposed to just running desktop software installation scripts that call sudo as part of their installation process and accidentaly make mess on filesystem)

Either way what is supposed to protect root access is Superuser app and what you're asking for is wrapper around it (because Superuser is not flexible enough for your use case)

When you call for example “sudo nano /system/build.prop” a password command is presented prior to execute the binary.

Well, by default nano is writable by Termux process (as well as libraries used by it), don't forget about those.

Also remember about protecting sudo launcher itself (from being replaced with hostile version capturing password, libraries or other files used by it being replaced and sudo launcher being ptraced to capture password)

Only the Termux:Sudo App has access to the password.

And of course everything that gets ran as root (Either via new sudo or standard su (from Termux or another installed app)), but that shouldn't be concern because it could replace Superuser app and not bother with Termux:Sudo

My idea is to use another and different process.

Well, if so then you should probably be able to make such app without cooperation from Termux side. Note that Termux:API works through being in same process but, I was considering extending termux-am it with api providing access to caller uid/pid, stdin/out across applications and not exiting am immediately but waiting for called app to say so. Please let me know if you'd need those, though as Termux:Sudo is going to use root access it could grab those from /proc/.../fd directly.

[lars18th]

Hi @michalbednarski ,

Thank you for your description and well analyzed response.

However, the target of such Termux:Sudo App isn't a strong security environment for root in Termux. It only targets a simple method for launching root processes inside Termux without granting Termux in SuperSU/MagiskSU. This makes Termux safe like now, but enables you (the user) to call tools with root privileges if you need it.

If the security model can be improved after this tool exists, then it will be welcome. At time, we only need a more secure option that the current tsu-script and termux-sudo.

Regards.

[Auxilus]

+1 for the idea, @lars18th am I correct that what you are proposing is similar to Ubuntu (when you enter command with root privs, it asks password)?

@Grimler91 wouldn't it be similar to termux-api in the sense that termux calls for a script, and script returns the sensor values for example? Similarly we can call to grant root access, if the password is correct then termux::Sudo would send +ve reply...

[Grimler91]

@Auxilus I know too little about android to know if it would work or not.

This termux:sudo idea is very interesting nevertheless!

[ghost]

@lars18th

The communication will be done using the same technique used in Termux:API: https://github.com/termux/termux-api See "How API calls are made through the termux-api helper binary" (that is using two sockets as PIPEs, one for STDIN and one for STDOUT).

The socket would not allow file access. The executables (all programms in Termux) are in the private directory of the main Termux App. Another App would be unable to access it. It would be only possible to outsource calling builtin Android system binaries with root permissions using a helper or to copy a few files into the other App for executing (but you can't automatically predict which files are needed and copying all would be a bit slow + applying changes from the Sudo App back to the main Termux App is complicated).

However, a good solution would be a confirmation dialog with the executed command shown by the Sudo Helper App. That would be safe because it happens in the other app.

[freebrowser1]

(three years later...) Now sudo and su do work in Termux after I let Magisk grant root access to Termux, but I use it sparsely. However, it would be nice (and secure !) that these commands (su, tsu, sudo) to run as root have a password.

The only way to work around this is granting root access each time you really need 'run as root' from Termux.

[ghost]

However, it would be nice (and secure !) that these commands (su, tsu, sudo) to run as root have a password.

Termux doesn't restrict file system access. As soon as you are able to access the original su binary, all passwords in su, tsu, sudo wrappers would be useless. This has to be implemented on Magisk or other root manager level.

[freebrowser1]

Well, I found out that when I revoked permanent root access to Termux, Magisk now prompts every time when I run su / tsu / sudo in Termux. When I click 'yes' I have access for this session only and that is also a secure way to use root shells.