Usage with sandboxed NM hosts

[PhrozenByte]

When I was thinking about how the new XDG Native Messaging Proxy could be used with KeePassXC, I had some difficulty understanding how it would work with sandboxed Native Messaging (NM) hosts (such as a sandboxed KeePassXC communicating with a sandboxed Firefox browser). Also see keepassxreboot/keepassxc#12327

Since documentation is currently limited, let me recap what I understood about how XDG Native Messaging Proxy works. Please correct me if I'm wrong - I might absolutely be wrong since I'm neither a Flatpak dev, nor a browser dev, not even a C dev in general:

From my understanding the new approach basically means that a xdg-native-messaging-proxy service runs on the host system that implements NM just as if the browser isn't sandboxed. One service handles NM for both Firefox and Chromium at the same time. For non-sandboxed NM hosts basically nothing changes: Applications just have to copy their NM manifest to one of the NM search paths (see service implementation; distributions might force different search paths with the XNMP_HOST_LOCATIONS env variable) as before, xdg-native-messaging-proxy then invokes the NM host binary specified in the NM manifest (just as a non-sandboxed browser would do) and proxies communication to the sandboxed browser via the new org.freedesktop.NativeMessagingProxy DBus interface. In general, nothing needs to be changed code-wise for non-sandboxed NM hosts.

What I don't really understand yet is how xdg-native-messaging-proxy works with NM hosts running within a sandbox:

Is the sandboxed NM host supposed to talk to the xdg-native-messaging-proxy service running on the host system? If yes, how is this accomplished? I neither see how a sandboxed NM host could add NM manifests to the NM search path on the host system, nor methods within the DBus interface to allow sandboxed NM hosts to talk to xdg-native-messaging-proxy via DBus.

Or is the sandboxed NM host supposed to talk directly to the sandboxed browser via the org.freedesktop.NativeMessagingProxy DBus interface (possibly not directly, but using a second xdg-native-messaging-proxy service running within the application's sandbox)? Is it even possible that browsers connect to multiple xdg-native-messaging-proxy instances (e.g. the first running on the host system and the second running within KeePassXC's sandbox) at the same time?

[swick]

What I don't really understand yet is how xdg-native-messaging-proxy works with NM hosts running within a sandbox:

It doesn't. This proxy has the same functionality that was proposed in the portal.

If this is a desired feature, I would suggest to add support for this in xdg-native-messaging-proxy.

Essentially, what needs to be done is discovering manifests for flatpak apps (~/.var/app/$appid/config/native-messaging-hosts, ~/.var/app/$appid/.mozilla/native-messaging-hosts, ...), and then when launching the path specified in those manifests, use flatpak run --command=$path $app-id.

It's not pretty but should get the job done without having to add anything new to flatpak or portals.

[droidmonkey]

From flatpak, writing manifests to the proper configuration folder per browser is a non-issue, and what we currently do. Likewise, those manifests run the correct sandboxed executable using the flatpak run command.

From snap, this is a problem unless your app gets the explicit permission from the snap maintainers to write to "hidden directories". It is possible, but cumbersome.

[swick]

Ah, yes, it is also possible to use --filesystem=~/.config/native-messaging-hosts and then put the manifest with the flatpak run ... line there. Not great either; if ~/.config/native-messaging-hosts doesn't exist, it won't get mounted, so really this needs --filesystem=~/.config and that is a really broad permission.

So IMO it would be better to add support to x-n-m-p to find the manifests "inside" the sandboxes in ~/.var/app instead of relying on the flatpak apps to manage to push it out of the sandboxes.

[PhrozenByte]

I like the idea to let xdg-native-messaging-proxy discover NM manifests within Flatpaks and Snaps and automatically prefix commands with flatpak run resp. snap run. It's simple and more importantly doesn't require any changes on the NM host's side.

However, one open question is whether we want xdg-native-messaging-proxy to discover NM manifests within any Flatpak, or just within Flatpaks that specifically ask for it in their Flatpak manifest (maybe with --allow, or even simpler with --metadata?). This would also allow repos like Flathub to display this as a permission ("Native Messaging: Can talk to a sandboxed web browser" or something like that). Not sure whether this is possible with Snap?

[swick]

We could export the manifests from flatpaks, just like we do for desktop files, icons, etc. The reason why I would prefer to just discover this in the sandbox is that this proxy and the whole concept is a workaround, that ideally works without having to adjust flatpak or portals to it.

[PhrozenByte]

Yeah, sounds reasonable. So, better use --metadata? --metadata seems to allow for arbitrary keys, but --allow seems to be limited to a pre-defined set of features (i.e. would need changes in Flatpak). Maybe --metadata=X-Native-Messaging=XDG-Native-Messaging-Proxy=true then? Not sure whether Flathub et. al. could still display this as a permission, but I guess they could? Whether they display it or not isn't relevant for xdg-native-messaging-proxy though… I just feel like that xdg-native-messaging-proxy shouldn't do this with Flatpaks and Snaps until they ask for it. Adding this to a NM host's Flatpak manifest (like KeePassXC's) shouldn't be a big deal.

swick, can you ping the Snap people? I'm not sure who was participating in the discussion before and I'm also not sure whether they watch this. It kinda impacts them, too. I don't know whether one can add arbitrary keys to meta/snap.yaml (I guess that's their metadata file? I really don't know anything about Snap…).

[swick]

Personally I would be fine with just discovering the manifests of all applications and not just ones which opt-in to that behavior. The elevated permission really is in the app calling the native messaging host, not from whoever provides it. You can equally just provide a dbus service to other apps.

Either way, if you're going to implement this, I'm not stopping you from implementing the opt-in.

[swick]

@jhenstridge @3v1n0 ping for snap

[PhrozenByte]

I'm afraid I'm no C dev (I could help with Python, but that's no help here I guess 🙈), so unfortunately I won't be able to implement any of this 😞 Implementation details like doing so with an opt-in are really just my 2 cents on the topic. Making the proxy work with sandboxed NM hosts in general, no matter as opt-in or not, is most important.

[3v1n0]

Mhmh, so for the snap case I feel that there's no way at the moment to expose a manifest in any well know place without further user approval, I mean, you could use the personal-files-interface enabling the snap to write the manifest in one of these well know locations, and then the user has to manually enable it (unless the store admins allow it to be auto-connected for well reviewed snaps).

So, while such solution would work initially, I feel it would be nicer for have an explicit way to expose such NM hosts, so that snapd would be able to generate the manifest, ensuring that the called binary is confined and everything else (including removal of it on snap removal).