Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firefox DBus user socket was not found #3769

Open
lupusbytes opened this issue Nov 22, 2020 · 20 comments
Open

Firefox DBus user socket was not found #3769

lupusbytes opened this issue Nov 22, 2020 · 20 comments

Comments

@lupusbytes
Copy link

Bug and expected behavior

  • Describe the bug.
    Firefox does not start, instead it prints:
Reading profile /etc/firejail/firefox.profile
Reading profile /etc/firejail/whitelist-usr-share-common.inc
Reading profile /etc/firejail/firefox-common.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-runuser-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
DBus user socket was not found.
No proxies specified
  • What did you expect to happen?
    Firefox starting

No profile and disabling firejail
Firefox works just fine without firejail

Reproduce
Steps to reproduce the behavior:

  1. Run in bash firejail firefox

Environment

  • Linux distribution and version (ie output of lsb_release -a, screenfetch or cat /etc/os-release)
    Gentoo Linux, Kernel 5.9.9
  • Firejail version
    firejail version 0.9.65

Compile time support:
- AppArmor support is disabled
- AppImage support is enabled
- chroot support is enabled
- D-BUS proxy support is enabled
- file and directory whitelisting support is enabled
- file transfer support is enabled
- firetunnel support is disabled
- networking support is enabled
- overlayfs support is enabled
- private-home support is enabled
- private-cache and tmpfs as user enabled
- SELinux support is disabled
- user namespace support is enabled
- X11 sandboxing support is enabled

Additional context
Other context about the problem like related errors to understand the problem.
I think the issue started after my latest kernel upgrade, to 5.9.9 from 5.9.6.

debug output
OUTPUT OF firejail --debug firefox
Autoselecting /bin/bash as shell
Building quoted command line: 'firefox'
Command name #firefox#
Found firefox.profile profile in /etc/firejail directory
Reading profile /etc/firejail/firefox.profile
Found whitelist-usr-share-common.inc profile in /etc/firejail directory
Reading profile /etc/firejail/whitelist-usr-share-common.inc
Found firefox-common.profile profile in /etc/firejail directory
Reading profile /etc/firejail/firefox-common.profile
Found disable-common.inc profile in /etc/firejail directory
Reading profile /etc/firejail/disable-common.inc
Found disable-devel.inc profile in /etc/firejail directory
Reading profile /etc/firejail/disable-devel.inc
Found disable-exec.inc profile in /etc/firejail directory
Reading profile /etc/firejail/disable-exec.inc
Found disable-interpreters.inc profile in /etc/firejail directory
Reading profile /etc/firejail/disable-interpreters.inc
Found disable-programs.inc profile in /etc/firejail directory
Reading profile /etc/firejail/disable-programs.inc
Found whitelist-common.inc profile in /etc/firejail directory
Reading profile /etc/firejail/whitelist-common.inc
Found whitelist-runuser-common.inc profile in /etc/firejail directory
Reading profile /etc/firejail/whitelist-runuser-common.inc
Found whitelist-var-common.inc profile in /etc/firejail directory
Reading profile /etc/firejail/whitelist-var-common.inc
conditional BROWSER_DISABLE_U2F, nou2f
conditional BROWSER_DISABLE_U2F, private-dev
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
DISPLAY=:0 parsed as 0
DBus user socket was not found.
starting xdg-dbus-proxy
sbox exec: /usr/bin/xdg-dbus-proxy --fd=8 --args=9
Dropping all capabilities
Drop privileges: pid 25925, uid 1000, gid 1000, nogroups 1
No supplementary groups
lupus@thinkpad ~ $ No proxies specified
@rusty-snake
Copy link
Collaborator

#3689

@lupusbytes
Copy link
Author

Reading from the other issue i found

As a workaround dbus-user none might work.

This also seems to work for me

Where does it listen? /run/user/UID/bus?

I have a directory called /run/user/1000/dbus-1 is that what you mean ?

@rusty-snake
Copy link
Collaborator

What files are in /run/user/1000/dbus-1?

What's the output of echo $DBUS_SESSION_BUS_ADDRESS? If it is empty, does DBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus-1/BUS firejail firefox work? (Replace BUS with bus or user_bus_socket or whatever is inside this directory).

@lupusbytes
Copy link
Author

What files are in /run/user/1000/dbus-1?

# tree /run/user/1000/dbus-1/
/run/user/1000/dbus-1/
└── services

What's the output of echo $DBUS_SESSION_BUS_ADDRESS?

nothing.

If it is empty, does DBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus-1/BUS firejail firefox work? (Replace BUS with bus or user_bus_socket or whatever is inside this directory).

DBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus-1/services firejail firefox makes firefox able to start, but with multiple warnings like
** (process:2950): WARNING **: 18:29:33.150: Failed to connect to bus: Address element ?/run/user/1000/dbus-1/services? does not contain a colon (:)

Note that I am running Gentoo Linux with OpenRC and not systemd. The distribution in the other bug #3689, is also using OpenRC. Could this be related ?

@rusty-snake
Copy link
Collaborator

/run/user/1000/dbus-1/
└── services

If that's not a socket, ignore the rest of this comment.

DBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus-1/services firejail firefox makes firefox able to start, but with multiple warnings like … ?/run/user/1000/dbus-1/services? does not contain a colon (:)

Sorry I give you the wrong format. Right is DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/dbus-1/services. wruc (whitelist-runuser-common.inc) maybe intervene too.

Note that I am running Gentoo Linux with OpenRC and not systemd. The distribution in the other bug #3689, is also using OpenRC. Could this be related ?

It is pretty sure the same reason. As both have DBUS_SESSION_BUS_ADDRESS not set and don't use one of the hardcoded paths. If it works with the env-var hack above, a DBUS_USER_SOCKET_FORMAT3 would likely fix it.

#define DBUS_USER_SOCKET_FORMAT "/run/user/%d/bus"
#define DBUS_USER_SOCKET_FORMAT2 "/run/user/%d/dbus/user_bus_socket"

@lupusbytes
Copy link
Author

Sorry I give you the wrong format. Right is DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/dbus-1/services. wruc (whitelist-runuser-common.inc) maybe intervene too.

I'm unsure how to use whitelist-runuser-common.inc
I tried setting whitelist ${RUNUSER}/dbus-1 and whitelist ${RUNUSER}/dbus-1/services but they don't seem to have an effect.

$ DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/dbus-1/services firejail firefox
Reading profile /etc/firejail/firefox.profile
Reading profile /etc/firejail/whitelist-usr-share-common.inc
Reading profile /etc/firejail/firefox-common.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-exec.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-runuser-common.inc
Reading profile /etc/firejail/whitelist-var-common.inc
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
Parent pid 14525, child pid 14528
Warning: An abstract unix socket for session D-BUS might still be available. Use --net or remove unix from --protocol set.
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
Child process initialized in 112.14 ms
Warning: an existing sandbox was detected. /usr/bin/firefox will run without any additional sandboxing features

** (process:14526): WARNING **: 20:22:23.783: Failed to connect to bus: Could not connect: Connection refused

** (process:14526): WARNING **: 20:22:23.998: Failed to connect to bus: Could not connect: Connection refused

** (process:14526): WARNING **: 20:22:24.312: Failed to connect to bus: Could not connect: Connection refused

There is no existing sandbox running when I execute the firejail command. I verified this with firejail --list
Do you have other things to try ?

@rusty-snake
Copy link
Collaborator

There's no "DBus user socket was not found. No proxies specified" anymore, so it seems that firejail can no find the DBus user socket and firefox gets "Connection refused".

If firejail --dbus-user=filter --dbus-user.own=org.mozilla.firefox --noprofile firefox works, the firefox.profile needs to be tweaked. If not, we need to dig in the environment. firejail --dbus-user=filter --dbus-user.own=org.mozilla.firefox --noprofile bash and then echo $DBUS_SESSION_BUS_ADDRESS should show unix:path=/run/firejail/mnt/dbus/user.

There is no existing sandbox running when I execute the firejail command. I verified this with firejail --list

This happens because the first firefox in $PATH is the firecfg symlink.

@rusty-snake
Copy link
Collaborator

Did some testing in artix OpenRC (was the only OpenRC system I found with live desktop). /run/user/1000/dbus-1/services is a directory. $DBUS_SESSION_BUS_ADDRESS is set, and therefore firejail works. OpenRC usually uses dbus-launch which defaults to abstract sockets AFAICS. There is a ~/.dbus/session-bus/LONG-ID. If you source ~/.dbus/session-bus/LONG-ID && export DBUS_SESSION_BUS_ADDRESS && firejail firefox it should work I think.

@lupusbytes
Copy link
Author

source ~/.dbus/session-bus/LONG-ID && export DBUS_SESSION_BUS_ADDRESS && firejail firefox
I have two different ID's

ls ~/.dbus/session-bus/
1decc0caa1bbc3b7e9f17c4b5c23ff73-0  1decc0caa1bbc3b7e9f17c4b5c23ff73-1

Using the first one works.
How would I go about setting this DBUS_SESSION_BUS_ADDRESS automatically at boot ?
I guess the reason why it's not set is that I'm not using a Desktop Environment, just a very simple tiling window manager called dwm

@rusty-snake
Copy link
Collaborator

How would I go about setting this DBUS_SESSION_BUS_ADDRESS automatically at boot ?

I've no knowledge of OpenRC and X11. I guess one of the X init/start scripts executes dbus-launch which could be modified to eval `dbus-launch --sh-syntax` or similar.


@kris7t can we do anything to make dbus-user filter work in such situation? Or can we only add change it to e.g Warning: DBus user socket was not found. Set DBUS_SESSION_BUS_ADDRESS or dbus-user none/ignore dbus-user filter.

@kris7t
Copy link
Collaborator

kris7t commented Nov 24, 2020

@rusty-snake We can change it to only emit a warning, but that's probably unsafe, because the sandboxed application still has access to the socket.

A better fix would be to try and find the socket in the filesystem somehow. But I don't know how are application supposed to find the socket (unless you eval dbus-launch --sh-syntax). Normally, you'd dbus-launch your whole user session as an argument (if you don't eval dbus-launch --sh-syntax before launching the session instead), I think, which should set the right environmental variables for the sessions. So if someone is using D-Bus, but DBUS_SESSION_BUS_ADDRESS is not set and the session bus socket is not at its well-know location, I think that's a configuration issue in the environment that should be fixed (and not fixing it is potentially dangerous, because there is a D-Bus socket around that sandboxed applications could connect to without any filtering). If I'm wrong and there's some other method for applications to find the session bus, we should add support for that, of course.

This leaves the case where somebody legitimately wants to use firejail in an environment without an active session bus. This is quite tricky, but one solution would be to essentially pgrep for /usr/bin/dbus-daemon (and maybe also dbus-launch) and only emit an error for dbus-user without a DBUS_SESSION_BUS_ADDRESS is there is at least one such process running. Otherwise we may fall back to a warning that D-Bus sandboxing was requested, but the system is currently not using D-Bus.

@lupusbytes
Copy link
Author

I did som reading and found my simple approach of just having dwm in my ~/.xinitrc was not ideal.
I replaced the line with exec dbus-launch --exit-with-session dwm and now echo $DBUS_SESSION_BUS_ADDRESS outputs
unix:abstract=/tmp/dbus-g5jO7666uf,guid=b6f2501f4e39fdd5c91c2e635fbd629d

@rusty-snake
Copy link
Collaborator

ok, IMHO it's then enough to improve the error message.

@seniorm0ment
Copy link

seniorm0ment commented Dec 1, 2020

I just updated my firejail configs, I am having this issue as well, I can't say I entirely understand the above comments.
I am on Artix, using OpenRC.
My old Firecfg profile for Firefox didn't have the dbus lines at the bottom, commenting these out fixed the issue and it works, but I assume they were added for a reason.

Edit: hm, same issue with keepassxc, commenting out the dbus filter line fixed it

Edit 2: looks like changing filter to none (as seen in #3689) works on both keepassxc, and firefox. Is this the ideal solution?

On a sidenote, is there anyway to stay up to date with the new firejail configs, but without them overwriting your original modifications? I havs them in home .config, and it doesn't overwrite them, however I had to manually remove them, run sudo firecfg to get the new ones, or I would have never known it got updated.

@rusty-snake
Copy link
Collaborator

Summary: You need to ensure that $DBUS_SESSION_BUS_ADDRESS is set. You can do this by adding eval `dbus-launch --sh-syntax` or exec dbus-launch --exit-with-session dwm for example to your xinitrc or whatever session start script you have.

Firefox didn't have the dbus lines at the bottom, commenting these out fixed the issue and it works, but I assume they were added for a reason. … commenting out the dbus filter line fixed it

Using dbus-user none is better (more secure) then ignore dbus-user filter if possible (as workaround). dbus-system none need no change.

hm, same issue with keepassxc,

strictly speaking: same issue with all profile containing dbus-user filter.

Is this the ideal solution?

This is more secure then filter, however, it does not work for all programs.

On a sidenote, is there anyway to stay up to date with the new firejail configs, but without them overwriting your original modifications? I havs them in home .config, and it doesn't overwrite them, however I had to manually remove them, run sudo firecfg to get the new ones, or I would have never known it got updated.

Just create a .local in ~/.config/firejail (or /etc/firejail). Example:

echo "blacklist ${HOME}/this_is_private" >> ~/.config/firejail/firefox.local
echo "ignore nodvd" >> ~/.config/firejail/firefox.local

@seniorm0ment
Copy link

I added the second one to my xinit and it didn't work.

sxhkd &
exec bspwm
exec dbus-launch --exit-with-session bspwm

Is my xinit, I tried adding it at the top but it broke my sxhkd.

@kris7t
Copy link
Collaborator

kris7t commented Dec 1, 2020

I think your whole desktop should run in dbus-launch. For example, you make

exec dbus-lauch --exit-with-session ~/.local/bin/desktop-session.sh

your .xinitrc and then put

#!/usr/bin/env bash
sxhkd &
exec bspwm

into ~/.local/bin/desktop-session.sh.

Although if you wanted to be fancy, I guess something like

exec dbus-launch --exit-with-session bash <<EOF
sxhkd &
exec bspwm
EOF

would also work.

@seniorm0ment
Copy link

I did the latter (EOF), it seems to have worked, I swapped the profiles back to filter and they launch.
I am curious though, should I have an output for the echo dbus sessipn address? As it is currently empty, as it was previously.

Also is there any chance you could provide a ELI5 explanation as to why the dbus commands were added to the configs, and how they're used? I'm not too familiar with dbus, however I haven't seen anyone else do this (dbus launch script), they generally just use xinitrc withojt a dbuslaunch line either. It looks like dbus is rather important, which makes me wonder why things worked fine before (ignoring the lines being added to firejail configs, I mean my system itself didn't have issues without my desktop running in dbus):

@rusty-snake
Copy link
Collaborator

Also is there any chance you could provide a ELI5 explanation as to why the dbus commands were added to the configs, and how they're used?

D-Bus is a great way to escape from a sandbox. That's why firejail 0.9.54 added the nodbus command to block the session bus. Since 0.9.60, this command blocks the system bus too. Firejail 0.9.64 split this in dbus-user none (block session bus) and dbus-system none (block system bus) because there are a lot programs which require the session bus but don't need/use the system bus. In addition firejail 0.9.64 added dbus-(user|system) filter to use xdg-dbus-proxy to allow access to the session/system bus, but only for whitelisted names.

I am curious though, should I have an output for the echo dbus sessipn address? As it is currently empty, as it was previously.

Either you made a typo or dbus-launch added a socket to one of the hardcoded places.

@kris7t
Copy link
Collaborator

kris7t commented Dec 1, 2020

Another key point is that it's much better to run with a D-Bus server in your session (systemd user sessions start one anyways) than without, because then at least we know where the bus socket is. The point being, if a privileged application (say, a notification daemon) started up a D-Bus user daemon and it placed a socket in some random filesystem location or as a named socket, sandboxed applications could find that socket and potentially escape through it.

So by ensuring that there's a user D-Bus daemon at all times, we know that we only need to control access to it, and not to some other random socket. Of course, privileged applications could just randomly decide to expose some IPC mechanism in a place that's not easily blocklistable for sandboxing, but that's relatively rarer, and such applications would arguably be broken in terms of security. But D-Bus is nearly ubiquitous for in-session IPC (especially in Gnome and KDE), so declaring any application that uses it broken is untenable.

Note that accidentally starting a D-Bus daemon within a sandbox is much less dangerous, because we could only use it break into a sandbox, not out of, and oftentimes the socked wouldn't even be visible outside the sandbox due to allowlisting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants