mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3769] firefox: DBus user socket was not found #2376
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2376
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lupusbytes on GitHub (Nov 22, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3769
Bug and expected behavior
Firefox does not start, instead it prints:
Firefox starting
No profile and disabling firejail
Firefox works just fine without firejail
Reproduce
Steps to reproduce the behavior:
firejail firefoxEnvironment
lsb_release -a,screenfetchorcat /etc/os-release)Gentoo Linux, Kernel 5.9.9
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
@rusty-snake commented on GitHub (Nov 22, 2020):
#3689
@lupusbytes commented on GitHub (Nov 22, 2020):
Reading from the other issue i found
This also seems to work for me
I have a directory called
/run/user/1000/dbus-1is that what you mean ?@rusty-snake commented on GitHub (Nov 23, 2020):
What files are in /run/user/1000/dbus-1?
What's the output of
echo $DBUS_SESSION_BUS_ADDRESS? If it is empty, doesDBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus-1/BUS firejail firefoxwork? (ReplaceBUSwithbusoruser_bus_socketor whatever is inside this directory).@lupusbytes commented on GitHub (Nov 23, 2020):
nothing.
DBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus-1/services firejail firefoxmakes 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 commented on GitHub (Nov 23, 2020):
If that's not a socket, ignore the rest of this comment.
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.It is pretty sure the same reason. As both have
DBUS_SESSION_BUS_ADDRESSnot set and don't use one of the hardcoded paths. If it works with the env-var hack above, aDBUS_USER_SOCKET_FORMAT3would likely fix it.3a3c1007d7/src/firejail/dbus.c (L36-L37)@lupusbytes commented on GitHub (Nov 23, 2020):
I'm unsure how to use whitelist-runuser-common.inc
I tried setting
whitelist ${RUNUSER}/dbus-1andwhitelist ${RUNUSER}/dbus-1/servicesbut they don't seem to have an effect.There is no existing sandbox running when I execute the firejail command. I verified this with
firejail --listDo you have other things to try ?
@rusty-snake commented on GitHub (Nov 23, 2020):
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 firefoxworks, 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 bashand thenecho $DBUS_SESSION_BUS_ADDRESSshould showunix:path=/run/firejail/mnt/dbus/user.This happens because the first
firefoxin $PATH is the firecfg symlink.@rusty-snake commented on GitHub (Nov 23, 2020):
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_ADDRESSis 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 yousource ~/.dbus/session-bus/LONG-ID && export DBUS_SESSION_BUS_ADDRESS && firejail firefoxit should work I think.@lupusbytes commented on GitHub (Nov 24, 2020):
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 commented on GitHub (Nov 24, 2020):
I've no knowledge of OpenRC and X11. I guess one of the X init/start scripts executes
dbus-launchwhich could be modified toeval `dbus-launch --sh-syntax`or similar.@kris7t can we do anything to make
dbus-user filterwork in such situation? Or can we only add change it to e.gWarning: DBus user socket was not found. Set DBUS_SESSION_BUS_ADDRESS or dbus-user none/ignore dbus-user filter.@kris7t commented on GitHub (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'ddbus-launchyour whole user session as an argument (if you don't evaldbus-launch --sh-syntaxbefore launching the session instead), I think, which should set the right environmental variables for the sessions. So if someone is using D-Bus, butDBUS_SESSION_BUS_ADDRESSis 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
pgrepfor/usr/bin/dbus-daemon(and maybe alsodbus-launch) and only emit an error fordbus-userwithout aDBUS_SESSION_BUS_ADDRESSis 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 commented on GitHub (Nov 24, 2020):
I did som reading and found my simple approach of just having
dwmin my~/.xinitrcwas not ideal.I replaced the line with
exec dbus-launch --exit-with-session dwmand nowecho $DBUS_SESSION_BUS_ADDRESSoutputsunix:abstract=/tmp/dbus-g5jO7666uf,guid=b6f2501f4e39fdd5c91c2e635fbd629d@rusty-snake commented on GitHub (Nov 25, 2020):
ok, IMHO it's then enough to improve the error message.
@seniorm0ment commented on GitHub (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 commented on GitHub (Dec 1, 2020):
Summary: You need to ensure that
$DBUS_SESSION_BUS_ADDRESSis set. You can do this by addingeval `dbus-launch --sh-syntax`orexec dbus-launch --exit-with-session dwmfor example to yourxinitrcor whatever session start script you have.Using
dbus-user noneis better (more secure) thenignore dbus-user filterif possible (as workaround).dbus-system noneneed no change.strictly speaking: same issue with all profile containing
dbus-user filter.This is more secure then
filter, however, it does not work for all programs.Just create a
.localin~/.config/firejail(or/etc/firejail). Example:@seniorm0ment commented on GitHub (Dec 1, 2020):
I added the second one to my xinit and it didn't work.
Is my xinit, I tried adding it at the top but it broke my sxhkd.
@kris7t commented on GitHub (Dec 1, 2020):
I think your whole desktop should run in
dbus-launch. For example, you makeyour
.xinitrcand then putinto
~/.local/bin/desktop-session.sh.Although if you wanted to be fancy, I guess something like
would also work.
@seniorm0ment commented on GitHub (Dec 1, 2020):
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 commented on GitHub (Dec 1, 2020):
D-Bus is a great way to escape from a sandbox. That's why firejail 0.9.54 added the
nodbuscommand to block the session bus. Since 0.9.60, this command blocks the system bus too. Firejail 0.9.64 split this indbus-user none(block session bus) anddbus-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 addeddbus-(user|system) filterto use xdg-dbus-proxy to allow access to the session/system bus, but only for whitelisted names.Either you made a typo or dbus-launch added a socket to one of the hardcoded places.
@kris7t commented on GitHub (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.