Postman is a tool to help in API Development workflows. We support a feature interceptor using which our users can sync their cookies from their browser (Google Chrome) to our app. To do this, it uses Chrome’s Native Messaging feature. We need access the directory where Chrome is installed and put a manifest file there. You can read more about the feature here: https://learning.postman.com/docs/sending-requests/capturing-request-data/interceptor/#how-it-works
We essentially need to access the ~/.config/google-chrome/NativeMessagingHosts/ location to put our manifest file.
This feature is already working for other platforms where we have this access and even on Linux it is working for the app that we distribute directly from our website (as a tarball) and is broken for the snap variant.
What is Postman Agent then?
Postman is now supported on browsers and it uses a much slimmer native companion app to send the requests which we call “Postman Agent”. It also needs to support the same feature interceptor as mentioned above and hence requires the classic confinement.
We wanted to start with making the new postman-agent as classic app and possibly in future do the same for the postman app as well.
We have registered the following names and want to start testing this capability on them. We request you to allow the classic confinement for these apps:
postman-agent
postman-agent-beta
postman-agent-stage
The beta and stage variants would be used by the internal team.
Please let me know if any more details are required.
If access to the ~/.config/google-chrome/NativeMessagingHosts/ path is all that is required, then this can be achieved via the personal-files interface. However, as postman-agent is not the clear owner of this path it likely would not be granted auto-connect to write to this location. Also would postman-agent want to support users running chromium (whether from the snap or native) - in which case you would also want to support the paths ~/.config/chromium/NativeMessagingHosts/ and ~/snap/chromium/current/.config/chromium/NativeMessagingHosts/? Finally, Firefox may also need to be supported similarly.
Even if you do use either personal-files to access these paths, or classic confinement, postman-agent will only be able to work with browsers that are natively installed (ie you won’t be able to support either the Firefox or Chromium snaps).
The problem here is that if you want to support these browsers which are shipped as snaps, they are strictly confined and so won’t be able to execute the interceptor extension since it will be outside of their sandbox. Perhaps a better solution is some use of a content interface between the a snapped extension (like postman-agent) and the snapped browsers - @oSoMoN@jdstrand would this be feasible?
Yeah, in future we might also support Firefox and other browsers as well. Since using classic-confinement would solve the problem for the natively installed browsers, we would like to start with that.
I don’t know much about the content interface but I think that would need the producer (Chrome in our case) to make some changes which we do not control.
Unfortunately, whilst classic confinement might solve this problem, this is not one of the supported use-cases for classic confinement. The current best-fit would be personal-files and strict confinement (but again this would not work for browsers which themselves are snaps).
Indeed, a content interface would need to be coordinated with the publishers of chromium etc - hence why I pinged @oSoMoN above
@harryi3t@oSoMoN have either of you had any more thoughts on this - specifically the idea of whether trying to get the major snap’d browsers to provide a content interface that would allow other strictly confined snaps to plug into the native messaging interface?
I’m very sorry for the late reply, for some reason this thread went unnoticed in my inbox, despite the repeated pings.
Using a content interface to allow third-party snaps to write to ~/snap/chromium/common/chromium/NativeMessagingHosts/ sounds feasible. Whether it’s a good idea from a security perspective is open for discussion.
Note that a native messaging host placed there by a third-party snap would be executed in the context of the chromium snap, i.e. strictly confined, so it cannot have additional external dependencies, which probably limits the usefulness of such a feature (see e.g. bug #1741074 where chrome-gnome-shell wouldn’t work unmodified because the connector is a python3 script that imports GLib and Gio, and because it talks to the org.gnome.Shell.Extensions D-Bus API, for which there doesn’t exist a snapd interface).
If postman-agent could be made to work in such a context, it could be used as a proof-of-concept. @harryi3t, can you comment on its external dependencies and interactions with the host system?
Another topic relating to decisions around native messaging:
I think the main points to consider from a security perspective:
Letting a snap install a native messaging configuration makes sandbox escape trivial. The configuration file contains a command line that the web browser will execute. If that command line is not a snap command wrapper, then it will be executed without confinement.
Even if they can trivially escape it, strict confinement can be useful for a native messaging service since it will be run in a well known execution environment. The request for system-files or personal-files access should be treated with similar gravity as a classic confinement request, due to the relative ease of escalating to similar privilege.
Having a snapped web browser talk to a snapped native messaging service is probably not going to be possible as a snapped application can not execute another snapped application directly.
@harryi3t - since we’ve not heard back from you, we are removing this request from our review queue. When you have more time to respond, simply do so here and we can add the request back to the queue. Thanks
