Unable to connect native KeePassXC to flatpak Firefox #7352
Comments
|
You cannot use the browser extension when the browser is in a flatpak or snap. It is impossible until they introduce a plug that let's that communication happen. |
I'm confused. This article discusses how to connect KeePassXC and Mozilla Firefox even if both are. I had only did the half part because KeePassXC is native. "Hooray!: For those, who install KeePassXC on the host (without any sandbox/flatpak), this is enough. Start KeePassXC and then Firefox and it should be able to connect. 🎉 |
|
That isn't posted by our team and I have no idea if it still works. You are on your own here. |
|
Unfortunately there is no native Firefox anymore with Ubuntu 22.04. Even if you install from packet with apt, you end up with a snap. So what now? |
|
Petition canonical if you want a simple solution. Snaps ain't it. |
|
@zeitisen Take a look at this guide: Maybe try Fedora in the future. It is very stable, more up to date and has no snap crap. There are many installation guides and reviews in the internet (including YouTube). I hope that Flatpak Firefox can handle KeePassXC in the future. Thanks to the developers anyway. I know that Canonical does weird things, but I think that the users should not be blamed for not doing a new install of another distro. Lets help euch other :) |
|
Ran into this same issue in the last few weeks, as I transitioned my 2012 MacBook Pro from macOS Catalina (10.15.7) to Ubuntu 22.04.1. My solution was to: 1.) Uninstall snap entirely (https://github.com/MasterGeekMX/snap-to-flatpak) Once Firefox and KeePassXC were installed, I added KeePassXC-Browser to Firefox ... and KeePassXC and Firefox connect as designed; indeed, this setup works pretty much the same as it did on macOS. Other thoughts: I should note that Firefox (and Thunderbird, which I installed using the same method) receives its updates internally (going to Help > About Firefox or Help > About Thunderbird). This may not be standard Linux behavior, but it was normal under macOS (and I actually prefer it) and thus is "more of the same" for me. Having all three apps installed and working properly (without the need for either snap or flatpak) was an important goal for me ... and this browser extension issue forced me to find a solution that would work independent of those environments. EDIT (8/23/23): This setup continues to work for me today (running Ubuntu 22.04.3), and specifically works while running Wayland (re noisystuff's post below). Although I haven't tested it with other Linux distros, it should work with KeePassXC installed via any standard package manager (apt, dnf, pacman, et cetera). It also worked for me using the AppImage version of KeePassXC, which I didn't really expect to work, but it did. Above, droidmonkey said "Petition canonical if you want a simple solution. Snaps ain't it." I would say much the same about Flatpak. This is one use case where I think sandboxing hurts more than it helps. |
|
It would be very nice to have the way to connect keepassxc to sandboxed browser. |
|
Hi Folks. |
|
I followed the initially mentioned guide (also on Stack Exchange) a few days ago and since it didn't work at first because the paths are outdated, I did some research and it seems like one really just needs two things today: Allow the sandboxed Firefox to access KeePassXC's socket and copy the
I believe that KeePassXC could do steps 2 and 3 automatically with a new "Firefox (Flatpak)" browser type. Step 1 surely needs some documentation, but truly isn't that big of a deal. There's one limitation though: The sandboxed Firefox can't start KeePassXC. Thus the user must start KeePassXC themselves. This is a permanent limitation for now. However, there's yet another, a little more annoying, but probably solvable limitation: KeePassXC must even be started before Firefox (this also means: if one restarts KeePassXC, one must also restart Firefox). I'm not entirely sure whether this is a limitation of KeePassXC, the browser extension, Since Besides, I'm aware that a native messaging portal has been suggested as a permanent, fully functional and "native" (in the sense of "not requiring workarounds") solution. However, it has been three years now and still I didn't find anything about its status. Flatpak matured in the past years and is more commonly used, personally I'm even thinking about whether I want to have native apps on my system. So, I guess this might be a working solution for now that could be implemented in KeePassXC? Cc: @droidmonkey @rugk Here's the full instructions for others to get this working in the meantime: # install Firefox and KeePassXC
flatpak install flathub org.mozilla.firefox
flatpak install flathub org.keepassxc.KeePassXC
# create native-messaging-hosts
FLATPAK_FIREFOX_CONFIG="$(realpath ~/.var/app/org.mozilla.firefox/.mozilla)"
mkdir "$FLATPAK_FIREFOX_CONFIG/native-messaging-hosts"
cat > "$FLATPAK_FIREFOX_CONFIG/native-messaging-hosts/org.keepassxc.keepassxc_browser.json" <<EOF
{
"allowed_extensions": [
"[email protected]"
],
"description": "KeePassXC integration with native messaging support",
"name": "org.keepassxc.keepassxc_browser",
"path": "$FLATPAK_FIREFOX_CONFIG/native-messaging-hosts/keepassxc-proxy",
"type": "stdio"
}
EOF
# build varjolintu's keepassxc-proxy-rust and copy it to native-messaging-hosts
# you might need to install Cargo first, but can remove it after building the project again
git clone https://github.com/varjolintu/keepassxc-proxy-rust.git
cd keepassxc-proxy-rust
cargo build --release
cp ./target/release/keepassxc-proxy "$FLATPAK_FIREFOX_CONFIG/native-messaging-hosts/keepassxc-proxy"
# allow the Firefox sandbox to access KeePassXC's browser socket
sudo flatpak override --filesystem=xdg-run/app/org.keepassxc.KeePassXC/org.keepassxc.KeePassXC.BrowserServer org.mozilla.firefox |
|
Placing the proxy within another apps sandbox is not a solution we endorse. It may work but that is definitely not something we will implement. |
What is the reason for that? The proxy doesn't implement any logic on its own, but just connects the application (Firefox) with KeePassXC running in another sandbox. Can you please elaborate on possible security implications and/or other general disadvantages of this solution, especially in comparison with (1) the currently endorsed non-sandboxed approach (i.e. both KeePassXC, or at least Firefox running on the host), and (2) a native messaging portal? Since (1) doesn't include any sandboxing or sandboxing that matters (running KeePassXC in a sandbox protects the host from KeePassXC, not KeePassXC from Firefox) I'd say it causes an overall lower security than the suggested solution? |
|
Interesting solution. I tried to compile it this way and with x86_64-unknown-linux-musl. But it doesn't work. Got error "Key exchange error". Checked everything, permissions, paths.. What could go wrong? Browser extension debug in Firefox says: |
|
@PhrozenByte yeah AFAIK flatpak also supports extensions which are like plugins. In this way, one could ship a Edit: I've pitched this idea to the Mozilla devs in https://bugzilla.mozilla.org/show_bug.cgi?id=1942175 and on Flathub's forum: https://discourse.flathub.org/t/pitch-idea-firefox-flatpak-extension-to-run-keepassxc-with-a-flatpaked-firefox/8673 |
I got the same error when trying this for myself. Would love to get this working |
|
@darkfessing @jeriox You should probably report that directly at https://github.com/varjolintu/keepassxc-proxy-rust, maybe the developer has an idea and can provide a fix. |
The developer seemingly has no interest in making this work.... varjolintu/keepassxc-proxy-rust#23 (comment) |
|
This isn't on us. Flatpak has not yet incorporated the necessary desktop portal for browsers to offer native messaging support. Snap hasn't either, but Firefox basically backdoor implemented it on their snap. The whole thing is a mess, |
this was definitely not my intention, sorry if it came across that way! I just saw the workaround above that was proposed by @PhrozenByte which sounded like a good idea to me and which apparently worked for him. I just hoped for some support to get that running as well. |
|
No worries, my frustration is with Snap/Flatpak and not with anyone here. Pretty crappy to force all browsers into that standard and leave a gaping hole in capability quite a few extensions rely on. |
|
I think you unfortunately misunderstood me: I didn't want to suggest that you ask him whether he wants to support this workaround (remember, I absolutely agree with you that this primarily is an issue of Flatpak and Firefox. They must provide the necessary APIs to integrate this nicely. I can absolutely feel your (and, by proxy, the project's) frustration about the matter, because more and more people want to use Flatpak and consequently ask why it isn't working. The reason I can feel your frustration is because I feel the exact same frustration when looking at flatpak/xdg-desktop-portal#705: Work on the portal started three years ago (!!) and it still didn't make it into Flatpak, even though the code is ready for years now. However, I also feel like that the workaround presented in this GitHub Issue isn't given enough consideration on KeePassXC's side, too. I absolutely agree that the original concept of a workaround (I mean the one that basically meant running KeePassXC from within the Firefox sandbox) wasn't even remotely an option. However, thanks to That is why I asked earlier why you rejected the latest workaround so categorically. I honestly don't see an issue with it, but I could absolutely miss something. Maybe you've provided reasoning elsewhere earlier already, unfortunately I didn't find any even though I definitely looked for it while summarizing @rugk's workaround. I could also massively underestimate the work required. Or you could also say that you (and, by proxy, the project) don't want to invest resources into integrating such workaround, but then whether you'd accept a pull request. That's why I asked for reasoning. I can't and won't ever demand anything from you, we're all participating in our free time here and it's absolutely up to you what you do with your free time, but in my experience not giving at least basic reasoning leads to even more frustration. This should not disguise the fact that it still is a workaround and the problem definitely lies with Flatpak and Firefox. However, making this workaround more accessible would surely reduce frustration on all sides - unless there are good reasons why this workaround is a bad idea in general of course. Yes, none of this is KeePassXC's fault, not even its job, but if KeePassXC could improve the situation, why not do it if it's reasonably possible? Thank you for your help @droidmonkey ❤️ |
|
I rejected it because that is a dangerous precedent to set by injecting binaries into another app's sandbox. Would you like it if a random app injected their stuff into KeePassXC's flatpak or snap sandbox? That is a major violation of the sandbox principles. Sure you can do anything as root, but "with great power, comes great responsibility". |
|
(Not an expert in this, this is just an idea that came to my mind; Please disregard if it completely misses the point;) Would it be feasible to switch the communication between the Browser Addon and the KeepassXC-Instance to use dbus instead of using raw sockets? As far as I understand Flatpak natively understands DBus and permissions can selectively be given to access certain endpoints (and also after installation - with a single command) and show an endpoint to the rest of the system. This would allow the permissions to be tweaked without much fiddling and without an additional proxy inside the sandbox. What I do not know is whether it is possible to make DBus-Calls from a Firefox Addon. |
|
That wouldn't solve anything because browsers do not allow extensions to connect to dbus. The only other solution is to switch back to http based communication which brings its own complications. |
I agree. However, that's true for basically any sandbox portal, and isn't much different from flatpak/xdg-desktop-portal#705. In fact, the current proposal for the portal is way more critical than our workaround, because the portal allows starting processes outside the sandbox from within the sandbox. It can't really get any more critical than that - and is a major reason why the portal still didn't make it into Flatpak: The portal can be abused by an attacker to escape the sandbox and there's no accepted proposal for a security model. In contrast, the workaround only allows for communicating with KeePassXC and requires KeePassXC to run already (which is a major limitation of the workaround). IMHO that's actually less critical than the portal. Or do I miss something?
Depends. If it requires user interaction (which it does, it even requires root permissions) I don't really see much of an issue. More importantly, KeePassXC can't tell the browser sandbox to run that binary and it doesn't "trick" the browser sandbox to run it. The workaround rather works precisely as expected by the Native Messaging API. One might criticize the Native Messaging API that it runs arbitrary binaries, but what am I missing that it is more critical now, but wasn't that much before? Another thing to consider are the alternatives: KeePassXC currently endorses users to not run the browser in a sandbox. Is it safer to not run the browser in a sandbox, than running the browser in a sandbox with this workaround? What am I missing here? |
|
Yes, running the browser in a sandbox is generally preferable from a security standpoint; Though I can understand why the KeepassXC team do not currently endorse this solution: With the current situation, the user needs to download random code from a git repo, compile it and place it somewhere it can be run. Same thing if this was "built in" into KeepassXC: Nevertheless, I'd have to argue that it would be good to at least have an up-to-date guide in the official documentation (with an adequate disclaimer, of course), instead of people who want this having to run commands from random Stack Overflow answers or forum threads. I think, what we'd really want here is a change in firefox itself to expose a better kind of API with which extensions can talk to other programs on the system, even through the flatpak isolation layer. (As far as I know, there has been some talk about something like this, but nothing has materialized yet. Edit: Here: https://bugzilla.mozilla.org/show_bug.cgi?id=1621763) |
|
Pardon my ignorance, but talking to a specific different program on the same machine sounds like the perfect use-case for a socket bound to localhost on a specific port. Has something like that been tried already? Of course, KeePassXC would need to listen on it and the port must be configurable in the extension. Is it possible to allow specific TCP ports on localhost to be accessed from inside the flatpak sandbox? Connection security / authentication can still be handled easily through the pre-shared secret, as it is now with the Native Messaging solution. |
|
The only solution I found is to disable KeepassXC addon in browser and use KeepassXC directly (copy-paste). So much for user experience :) |
|
I've used Flatseal to disable Wayland (socket=wayland) for KeepassXC and Firefox and by forcing them to use Xwayland (socket=x11) as that facilitates using hot-keys and KeepassXC's auto-type feature to populate the browser fields. Okay, it defeats a key security enhancement offered by Wayland (so risking text being captured by a keystroke logger) but my network's pretty well bolted down and I use my head for storing banking passwords (or the likes), so in my case it's a useful solution with a reasonably low risk. Interestingly, I haven't had to change the default Flatseal settings for Linux Edge (socket=x11 and socket=wayland are both enabled) as Edge defaults to using Xwayland. |
|
@noisystuff unfortunately this did not work for me (Ubuntu 24.10). I have both installed as flatpaks, I disabled socket=wayland and left activated socket=x11. I can see from the terminal that my browser is switching to X11, but unfortunately the connection window does not appear when I am trying to connect. I am not sure from keepassxc though if it is switching to x11... I do have an error message "Could not load the Qt platform plugin "wayland" in "" even though it was found", but unsure if that is enough... |
I'm ubuntu 24.10 too. Firefox snap + keepassXC snap works OOTB for me. |
I followed the instructions 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 to expose Firefox/KeePassXC to each other but I am not having luck actually getting them to connect.
Steps to Reproduce
Expected Behavior
Flatpak Firefox should be able to connect to native KeePassXC
Actual Behavior
Clicking on the KeePassXC add-on in my browser bar says:
Going into about:debugging says:
Context
I am not sure if I need to be changing the "browser integration" settings in KeePassXC, as the article I linked at the top here says it should just work. I tried turning off and on integrated with Firefox as well as going into the advanced tab and turning off and on "Use a custom browser configuration location:
When I have "Update native messaging manifest files at statup" it changes
to
So I know that is not as expected and I should probably not use that config.
KeePassXC 2.6.6
Firefox flatpak 96.0.3
Operating System: Arch Linux
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.15.16-hardened1-1-hardened (64-bit)
Graphics Platform: X11
The text was updated successfully, but these errors were encountered: