How to block internet access while retain connection to host native X11

[azurvii]

The options I explored:

• --net=none blocks both internet and host X11 connection. --net=none --x11 works, but I need gpu hardware acceleration, and thus a direct host x11 connection.
• --netfilter works only when --net= is used, according to the manpage.
• --protocol=unix works only partially. I tested with steam, in which web pages are all broken. But somehow steam can still download games (both new game install and update downloads work).

For the 3rd point, my impression is that unix sockets are local. Is it possible to use a unix socket for internet access? I found https://wiki.manjaro.org/index.php?title=Firejail#Block_an_application_from_accessing_the_internet, which seems to side with my impression (that unix socks are local), but somehow firejailed steam is not fully restricted from internet.

In case it might be helpful, how I launch steam is: firejail --noprofile --seccomp --nonewprivs --caps.drop=all --chroot=~/chroot steam.

Not sure what else I can do to achieve the result in the title. Any recommendations / suggestions are welcome.

[rusty-snake]

But somehow steam can still download games (both new game install and update downloads work).

Unix sockets are local and can not be used for TCP/IP. Steam likely spawns a download-worker through systemD/D-Bus .

Not sure what else I can do to achieve the result in the title. Any recommendations / suggestions are welcome.

You can bind mount the regular-X11-socket inside the chroot.

[smitsohu]

A bit of a dirty hack is to set an environment variable FIREJAIL_X11 before starting the sandbox, then Firejail will take care of X11 mounting itself. But only do this when not using any of the --x11 options.

[azurvii]

But somehow steam can still download games (both new game install and update downloads work).

Unix sockets are local and can not be used for TCP/IP. Steam likely spawns a download-worker through systemD/D-Bus .

Can you expand a bit on the systemd/dbus exploit? I'm trying to relate how steam can communicate with the systemd/dbus in the chroot, but my assumption is that systemd/dbus that steam talks to is also bound by the --protocol parameter, which should restrict their outreaching activities. Correct me if I'm wrong.

You can bind mount the regular-X11-socket inside the chroot.

A bit of a dirty hack is to set an environment variable FIREJAIL_X11 before starting the sandbox, then Firejail will take care of X11 mounting itself. But only do this when not using any of the --x11 options.

This worked for me! I found some more info in #2711 and the code. Do you have any idea whether this hack would be formalized? E.g. to become a command line parameter. Also, as the solution is similar for #3484 as well, I think this should be able to be applied to pulseaudio as well (which needs to copy /etc/machine-id and bind-mount /$XDG_RUNTIME_DIR/pulse).

[azurvii]

I just found that the bind-mounting by FIREJAIL_X11 does not expose the mount in the host (mount shows the mount in the jail but not in the host). And I assume (and hope) that this mount is umounted when firejail exits.

If that is correct, this would be much cleaner than the manual mounting outside the jail (I'm scripting it for pulseaudio, and I don't have a good way yet to umount it automatically, considering a possible multiple instances situation).

[smitsohu]

And I assume (and hope) that this mount is umounted when firejail exits.

These mounts are destroyed when all processes in the sandbox mount namespace have terminated, or in other words, when Firejail exits.

Do you have any idea whether this hack would be formalized? E.g. to become a command line parameter. Also, as the solution is similar for #3484 as well, I think this should be able to be applied to pulseaudio as well (which needs to copy /etc/machine-id and bind-mount /$XDG_RUNTIME_DIR/pulse).

I guess a simple way to formalize this would be to just use an environment variable different from FIREJAIL_X11. And right, Firejail could do in principle the same with pulseaudio.

[smitsohu]

but my assumption is that systemd/dbus that steam talks to is also bound by the --protocol parameter, which should restrict their outreaching activities. Correct me if I'm wrong.

The problem is that the process at the other end of the socket doesn't know about our own sandbox restrictions. If you allow a sandbox access to a socket, you open up unrestricted access to the service, and what that means depends on the service alone.

What does echo $DBUS_SESSION_BUS_ADDRESS say? Did you maybe bind mount that path in the chroot? Is the issue fixed by adding --nodbus or --dbus-user=none --dbus-system=none (depending on Firejail version)?

[azurvii]

The problem is that the process at the other end of the socket doesn't know about our own sandbox restrictions. If you allow a sandbox access to a socket, you open up unrestricted access to the service, and what that means depends on the service alone.

Do you suggest that firejail mounts the dbus in chroot by default? Not stated in the manpage at least. I was saying that with an assumption that the dbus inside is a different one, and not the dbus outside.

What does echo $DBUS_SESSION_BUS_ADDRESS say? Did you maybe bind mount that path in the chroot? Is the issue fixed by adding --nodbus or --dbus-user=none --dbus-system=none (depending on Firejail version)?

With --protocol=unix:

$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus
$ ls /run/user/1000/bus
ls: cannot access '/run/user/1000/bus': No such file or directory

And when trying with an additional --nodbus, steam still partially worked (same: no web pages, but downloads work).
However, with --nodbus firejail added: Warning: An abstract unix socket for session D-BUS might still be available. Use --net or remove unix from --protocol set.
I am unable to locate anything like a dbus socket in either /run/user/1000/ or /tmp/.

There is a /run/user/1000/systemd folder in the chroot, somehow. But it seems systemd is defunct:

$ systemctl list-units
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

I'm not sure how to test dbus. What I came up with:

$ dbus-send hello hello
Failed to open connection to "session" message bus: Failed to connect to socket /run/user/1000/bus: No such file or directory

seems to indicate that dbus is defunct too.

I'll try to find something to figure out which process is handling the network traffic. That might help to provide more clues.

[rusty-snake]

To find a abstract unix socket, you must use ss/netstat or lsof.

[smitsohu]

I added environment variables FIREJAIL_CHROOT_X11 and FIREJAIL_CHROOT_PULSE, which expose X11 session and pulseaudio session in the chroot, respectively. You can give it a try!

Do you suggest that firejail mounts the dbus in chroot by default?

No, it doesn't do anything with D-Bus.

[azurvii]

Sorry for a much delayed response. I finally got the latest firejail in backports channel.
I tried launching steam with both env, and it worked like a charm! However, I had to manually mkdir -p /run/user/1000 and chown it. Otherwise FIREJAIL_CHROOT_PULSE would complain the folder was not found. I did not need to manually copy machine-id to get pulseaudio to work.
Thank you smitsohu!