firefox: cannot access keepassxc with addon

[NetSysFire]

Bug and expected behavior

The newest profiles break the KeePassXC Firefox addon. I verified that Firefox (and not KeePassXC) is the application causing problems by running them with and without a sandbox. It started to work again when I ran Firefox without a sandbox.

No profile and disabling firejail Running it without Firejail works. I downloaded an older package, and copied firefox*.profile to ~/.config/firejail/ to force it to use the old profiles. It worked again.

Reproduce Steps to reproduce the behavior:

• Make sure to use the latest version of Firefox, Firejail and KeePassXC (also its browser addon)
• Open Firefox, the extension will complain about the fact that it can not connect

Environment

• Distro: Arch Linux
• Firejail version: 0.9.64.2-1 I compared the checksums of the relevant profiles contained in the Arch Linux package and the ones in the git repo. I verified that these are the latest profiles.

Additional context

I diffed the old, confirmed working profiles (although I had some U2F problems, I had to make sure my yubikey was plugged in before starting the browser), encountered a comment and began working on my overrides (.local). I tried putting this in firefox-common-addons.local:

private-bin keepassxc-proxy
include whitelist-runuser-common.inc

but unfortunately this did not resolve this issue (with the newest profiles of course). I suspect it is either related to the newly introduced dbus-filtering or to a now inaccessible socket location, which is why I tried adding that whitelist include into my override. I could not get any useful debug output from Firefox or KeePassXC and there are not any blacklist violations in my journal. Let me know if there is anything else I can do to debug this, but I have no clue about all the dbus filtering.

Checklist

• [x] The profile (and redirect profile if exists) hasn't already been fixed upstream.
• [x] The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
• [x] I have performed a short search for similar issues (to avoid opening a duplicate).
• [ ] If it is a AppImage, --profile=PROFILENAME is used to set the right profile.
• [x] Used LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 PROGRAM to get english error-messages.
• [x] I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.

[glitsj16]

I tried putting this in firefox-common-addons.local:

private-bin keepassxc-proxy include whitelist-runuser-common.inc

Haven't gotten around to debug this properly yet (I have a very customized Firefox setup on Arch), but by looking at the profiles involved I would want to make two remarks.

First, adding keepassxc-proxy to private-bin assumes you have a firefox.local that also uses private-bin for the other relevant commands to run Firefox (as indicated by the comment in firefox.profile). If you didn't do that, don't add any private-bin command(s) to your firefox-common-addons.local.

Secondly, I think we might have a problem in firefox-common-addons.inc. Another Arch Linux user reported firefox profile breakage on the Arch bug tracker. I've only just seen that, but it looks related to this issue IMO. I assume that's the reason why you tried adding 'include whitelist-runuser-common.inc' again to counter it being ignored in firefox-common-addons.inc. That logic is sound IMO. Please download this file as ${HOME}/.config/firejail/firefox-common-addons.inc and try again.

@rusty-snake Can you remember why we ignore include whitelist-runuser-common.inc in firefox-common-addons.inc? The Arch bug report mentions https://github.com/netblue30/firejail/commit/096d0de5f8bb253d0c1035796464bc5982f06f81 as the offending commit.

[rusty-snake]

First, adding keepassxc-proxy to private-bin assumes you have a firefox.local that also uses private-bin for the other relevant commands to run Firefox (as indicated by the comment in firefox.profile). If you didn't do that, don't add any private-bin command(s) to your firefox-common-addons.local.

:+1:

Can you remember why we ignore include whitelist-runuser-common.inc in firefox-common-addons.inc?

3767

TL;DR: KeePassXC uses a socket ($XDG_RUNTIME_DIR/org.keepassxc.KeePassXC.BrowserServer) for communication to the browser addon. This path is hardcoded, so we can not add any env hacks. Because this is a socket direct under ${RUNUSER} rather in a sub-directory, firefox can only access it if keepassxc was started before firefox. If you then restart keepassxc, firefox only has a dead socket.

[rusty-snake]

I added it because it has better protection then the blacklist in disable-common.inc and sockets in $XDG_RUNTIME_DIR can likely be used to escape the sandbox. I didn't add it in earlier because it was not possible to ignore include whitelist-runuser-common.inc, instead you needed a ignore for every whitelist ${RUNUSER}. If this is too much breakage, we can comment it.

@NetSysFire it should work if you add whitelist ${RUNUSER}/org.keepassxc.KeePassXC.BrowserServer to firefox.local and start KeePassXC before firefox and keep it open as long as you run firefox. A KeePassXC instance started after firefox is started will not work.

Or you ignore include whitelist-runuser-common.inc, then it should work. No matter in which order you start and stop the sandboxes.

[NetSysFire]

I tested both solutions: The override in firefox-common-addons.inc @glitsj16 suggested did not work unfortunately. But adding the whitelist directive just like @rusty-snake suggested works. Thanks for your help!

I agree that whitelisting the entire dir can potentially lead to a sandbox escape but luckily KeePassXC is already running before Firefox in 99% of the cases here, so it will not affect me.

[glitsj16]

@NetSysFire Glad you have a working solution! What follows is just my own confusion, but it would be awesome if you could confirm/deny.

I tried putting this in firefox-common-addons.local

Or you ignore include whitelist-runuser-common.inc, then it should work. No matter in which order you start and stop the sandboxes.

As the OP mentioned firefox-common-addons.local I assumed that they saw the comment in firefox-common.profile to allow access to common programs/addons/plugins and has 'include firefox-common-addons.inc' in a firefox-common.local override. The firefox-common-addons.inc file already contains 'ignore include whitelist-runuser-common.inc', so - if I understand @rusty-snake correctly - that should have worked no? @NetSysFire Can you try/confirm that please? Apologies for being a bit confused here, but I think it might be relevant to the aforementioned Arch Linux bug report. If in fact KeePassXC can only be made to work by adding whitelist ${RUNUSER}/org.keepassxc.KeePassXC.BrowserServer to firefox.local, I think we need to stress that via a comment in the firefox.profile.

[NetSysFire]

@glitsj16 I tested this for you:

I put ignore include whitelist-runuser-common.inc into firefox.local and it also worked. The file you wanted me to download to ~/.config/firejail/firefox-common-addons.inc did not work. I have not touched firefox-common.local.

I am also confused right now, I don't get in which order these things are applied, which might also have been the issue here.

[guillaume-uH57J9]

My system is also affected. This local change fixes it for me:

$ cat /etc/firejail/firefox-common.local 
# KeePassXC Browser Integration
whitelist ${RUNUSER}/org.keepassxc.KeePassXC.BrowserServer

[qinohe]

@NetSysFire , is your issue solved? I'm on Arch too and I have tested the issue again, mine seems to be solved (see)https://github.com/netblue30/firejail/issues/3962

[rusty-snake]

@qinohe everything answer here: https://github.com/netblue30/firejail/issues/3952#issuecomment-774717729. This is expected to break without user changes. The only unresolved question is if we should revert this change.

[qinohe]

@rusty-snake, I understand, thanks.

[nidamanx]

I added it because it has better protection then the blacklist in disable-common.inc and sockets in $XDG_RUNTIME_DIR can likely be used to escape the sandbox. I didn't add it in earlier because it was not possible to ignore include whitelist-runuser-common.inc, instead you needed a ignore for every whitelist ${RUNUSER}. If this is too much breakage, we can comment it.

@NetSysFire it should work if you add whitelist ${RUNUSER}/org.keepassxc.KeePassXC.BrowserServer to firefox.local and start KeePassXC before firefox and keep it open as long as you run firefox. A KeePassXC instance started after firefox is started will not work.

Or you ignore include whitelist-runuser-common.inc, then it should work. No matter in which order you start and stop the sandboxes.

Unfortunately, both solutions didn't work on Debian 10. To be sure I used firefox.profile and keepassxc.profile from the git (just now)

Without jail, all is fine (and also if I keep in jail only keepassxc).

What works, in the communication between firefox and keepassxc, is the "Perform Auto-Type" from the menu Entries. I have to say that, before the last FireJail Debian backport released few days ago (if I remember well), all was absolutely fine. Another mention is: since months, i'm using the updated Firefox installed in /opt and the location of the .kdbx is in ~/Documents/KeePassXC/ Never had problems since the backport.

Maybe a solution could be to set a custom location for keepassxc proxy? Thanks!

[rusty-snake]

@nidamanx if you start keepassxc (in firejail) and enable Browser-Integration does the KPXC socket show up at /run/user/$UID/org.keepassxc.KeePassXC.BrowserServer?

If so, does firejail --profile=firefox ls /run/user/$UID show it too?

[nidamanx]

@nidamanx if you start keepassxc (in firejail) and enable Browser-Integration does the KPXC socket sow up at /run/user/$UID/org.keepassxc.KeePassXC.BrowserServer?

If so, does firejail --profile=firefox ls /run/user/$UID show it too?

Ah! You're right! I didn't think about it. I was really looking somewhere else!

The answer is no. File not found But I have /run/user/$UID/kpxc_server

...we're on the right way to solve!

---

[SOLVED]

$ cat ~/.config/firejail/firefox.local 
whitelist ${RUNUSER}/org.keepassxc.KeePassXC.BrowserServer
whitelist ${RUNUSER}/kpxc_server

[rusty-snake]

https://github.com/keepassxreboot/keepassxc/commit/a145bf91191f0a4630a7e31654aff8a8dfd09bf0 has changed the socket name.

[nidamanx]

I see. So this is a global fix. Maybe better keep both whitelists for a while (to have a better compatibility with old versions of KeePassXC)

[glitsj16]

Or you ignore include whitelist-runuser-common.inc, then it should work. No matter in which order you start and stop the sandboxes.

@rusty-snake That works for X11 but it breaks Firefox on Wayland unless a user takes care of additionally adding

whitelist ${RUNUSER}/wayland-0
whitelist ${RUNUSER}/wayland-1

And that's only Wayland. Other things explicitly handled in whitelist-runuser-common.inc would need attention too I guess. So for prosperity's sake, I think we should advise users not to mess with that include without expecting some kind of breakage.

[rusty-snake]

It works always except if you have some other whitelist ${RUNUSER}/foo in the include chain.

[glitsj16]

It works always except if you have some other whitelist ${RUNUSER}/foo in the include chain.

True. But as we don't know what a user might have (for example in globals.local) I think it's wise to be cautious with advise on whitelist-runuser-common.inc, that's all I wanted to stress. It was not meant as a personal remark towards your advice given in this thread. Apologies if it sounded that way!

[rusty-snake]

If you have whitelist ${RUNUSER}/foo in globals.local, every wayland program without wruc is broken. Anyway, if we suggest to ignore wruc, it will fail if users have other whitelist ${RUNUSER} commands in the include chain. And if we suggest to whitelist the socket, users must do this restricting workflow. Both are not perfect.

[glitsj16]

Both are not perfect.

No argument there. If only we could advise users to use a more user-friendly password manager instead of KeePassXC... (ducks under his local bitwarden setup)

[nidamanx]

we could advise users to use a more user-friendly password manager instead of KeePassXC... (ducks under his local bitwarden setup)

I partially agree to the suggestion. Good point is: a more user friendly solution Not good point is: pwd will be stored somewhere online (in places we need to trust, but who knows) and to have all features, people need to agree to a plan. Using KPXC gives more freedom,

I think it could be better to follow the best solution we can have now and be prepared to change it in case a better way to solve will be discovered.

[glitsj16]

Not good point is: pwd will be stored somewhere online (in places we need to trust, but who knows) and to have all features, people need to agree to a plan.

That's why I used local bitwarden setup, as in self-hosted. The AUR has several packages that make that relatively easy: bitwarden_rs-sqlite and if you need the Web Vault interface the combo bitwarden_rs-git + bitwarden_rs-vault-git works like a charm. Just sharing info, but I sure can see your point. Choosing a password manager solution will always be a user decision, I'm not arguing in favor of pushing one specific solution via firejail.

[ghost]

Hi

I have still the problem. I have just started to install/learn firejail and atm I try to get keepassxc addon running.

I tried all suggestions here but nothing seems to work. For now I get my setup back to more or less to the default settings the only things what I have changed so far is: /etc/firejail/keepassxc.local

# Database path
whitelist ${HOME}/path/to/the/KeePassfolder/*.kdbx

# Key path
whitelist ${HOME}/.keys/keepass/*.key

# Needed for Firefox-Browser addon
mkfile ${HOME}/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json
whitelist ${HOME}/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json
mkdir ${HOME}/.cache/keepassxc
mkdir ${HOME}/.config/keepassxc
whitelist ${HOME}/.cache/keepassxc
whitelist ${HOME}/.config/keepassxc
include whitelist-common.inc

# Uncomment or add to your keepassxc.local to allow Tray.
dbus-user.talk org.kde.StatusNotifierWatcher
dbus-user.own org.kde.*

# SSH key path
noblacklist ${HOME}/.ssh/*
noblacklist ${HOME}/.keys/.ssh/*
whitelist ${HOME}/.ssh/*
whitelist ${HOME}/.keys/ssh/*

and

/etc/firejail/firefox.local

# Allow internet access
ignore net

# firefox requires a shell to launch on Arch.
private-bin bash,dbus-launch,dbus-send,env,firefox,sh,which

# Allow keepassxc addon
#whitelist ${RUNUSER}/org.keepassxc.KeePassXC.BrowserServer
#whitelist ${RUNUSER}/kpxc_server

#ignore include whitelist-runuser-common.inc

So I uncomment it as well but still no connections ...

[rusty-snake]

From OP: private-bin keepassxc-proxy You enabled private-bin in your firefox.local but did not add keepassxc-proxy, that's likely the issue here.

[ghost]

Yep, that's it! Thanks!

# firefox requires a shell to launch on Arch.
private-bin bash,dbus-launch,dbus-send,env,firefox,sh,which,keepassxc-proxy

# Allow keepassxc addon
whitelist ${RUNUSER}/org.keepassxc.KeePassXC.BrowserServer
whitelist ${RUNUSER}/kpxc_server

[qdii]

On my distrib, /run/user/1000/org.keepassxc.KeePassXC.BrowserServer is a symlink to /run/user/1000/app/org.keepassxc.KeePassXC/org.keepassxc.KeePassXC.BrowserServer, so simply whitelisting the first doesn't work.

What I needed to do to make it work is:

whitelist ${RUNUSER}/org.keepassxc.KeePassXC.BrowserServer
noblacklist ${RUNUSER}/app