Plugins without shared UID #2921

tareksander · 2022-08-05T15:43:09Z

This adds a bound service plugins without a shared UID can use.
closes #2654

How it works:

Plugins can connect to the service
After connecting, they have to register themselves as a client by providing a Binder for callbacks (and for Termux to watch when the plugin process dies, so resources can be released)
After that, the plugin can call the other methods of the service

As an alternative to providing a Binder, clients can also specify a bound service Termux will then bind to to call the callback methods. Plugins can use this prevent themselves from getting killed in the background without having to clutter the notification area with another foreground service notification.

Security Model:

From the Termux side:
- The bound service is protected with a new dangerous permission for plugins, so only apps the user granted the permission can use the service
- All file methods check if the path is in the plugin directory, so no arbitrary file read/write can occur
- The runTask method is additionally secured with the RUN_COMMAND permission
- The service keeps track of which plugin started which task, and plugins can only send signals to their own tasks
From the plugin side:
- I made a library that abstracts away the lower level communication with the service a bit and adds security checks
  - Before connecting to the service, it checks if the signature for the Termux app matches one of the google play, github or fdroid signatures.
  - The callback binder checks if the calling app is Termux on the first transaction, and also checks the Termux app signature
  - Callback services can be secured with a new signature permission Termux defines. This ties the signature into the Android permission system. After getting called, the plugin also has to verify the signature of the Termux app, to tie the permission to the actual signature. This is done in the callback binder by default.

I tested the security aspects, paths outside the plugin directory are rejected, absolute paths are interpreted with the plugin directory as the root. Limiting runTask to apps that have the RUN_COMMAND permission also works. Plugins refuse to connect to Termux if the signature doesn't match.

Features:

Each plugin gets a directory with its package name under /data/data/com.termux/files/apps/plugins and some methods to manage it
- Opening files for reading and/or writing
- Creating and listening on socket files
If the plugin has the RUN_COMMAND permission: A new way to run tasks, using pipes for arbitrarily long input and output
- A way to send signals to the task
- A callback for when the task exits/is killed

The features are deliberately minimal and designed to work with programs in Termux to use the sockets and files.

Client Perspective

The client checks if the filesystem socket exists and is connectable.
- If not, activate the plugin with am or termux-am broadcast and wait until connection succeeds.
Communicate with the plugin however you want through the socket and files in the plugin dir.

Plugin Perspective

Plugin is activated through any means, possibly a broadcast by a client package in Termux.
Plugin connects to the plugin service in Termux.
- Plugin specifies a callback binder: The plugin has to manage not getting killed on its own, likely with a foreground service.
- Plugin specifies callback service: The plugin can specify the binding priority Termux will use to control how likely it it to be killed by Android.
The plugin can now set up filesystem sockets to listen to and manipulate files in its plugin directory.
If the plugin also has the RUN_COMMAND permission, it can also run commands through the plugin service, with piped std* streams.

Termux Perspective

Termux acts as a broker between the plugins and client packages.
It manages the filesystem sockets for the plugin (because you can't pass a filesystem server socket to other apps) and forwards connected clients to the plugin.
It also provides a new task type for plugins that gets displayed as a task in the UI, with streams forwarded to the plugin, only if the RUN_COMMAND permission is held by a plugin.
Care is taken to keep the list of active plugins valid, plugins are removed when the callback binder/service dies, and filesystem sockets are stopped.

CruelCritic · 2022-10-04T15:28:45Z

Why hasn't this been merged already?
@agnostic-apollo isn't even needed.

agnostic-apollo · 2022-10-04T15:53:03Z

@agnostic-apollo isn't even needed.

Things specially like this with security issues don't get merged without proper review and testing.

I did review it couple of weeks back and even with a quick look I did, it had quite a few issues, which I need to fix before this can be merged. I also have to push my local changes first, some of which are required by this pull, which I will do in next few days, mostly done with what I had to do, but lot of testing is required due to tonne of changes and some docs updates.

CruelCritic · 2022-10-04T16:56:09Z

bruh 💀
ig that's my bad on not knowing how PR properly work.

I thought if it's bad, then it just gets rejected.

agnostic-apollo · 2022-10-05T06:54:55Z

I thought if it's bad, then it just gets rejected.

This pull request is not bad that it gets rejected/closed. The design should likely work and overall good work by @tareksander, but needs a deeper look. There are just issues that need to be fixed, initial implementations usually do have issues.

cgarz · 2023-12-08T02:50:31Z

Is this still being considered?

It would be very nice to be able to use termux-gui for my scripts without having to switch from F-Droid. Especially since then I wouldn't need to worry about termux-dialog and the termux/termux-api#297 issue anymore.

agnostic-apollo · 2023-12-08T06:19:01Z

This is planned to be available in next major app release.

khimaros · 2024-03-23T22:46:42Z

@agnostic-apollo @tareksander is this still happening?

was this fix committed in another PR?

according to termux/termux-gui#4 (comment) this should fix termux/termux-gui#4

agnostic-apollo · 2024-03-23T23:11:15Z

Read my comment above. And no, not merged elsewhere.

…o send and receive file descriptors over UNIX sockets as ancillary data.

…signature permission com.termux.permission.TERMUX_SIGNATURE, PluginService bound service for plugins. The methods for PluginService are defined in AIDL in the new module plugin-aidl. The module can be imported by plugins to get the method definitions. The TERMUX_PLUGIN permission is needed to bind to the PluginService, and external apps have to be enabled in the config. AIDL methods: setCallbackBinder and setCallbackService: Used to get a Binder for the PluginService to identify each plugin and get notified when it dies. runTask: Runs a command as a Termux task in the background if the caller also has the RUN_COMMAND permission. listenOnSocketFile: Creates a server socket in the app directory for the plugins (TermuxConstants#TERMUX_APPS_DIR_PATH/<package name>) and returns the file descriptor, which can be used for a LocalServerSocket. openFile: Opens a file in the app directory for the plugin and returns the file descriptor.

…es/apps/plugins`.

…ission error. listenOnSocketFile() now doesn't send the server socket, but sends the client sockets via new socketConnection() callback.

…lugin system.

…n not updating for NativeShell tasks. Added taskFinished callback for plugins and signalTask method for plugins to call.

…lback services, fixed callback services, fixed plugin UID accidentally being set to the PID.

… on my machine.

agnostic-apollo · 2024-03-26T15:53:40Z

termux-shared/src/main/java/com/termux/shared/android/BinderUtils.java

+ if (packageName == null) {
+ return null;
+ }
+ return TermuxConstants.TERMUX_PLUGINS_DIR_PATH + "/" + packageName;


This will cross UNIX_PATH_MAX (108) for long package names of termux forks or external apps. Check TERMUX__APPS_DIR_MAX_LEN and TERMUX__ROOTFS_DIR_MAX_LEN at following links. The sub directory hierarchy needs to change too. I haven't given much thought into it, but it could be handled by using package name itself and seeing if limit will cross for socket file, and if it does, then generate a shorter random identifier. Whatever is chosen on first connection will be saved in shared preferences, and the selected app data directory can be queried by the plugin app.

https://github.com/termux/termux-packages/wiki/Termux-file-system-layout#file-path-limits

Avoid executing ELF files directly termux-exec#24 (comment)

I don't think it's a major problem: /data/data/com.termux/files/apps/plugins/very.long.termux.plugin.name.with.a.filesystem.socket/socket.sock would be the limit, but maybe we could drop the plugins from the path to get a few more characters, package names are unique anyways. Or move the while thing up and even drop the files. And if it gets extreme you could only use one letter for the socket name instead of something more descriptive.

When you generate short randomized names instead of the package names, one problem would be that the client binaries also need to get the name. You'd have to put a mapping file somewhere for them to read.

The TERMUX__APPS_DIR_MAX_LEN is chosen as 84 based on the 12, 13, 14, 16, 17 and 18 examples.

Check them, it will easily cross. And termux forks matter too, so /data/data/very.long.termux.fork.name/ matters too. And /data/user/xx for secondary users or /mnt/expand for adoptable sd are far more easy to cross. I need to think about every possible use case and for any future changes, not just current termux one.

You'd have to put a mapping file somewhere for them to read.

You mean like /data/data/com.termux/shared_prefs/plugin-apps-mappings.xml? :p

I hadn't thought it from that case, but will have to think on it too, lots to think about and do.

Why do you need to know the package name? Don't third party apps already know their package names? They can always export an environment variable for it too.

However, termux app will write to an apps/i/termux/termux-apps.env file for all the variables of the other termux apps whenever a package is installed/uninstalled/updated. Current way of exporting them when creating shell doesn't work for variables for version names, etc as app could get installed/uninstalled/updated after shell was created, so variables are invalid. So shell scripts will source the file when they want to read an app specific variable. I was thinking of adding variables for currently bound third apps too, so one could find the right variable for the uid of the app by comparing against id -u, and then get package name by generating a variable name with the same prefix as uid variable and reading it. A singular variable could also be provided with info for all the apps in some specific format.

Using socket servers to read app variables has a lot of latency, so cannot be used for time sensitive scripts like termux-api ones, lot of the time gained from using termux-am-socket would be lost if two servers are connected to, but sourcing a file is instant.

Why do you need to know the package name? Don't third party apps already know their package names?

So programs inside Termux that use the plugin know where to look. Third party apps running commands is just one use case.

Then they can do the reverse, find the variable for package name and then its uid and then generate the path, we can provide a helper script for it too. Or a single json variable with package names as keys and nested dict with values like path.

Even a json file could work.

I like the idea of a JSON file, it's more useful in case you don't use bash, so you can't just source the env file.

That should be fine for plugins, not for termux apps itself, as parsing json with jq in an external call and is heavy and a dependency on the jq package, termux-api scripts and others require ms level efficiency, so sourcing is significantly faster. Could add info to both an env file and json file and clients can decide themselves.

agnostic-apollo · 2024-03-26T15:57:21Z

There are quite a few other issues, but I do not have time to get into them now, and cannot get distracted with this anyways. Will look into it all after the pre release, this should be there for the main release, I think this design should work, but have to give a deeper look.

tareksander requested a review from agnostic-apollo August 5, 2022 15:43

theotheroracle mentioned this pull request Oct 3, 2022

Can't install from f-droid termux/termux-gui#4

Open

agnostic-apollo force-pushed the master branch from 21804bc to 3f7a939 Compare October 3, 2022 23:49

tareksander mentioned this pull request Nov 23, 2022

termux:gui not installed? tareksander/termux-gui-python-bindings#1

Closed

tareksander mentioned this pull request Mar 25, 2024

[Feature request] Getting rid of sharedUserId termux/termux-api#668

Open

tareksander added 10 commits March 26, 2024 09:04

Added: Methods sendFD and readFD with sendFDNative and readFDNative t…

f3ebad8

…o send and receive file descriptors over UNIX sockets as ancillary data.

Changed: The plugin directory is now under `/data/data/com.termux/fil…

d690e61

…es/apps/plugins`.

Fixed: listenOnSocketFile() permission parameter error.

dd246a6

Changed: Listening to a socket from listenOnSocketFile() gives a perm…

9bc59ac

…ission error. listenOnSocketFile() now doesn't send the server socket, but sends the client sockets via new socketConnection() callback.

Added: NativeShell as a task runner that is only available ofer the p…

44267d6

…lugin system.

Added|Fixed: NativeShell now works, fixed the Termux task notificatio…

f459ee4

…n not updating for NativeShell tasks. Added taskFinished callback for plugins and signalTask method for plugins to call.

Added|Fixed: Added the option to specify the binding priority for cal…

b1fe382

…lback services, fixed callback services, fixed plugin UID accidentally being set to the PID.

Fixed: Fixed build error from using the old env variable system.

ecf4f4a

Fixed|Changed: Updated Gradle version and AGP, the old one didn't run…

7ea61ee

… on my machine.

tareksander force-pushed the plugin-system-rebase branch from 1c98e03 to 7ea61ee Compare March 26, 2024 14:02

agnostic-apollo reviewed Mar 26, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Plugins without shared UID #2921

Plugins without shared UID #2921

tareksander commented Aug 5, 2022 •

edited

CruelCritic commented Oct 4, 2022

agnostic-apollo commented Oct 4, 2022

CruelCritic commented Oct 4, 2022

agnostic-apollo commented Oct 5, 2022

cgarz commented Dec 8, 2023

agnostic-apollo commented Dec 8, 2023

khimaros commented Mar 23, 2024

agnostic-apollo commented Mar 23, 2024

agnostic-apollo Mar 26, 2024

tareksander Mar 26, 2024

tareksander Mar 26, 2024

agnostic-apollo Mar 26, 2024 •

edited

agnostic-apollo Mar 26, 2024

agnostic-apollo May 21, 2024 •

edited

tareksander May 21, 2024

agnostic-apollo May 21, 2024 •

edited

tareksander May 21, 2024

agnostic-apollo May 21, 2024

agnostic-apollo commented Mar 26, 2024

Plugins without shared UID #2921

Are you sure you want to change the base?

Plugins without shared UID #2921

Conversation

tareksander commented Aug 5, 2022 • edited

How it works:

Security Model:

Features:

Client Perspective

Plugin Perspective

Termux Perspective

CruelCritic commented Oct 4, 2022

agnostic-apollo commented Oct 4, 2022

CruelCritic commented Oct 4, 2022

agnostic-apollo commented Oct 5, 2022

cgarz commented Dec 8, 2023

agnostic-apollo commented Dec 8, 2023

khimaros commented Mar 23, 2024

agnostic-apollo commented Mar 23, 2024

agnostic-apollo Mar 26, 2024

Choose a reason for hiding this comment

tareksander Mar 26, 2024

Choose a reason for hiding this comment

tareksander Mar 26, 2024

Choose a reason for hiding this comment

agnostic-apollo Mar 26, 2024 • edited

Choose a reason for hiding this comment

agnostic-apollo Mar 26, 2024

Choose a reason for hiding this comment

agnostic-apollo May 21, 2024 • edited

Choose a reason for hiding this comment

tareksander May 21, 2024

Choose a reason for hiding this comment

agnostic-apollo May 21, 2024 • edited

Choose a reason for hiding this comment

tareksander May 21, 2024

Choose a reason for hiding this comment

agnostic-apollo May 21, 2024

Choose a reason for hiding this comment

agnostic-apollo commented Mar 26, 2024

tareksander commented Aug 5, 2022 •

edited

agnostic-apollo Mar 26, 2024 •

edited

agnostic-apollo May 21, 2024 •

edited

agnostic-apollo May 21, 2024 •

edited