[GH-ISSUE #3952] firefox: cannot communicate with keepassxc #2470

Closed
opened 2026-05-05 09:09:21 -06:00 by gitea-mirror · 26 comments
Owner

Originally created by @NetSysFire on GitHub (Feb 6, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3952

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

  • The profile (and redirect profile if exists) hasn't already been fixed upstream.
  • The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
  • 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.
  • Used LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 PROGRAM to get english error-messages.
  • I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
Originally created by @NetSysFire on GitHub (Feb 6, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/3952 **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](https://archive.archlinux.org/packages/f/firejail/firejail-0.9.58-1-x86_64.pkg.tar.xz), 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 `diff`ed 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](https://github.com/netblue30/firejail/blob/master/etc/inc/firefox-common-addons.inc#L70) 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](https://github.com/netblue30/firejail/tree/master/etc). - [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.
Author
Owner

@ghost commented on GitHub (Feb 7, 2021):

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 096d0de5f8 as the offending commit.

<!-- gh-comment-id:774589411 --> @ghost commented on GitHub (Feb 7, 2021): > 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](https://bugs.archlinux.org/task/69523) 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](https://gist.github.com/glitsj16/51dc1d2585616d9b53e00beec6a4b7a8) 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](https://bugs.archlinux.org/task/69523) mentions https://github.com/netblue30/firejail/commit/096d0de5f8bb253d0c1035796464bc5982f06f81 as the offending commit.
Author
Owner

@rusty-snake commented on GitHub (Feb 7, 2021):

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.

👍

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.

<!-- gh-comment-id:774647586 --> @rusty-snake commented on GitHub (Feb 7, 2021): > 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.
Author
Owner

@rusty-snake commented on GitHub (Feb 7, 2021):

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.

<!-- gh-comment-id:774717729 --> @rusty-snake commented on GitHub (Feb 7, 2021): 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.
Author
Owner

@NetSysFire commented on GitHub (Feb 7, 2021):

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.

<!-- gh-comment-id:774741497 --> @NetSysFire commented on GitHub (Feb 7, 2021): 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.
Author
Owner

@ghost commented on GitHub (Feb 7, 2021):

@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.

<!-- gh-comment-id:774747816 --> @ghost commented on GitHub (Feb 7, 2021): @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.
Author
Owner

@NetSysFire commented on GitHub (Feb 7, 2021):

@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.

<!-- gh-comment-id:774753378 --> @NetSysFire commented on GitHub (Feb 7, 2021): @glitsj16 I tested this for you: I put `ignore include whitelist-runuser-common.inc` into `firefox.local` and it *also* worked. The [file](https://gist.github.com/glitsj16/51dc1d2585616d9b53e00beec6a4b7a8) 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.
Author
Owner

@guillaume-uH57J9 commented on GitHub (Feb 7, 2021):

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
<!-- gh-comment-id:774756084 --> @guillaume-uH57J9 commented on GitHub (Feb 7, 2021): 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 ```
Author
Owner

@qinohe commented on GitHub (Feb 9, 2021):

@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

<!-- gh-comment-id:776110374 --> @qinohe commented on GitHub (Feb 9, 2021): @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
Author
Owner

@rusty-snake commented on GitHub (Feb 9, 2021):

@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.

<!-- gh-comment-id:776113224 --> @rusty-snake commented on GitHub (Feb 9, 2021): @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.
Author
Owner

@qinohe commented on GitHub (Feb 9, 2021):

@rusty-snake, I understand, thanks.

<!-- gh-comment-id:776131478 --> @qinohe commented on GitHub (Feb 9, 2021): @rusty-snake, I understand, thanks.
Author
Owner

@nidamanx commented on GitHub (Feb 13, 2021):

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!

<!-- gh-comment-id:778628490 --> @nidamanx commented on GitHub (Feb 13, 2021): > 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!
Author
Owner

@rusty-snake commented on GitHub (Feb 13, 2021):

@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?

<!-- gh-comment-id:778629801 --> @rusty-snake commented on GitHub (Feb 13, 2021): @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?
Author
Owner

@nidamanx commented on GitHub (Feb 13, 2021):

@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
<!-- gh-comment-id:778640094 --> @nidamanx commented on GitHub (Feb 13, 2021): > @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 ```
Author
Owner

@rusty-snake commented on GitHub (Feb 13, 2021):

a145bf9119 has changed the socket name.

<!-- gh-comment-id:778642980 --> @rusty-snake commented on GitHub (Feb 13, 2021): https://github.com/keepassxreboot/keepassxc/commit/a145bf91191f0a4630a7e31654aff8a8dfd09bf0 has changed the socket name.
Author
Owner

@nidamanx commented on GitHub (Feb 13, 2021):

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)

<!-- gh-comment-id:778643784 --> @nidamanx commented on GitHub (Feb 13, 2021): 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)
Author
Owner

@ghost commented on GitHub (Feb 17, 2021):

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.

<!-- gh-comment-id:780311495 --> @ghost commented on GitHub (Feb 17, 2021): > 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.
Author
Owner

@rusty-snake commented on GitHub (Feb 17, 2021):

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

<!-- gh-comment-id:780356394 --> @rusty-snake commented on GitHub (Feb 17, 2021): It works always except if you have some other `whitelist ${RUNUSER}/foo` in the include chain.
Author
Owner

@ghost commented on GitHub (Feb 17, 2021):

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!

<!-- gh-comment-id:780364259 --> @ghost commented on GitHub (Feb 17, 2021): > 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!
Author
Owner

@rusty-snake commented on GitHub (Feb 17, 2021):

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.

<!-- gh-comment-id:780368648 --> @rusty-snake commented on GitHub (Feb 17, 2021): 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.
Author
Owner

@ghost commented on GitHub (Feb 17, 2021):

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)

<!-- gh-comment-id:780380076 --> @ghost commented on GitHub (Feb 17, 2021): > 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)
Author
Owner

@nidamanx commented on GitHub (Feb 17, 2021):

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.

<!-- gh-comment-id:780477241 --> @nidamanx commented on GitHub (Feb 17, 2021): > 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.
Author
Owner

@ghost commented on GitHub (Feb 17, 2021):

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.

<!-- gh-comment-id:780492822 --> @ghost commented on GitHub (Feb 17, 2021): > 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](https://aur.archlinux.org/packages/bitwarden_rs-sqlite/) and if you need the Web Vault interface the combo [bitwarden_rs-git](https://aur.archlinux.org/packages/bitwarden_rs-git/) + [bitwarden_rs-vault-git](https://aur.archlinux.org/packages/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.
Author
Owner

@ghost commented on GitHub (Apr 16, 2021):

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 ...

<!-- gh-comment-id:820844333 --> @ghost commented on GitHub (Apr 16, 2021): 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 ...
Author
Owner

@rusty-snake commented on GitHub (Apr 16, 2021):

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.

<!-- gh-comment-id:820929578 --> @rusty-snake commented on GitHub (Apr 16, 2021): 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.
Author
Owner

@ghost commented on GitHub (Apr 16, 2021):

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
<!-- gh-comment-id:821039708 --> @ghost commented on GitHub (Apr 16, 2021): 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 ```
Author
Owner

@qdii commented on GitHub (Jun 13, 2024):

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
<!-- gh-comment-id:2164885116 --> @qdii commented on GitHub (Jun 13, 2024): 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 ```
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2470
No description provided.