Cannot connect to sandboxed (Flatpak or Snap) browser

[ghost]

keepassxreboot/keepassxc/issues/2656

[AsavarTzeth]

In this case the problem is that you are using an isolated Firefox instance (Flatpak version). In other words, you currently must use a native (traditional) distribution package for Firefox. That is a package that is not sandboxed.

Here are the limitations of the current working solution in more detail:

• Firefox must be able to write to its usual home directories, i.e. ~/.mozilla, in the real home directory.
• Firefox (or KeePassXC-Browser if you will) must be able to launch keepassxc/keepassxc-proxy (effectively the same thing, since both are packaged as org.keepassxc.KeePassXC).
  • That means Firefox must be able to launch another app, i.e. from the host, which is not possible from within the sandbox. Allowing it to do so unacceptable, which is why Firefox cannot be sandboxed.
  • The path used to launch org.keepassxc.KeePassXC must be a single absolute path (no spaces allowed), i.e. no flatpak run org.keepassxc.KeePassXC. This is not a problem since Flatpak exports wrappers (by default in /var/lib/flatpak/exports/bin).

I have spent countless hours exploring other (more proper) ways of making all of this work, but they all end with a brick wall. The current solution is the only compromise that works at all. Other solutions may work, but requires changes to either one or all of: KeePassXC, KeePassXC-Browser, Firefox (and others) or even Flatpak.

[AsavarTzeth]

By the way, unfortunately your "Possible Solution" does not work. Extensions are more like mounts in the same container, making it a good fit for libraries and plugins. It won't work with executables that need to be launched from the host.

In any case, Firefox still needs a way to execute it, which still is not possible from within the sandbox.

For the record, way back, I did try packaging org.keepassxc.KeePassXC.Proxy both as an extension and as a regular flatpak in order to learn about this.

[ghost]

What about DBUS activation?

[AsavarTzeth]

Would that work without allowing Firefox to talk to, or own org.keepassxc.KeePassXC? I am no D-Bus expert, but I assume not. There would likely be some sandbox issue. Anyone feel free to correct me if I am wrong.

Anyhow, it currently makes no difference since the browser extension can only communicate via stdio. In a perfect world the Native Messaging API would support D-Bus too. Presumably that would make D-Bus activation feasible.

You can find some very good documentation on Native Messaging here:

• https://wiki.mozilla.org/WebExtensions/Native_Messaging
• https://developer.chrome.com/extensions/nativeMessaging#native-messaging-host

I imagine if it was supported, the native messaging host manifest could contain: type: dbus.

Although an ideal solution, it may not be a realistic expectation. All browsers would have to support it and it would likely be a Linux (and BSD) specific solution. That is important to consider, since both KeePassXC and Web Browsers support Windows and MacOS as well.

In that case, perhaps a portal (xdg-desktop-portal) could be implemented to act as a generic stdio-to-dbus proxy? Not sure about the details, or if it is even possible; just an initial idea.

[varjolintu]

Anyone who searchs for a workaround:

Create a wrapper script /var/lib/flatpak/exports/bin/org.keepassxc.KeePassXC.proxy with the following content:

#!/bin/sh
exec /usr/bin/flatpak run --command=keepassxc-proxy org.keepassxc.KeePassXC "$@"

Make the script executable with chmod +x and then change the Use a custom proxy location to point this script.

[mauvm]

@varjolintu This worked, thank you!

I had to make one small change though, since my Firefox config file (~/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json) contained the path without .proxy. So I named the file: /var/lib/flatpak/exports/bin/org.keepassxc.KeePassXC

[Ramblurr]

16 days ago @AsavarTzeth committed a patch to this repo removed the ability to specify the custom proxy location with this note:

org.keepassxc.KeePassXC/patch/keepassxc/0003-Support-KeePassXC-Browser-Flatpak-environments.patch

Lines 26 to 28 in 7d976c9

	- The browser cannot be sandboxed or it will not be able to execute
	commands in the host namespace; i.e. a "native" distribution
	package, or possibly an AppImage.

However this seems to contradict what @varjolintu stated and @mauvm confirmed, that there is a workaround to make flatpak'ed keepassxc and flatpak'ed Firefox communicate.

Were they mistaken?

Interestingly, in the latest keepassxc flatpak, I do have the file /var/lib/flatpak/exports/bin/org.keepassxc.KeePassXC and it contains

exec /usr/bin/flatpak run --branch=stable --arch=x86_64 org.keepassxc.KeePassXC "$@"

which, notably, doesn't have the --command=keepassxc-proxy that @varjolintu suggests.

[varjolintu]

@Ramblurr By quickly looking at the patch after line 102, it seems it could find the proxy without any further configuration.

Maybe that code could be included in to the official codebase too, if it really works.

[Ramblurr]

@varjolintu Hm, interesting. Do you have a working keepassxc - firefox integration, when both are flatpaked (using this latest keepassxc flatpak release)?

[AsavarTzeth]

However this seems to contradict what @varjolintu stated and @mauvm confirmed, that there is a workaround to make flatpak'ed keepassxc and flatpak'ed Firefox communicate.

No they were not mistaken. That is an error in the commit message. Thank you for finding it! It should say:

- The browser cannot be sandboxed (installed as a Flatpak) or it
  will be unable execute commands and use stdio on the host
  namespace; i.e. browsers must be installed from a "native"
  distribution package or possibly an AppImage.

The KeePassXC installation method does not matter, the browser installation method still does. I will make sure to correct that error in the commit message.

which, notably, doesn't have the --command=keepassxc-proxy that @varjolintu suggests.

It doesn't because that is currently impossible. Flatpak apps can only have a single command exported as a wrapper, which is the command set in the manifest. I workaround that using this wrapper, which automatically uses keepassxc-proxy when needed.

This is the only way to make it work by default, without changing flatpak, or flatpak-builder itself. Here is one issue related to this: flatpak/flatpak#1638

[AsavarTzeth]

@Ramblurr By quickly looking at the patch after line 102, it seems it could find the proxy without any further configuration.

Maybe that code could be included in to the official codebase too, if it really works.

That and the automatic proxy work is the main motivation for the recent reworking of the patches.

The main blocker now is time and real life issues that must take precedence.

[varjolintu]

@AsavarTzeth Thanks for the good work.

Hm, interesting. Do you have a working keepassxc - firefox integration, when both are flatpaked (using this latest keepassxc flatpak release)?

@Ramblurr Like already answered above, it will not work (for now). I've also received a lot of issues where browser is installed via snap. The same sandbox problems exists with it too.

[AsavarTzeth]

If you're wondering what is missing to for this particular issue to be closed I know of only two possible solutions.

1. Ideally browser vendors would complement stdio with a DBus based Native Messaging type. A user friendly portal could be built around this, which would ask if say Firefox is allowed to communicate with KeePassXC via DBus. This should work well with any sandbox solution, but it involve changes to flatpak (and snap), xdg-portals, keepassxc, and all browsers.

2. Browsers are modified to optionally support native messaging using the HostCommand method of the org.freedesktop.Flatpak.Development interface. However this is intended for development tools, such as Gnome Builder and it severely compromises the sandbox security. Naturally that is bad for a web browser.

I don't consider myself an expert and these ideas may be flawed. I have thought about it for a long time though.

[fixinggunsinair]

One year passed by. Firefox released an official Flatpak-version on Flathub, but this one is still an issue. :(

[rugk]

This is a tough problem, given we have three layers of sandboxing that do not make it easy to interact.

So here is how I understand the current

status

• KeePassXC can be installed from a flatpak, thanks to patches etc. browsers should be able to start it
• However, the browser needs to be able to run flatpak run – it cannot do that when it is inside a flatpak

workaround (tries – failed)

This uses the new official Firefox flatpak from flathub.

• So when you compile/create the proxy as a separate binary, e.g. the rust version, you can build a separate proxy binary, which is conveniently only one file.
• Put that into a correct place and edit the native messaging manifest in ~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json to point to that binary. Maybe you need to adjust the path. (E.g. put the binary next to ~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/.
• This way, the proxy application can launch _inside- of the Firefox flatpak. Firefox can then start the proxy binary inside of the flatpak.
• Now the step where I still fail is to get the Unix socket file in both flatpaks being accessible.
• You can patch the proxy to use a different path, like this: https://gist.github.com/rugk/dd545705f94ed116343b9cfae4427df1
• And you can install KeePassXC outside of a flatpak to get to the $XDG_RUNTIME_DIR/kpxc_server file.

Still did not got it to work, because just symbolic linking these files to the correct destination did not work. Also hardlinking $XDG_RUNTIME_DIR/kpxc_server to $XDG_RUNTIME_DIR/app/org.mozilla.firefox/kpxc_server (with the unpatched proxy) did not work.

Another workaround would be to pinch a hole in the Firefox sandbox to allow it to spawn other commands on the host, as said before, but I did not try this, given it does not really improve the security in contrast to running a native Firefox installation.

Proper solution

Anyway, a proper solution could be:

• to have a DBUS or portal for that generic things (unlikely)
• to have a special proxy that uses another communication method. (HTTP server or DBUS or so) That could be at least a drop-in solution (you might still have to place the proxy binary somewhere; or it has to be shipped with Firefox, which is unlikely). The communication is encrypted, so that should be no problem.

That said, if that workaround mentioned before could be made possible, this would already help a lot. E.g. maybe the flatpak can get a permission to read this socket? I don't know the flatpak permissions in such a detail to know how to do this.

[AsavarTzeth]

Very interesting @rugk, perhaps we could do the following:

1. Patch the rust version of the proxy to have its unix socket listening at XDG_RUNTIME_DIR/app/org.mozilla.firefox/kpxc_server.
   This path is available to org.mozilla.firefox and the host, but not org.keepassxc.KeePassXC (but that can be fixed. See bellow).

2. Add the missing permissions to org.keepassxc.KeePassXC. This should suffice: --filesystem=xdg-run/app/org.mozilla.firefox:ro.

3. Although we can't ship the proxy with firefox directly, they might accept a flatpak extension. Of course that will still require the addition of extension points to org.mozilla.firefox. Hopefully they find it an acceptable compromise.

The one thing that won't be possible is having KeePassXC automatically configuring the native host manifest. Adding a permission won't work in this case because no app is ever allowed to read another ones app data (under ~/.var/app).
Perhaps the suggested Flatpak extension (3.) could include a setup or wrapper script that edits the manifest?

Did I miss anything? You seem well informed of all the issues and the permission issue should be simple enough to solve. The toughest issue is perhaps getting the proxy binary shipped, but perhaps an extension will be accepted, opposed to shipping it with Firefox directly.

[rugk]

1. AFAIK that should be the default path. It actually uses $XDG_RUNTIME_DIR/app/$FLATPAK_ID, i.e. $XDG_RUNTIME_DIR/app/org.mozilla.firefox by default. So I expected it to be there.
2. I have not looked into how exactly the KeePassXC flatpak chooses the location, but it's also $XDG_RUNTIME_DIR/kpxc_server, which is of course a different folder for the KeePasssXC flatpak it's $XDG_RUNTIME_DIR/app/org.keepassxc.KeePassXC/kpxc_server.. (just checked in file manager: yep, it's there)
   So this would then actually require a patch of KeePassXC…

[AsavarTzeth]

1. I agree. That is the proper path and should be the default for this flatpak, assuming we get all of this to work in a simple and integrated manner.
   However, if by "it" you are referring to the rust proxy then it appears to use $XDG_RUNTIME_DIR by default, rather than $XDG_RUNTIME_DIR/app/$FLATPAK_ID.

2. The KeePassXC flatpak does indeed use $XDG_RUNTIME_DIR/app/org.keepassxc.KeePassXC by default, as a part of current browser integration patch (which only works with non-sandboxed browsers). Since I am the author and maintainer of that patch it is a non-issue to update it again.

Note! Flatpak still sets XDG_RUNTIME_DIR=/run/user/$UID. So $XDG_RUNTIME_DIR does not equal $XDG_RUNTIME_DIR/app/$FLATPAK_ID which means the latter is never used by default, unless explicitly set to do so.

[rugk]

Okay yeah, did not thought about the last thing.

Anyway, I've tried it in the other way around, i.e. keeping the file in the $XDG_RUNTIME_DIR/app/org.keepassxc.KeePassXC dir (because that's easer for me as I don't have to patch KeePassXC) and then adding a permission to Firefox to access that (if your command works that has to be sudo flatpak override --filesystem=xdg-run/app/org.keepassxc.KeePassXC:ro org.mozilla.Firefox.
However, for some reason, it still cannot access the

Rust proxy patch: https://gist.github.com/rugk/01caaf238ae1e667c67f7b53a9e782e2

A big problem is I cannot test how that looks from inside of the flatpak enter is broken.
Oh no, use flatpak run --command=/bin/sh org.mozilla.firefox instead.

Okay, by doing so, I can see the permission overwrite is not working. Firefox cannot see the other dirs other than it's own org.mozilla.firefox in $XDG_RUNTIME_DIR, even though it has these:

$ flatpak override --show org.mozilla.Firefox
[Context]
filesystems=xdg-run/app/org.keepassxc.keepassxc:ro;xdg-run/app/org.keepassxc.KeePassXC:ro;

Propbably you just cannpt specify it like this?

[rugk]

Ah, but sudo flatpak override --filesystem=xdg-run/kpxc_server:ro works for Firefox, so if you use a native installation, it can see kpxc_server at least.
That said, I… ah of course I need to change the proxy application.

But yeaah! That worked! 🎉 (and it needs no patch for the proxy)

So the issue is just it has to be installed natively, which is bad, of course.

[rugk]

Aaaand… it also works with the flatpak, if you'd go cd $XDG_RUNTIME_DIR and create a symbolic link to that ln -s app/org.keepassxc.KeePassXC/kpxc_server . (I tested a hardlink first, but a symbolic llink also works for me.)

With the already mentioned overwrite for FF, FF can read the socket file. 🎉

Now… we only have one problem: AFAIK /run is temporarily mounted, so at each reboot all files (including our required symbolic link) are gone.
Or you just find another writable location for both KeePassXC and Firefox…

[rugk]

If further investigated this issue:

• Good news: it works without any overrides at all! If you have that symbolic link in place, for some reason Firefox can access and see the app/org.keepassxc.KeePassXC dir!
  However, some little bad news: The symblink needs to be in place before Firefox starts.
• bad news: If I place the symbolic link in any user dir (~/.var/org.mozilla.firefox) it does not work; for some reason I did not got it to work
• bad news: (but obviously a security feature) if I try to create this inside if the KPXC flatpak, it is only sandboxed and does not even appear outside if the flatpak

[rugk]

That said, I think I've found a way to make that workaround work persistently. I'll do a full writeup later… 😃

[varjolintu]

@rugk Nice work!

[rugk]

Early 2020's: We've got a working workaround. For those following this thread here in short the news:

• I got the symbolic link to be permanent by creating a config file for systemd-tmpfiles
• Problem 1: The socket file needs to exist before Firefox is started, otherwise it does not get read-only access/it mounted inside of the sandbox.
• Problem 2: Somehow I saw that the whole solution may break existing other connection possibilities, like when you run Firefox not in a sandbox. (need to investigate why though)

Here the full workaround, posted in different places:

• Fedora Community
• Unix Stackexchange
• Flathub forum (to be added soon)

[t2d]

Awesome work @rugk! I can confirm that the workaround is working on Ubuntu 20.04 with Firefox flatpak and KeePassXC flatpak.

[AsavarTzeth]

Interesting fact. I actually managed to reproduce your workaround last week. But instead I used only Flatpaks, a patched proxy and successful overrides under XDG_RUNTIME_DIR/app (no symlinks). Just like we wanted it.

However the very same day I did a reset, because I wished to try it the other way around. But since then I too have broken overrides. In fact no filesystem overrides have worked for me since. It would be interesting to ask some flatpak devs if what the intended behaviour is.

In general it has been my personal experience, now and in the past, that filesystem overrides sometimes can be unreliable. Hopefully that is specific to my system.

[rugk]

Okay, that is strange, that could explain why I did not seem to override directly in $XDG_RUNTIME_DIR/app. Definitively needs more investigation though…

As I explained somewhere, I could also only get write access into the $XDG_RUNTIME_DIR/app dir with overrides. Though that would be enough if you patch KeePassXC and the proxy.

[rugk]

Okay, using it for some time, I still see some problems:

• apparently I was wrong with the :ro -> it cannot find passwords there (maybe the extension cannot write into the socket?), omitting that seems to fix it
• It is surprisingly unreliable and I have websites, where it keeps getting disconnected, when I click on "re-detect login fields" it then disconnects, when I click reconnect, it connects again etc. (so it constantly reconnect/disconnects in a loop if I click that button)

It's throwing me all kinds of strange errors:

Interestingly that depends on the website I request the password for. For some it just does not work.

Does anybody know what could cause this?

[BeatLink]

Any updates on this?

[zroug]

Probably not a good final solution because it gives Firefox the ability to execute commands outside of its sandbox but a relatively clean, quick and reliable workaround:

1. Give Firefox the ability to execute commands outside of its sandbox. (flatpak override --user --talk-name=org.freedesktop.Flatpak org.mozilla.firefox)
2. Place a file with the content below somewhere where Firefox can read it and make it executable. (I used ~/.var/app/org.mozilla.firefox/data/keepassxc-helper)
3. Point to this file in ~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json. (Use an absolute path.)

Content of keepassxc-helper:

#!/bin/sh
exec flatpak-spawn --host flatpak run org.keepassxc.KeePassXC "$@"

Content of org.keepassxc.keepassxc_browser.json:

{
    "allowed_extensions": [
        "[email protected]"
    ],
    "description": "KeePassXC integration with native messaging support",
    "name": "org.keepassxc.keepassxc_browser",
    "path": "/home/username/.var/app/org.mozilla.firefox/data/keepassxc-helper",
    "type": "stdio"
}

[AsavarTzeth]

@zroug Is that a complete workaround? You're right that it won't be accepted as a solution. I very much doubt browser package maintainers would allow that permission or extensions that rely on it.

In Firefox's case I'm not sure if they have even added the necessary flatpak extension points that I would need.

But as a workaround for savvy users it might suffice, for now. As long as they understand what it means.

[zroug]

Yes that should be a complete workaround. But as @rugk has already mentioned here, it completely disables the Flatpak sandbox if something is aware of Flatpak. So only choose this workaround if you are okay with this, otherwise you should use his workaround.

[AsavarTzeth]

Good. I just wanted to make sure you and anyone else reading this always is informed about that fact.

[Ramblurr]

@rugk Unfortunately I think the workaround is broken now :(

Firefox fails to start when $XDG_RUNTIME_DIR/kpxc_server symlink exists. With or without :ro in the override makes no difference.

$  flatpak run org.mozilla.firefox
bwrap: Can't make symlink at /run/user/1000/kpxc_server: File exists

The only way to get firefox to boot is to remove that symlink. But then firefox creates its own symlink inside its container (that isn't visible on the host) and so it can never follow the host symlink even if you re-create it after starting FF.

• firefox flatpak 93.0
• flatpak 1.12.1

[rugk]

Uff, thanks for the information. Feel free to comment that on the other places, where I have posted it. That's really unfortunate…

[masiv1001]

Tried with both workarounds and none of them work, using firefox v.93.0, also tried with Librewolf without success.

[zroug]

I think the flatpak-spawn workaround should still work, at least it does for me.

[Ramblurr]

I think the flatpak-spawn workaround should still work, at least it does for me.

Yes, it probably does but that totally breaks the sandbox security model. So for me at least, it's not a viable workaround. I'd rather copy and paste from KeepassXC manually

[WineBottles]

Hi @rugk thanks for all of your work on this issue.

I followed your guide found here https://discourse.flathub.org/t/how-to-run-firefox-and-keepassxc-in-a-flatpak-and-get-the-keepassxc-browser-add-on-to-work/437 and got it "working".

There were 2 extra things I needed to do to get it working and 2/3 issues to resolve to get it in an acceptable phase for me personally.

What I needed to do different:

1. this command "sudo flatpak override --filesystem=xdg-run/kpxc_server:ro org.mozilla.firefox" never actually did anything for me personally so I had to manually add xdg-run/kpxc_server in flatseal for Firefox.

2. I had to run "systemd-tmpfiles --user --create" as the one commentor pointed out. Restarting after putting the config file in the user-tmpfiles.d directory did nothing.

Then there are 2 (really 3, but 1 I can overlook) issues I am facing:

1. This one I could probably work around with a start-up script although I am curious why I need to do it in the first place: I need to run "systemd-tmpfiles --user --create" after every single reboot or I the connection doesn't work. it doesn't matter if KeePassXC started before FireFox or not.

2. This one is a deal breaker: While this makes the connection work between the two, for some reason after I close Firefox once, I can never reopen it again unless I fully reboot my computer. Not even logging out and back in helps. When I look at journalctl all it says is
   systemd[1429]: Started app-flatpak-org.mozilla.firefox-3258.scope.
   systemd[1429]: Started app-flatpak-org.mozilla.firefox-3269.scope.
   systemd[2106]: Started app-flatpak-org.mozilla.firefox-2691.scope.
   over and over again for each click I do on the task manager icon. There are no further logs of a crash or anything so I am at a loss with that.

I am 100% sure the cause is the connection between KeePassXC and Firefox because when I don't run the "systemd-tmpfiles --user --create" command to get them connected, then I can close and re-open Firefox as many times as I want.

3. This one I can overlook but it's meh: The connection between the two flatpak packages seems flaky for some reason and gets disconnected at random times. I do have the experimental setting checked off in KeePassXC browser plugin to autoreconnect os I think that fixes it for the most part. Some websites just reload the keepassxc icon on the login field indefinitely without me being able to actually use it though.

Again thanks for all of your work on this.

[rugk]

Thanks for the addendum, yeah really complicated O have to say but thanks you shared that and great you got it working in "some" way somewhat at least.

[tazihad]

please keepassxc team needs to look into this.

I tried the https://discourse.flathub.org/t/how-to-run-firefox-and-keepassxc-in-a-flatpak-and-get-the-keepassxc-browser-add-on-to-work/437
It works for the first time after reboot. But when I reboot the flatpak firefox. I get this error.

bwrap: Can't make symlink at /run/user/1000/kpxc_server: File exists

So, I think this needs an official solution.

[spacemule]

Just a little addition to @zroug's solution:

If keepassxc is not running in flatpak, change the content of keepassxc-helper to:

#!/bin/sh
exec flatpak-spawn --host keepassxc-proxy "$@"

[droidmonkey]

This is not a problem with the Flatpak, xdg-desktop-portal is coming out with Native Messaging support and reports it works with FireFox Snap Beta