Question : firejail and Xephyr

[deb75]

Hello,

I am used to launch X applications like browsers with firejail, Xephyr and openbox :

firejail  ... --x11 Xephyr openbox-session

Then, openbox autostarts the desired application inside Xephyr.

I would like to proceed differently :

1. first, launch Xephyr separately : Xephyr -ac -br :1
2. second, launch a window manager in it : DISPLAY=:1 awesome
3. third, launch my desired app in it with firejail : DISPLAY=:1 firejail --private firefox

I would like to know if it is equivalent in terms of security provided by firejail.

Regards

[netblue30]

In your example:

$ Xephyr -ac -br :1
$ DISPLAY=:1 awesome
$ DISPLAY=:1 firejail --private firefox

the last line (firefox) is bad. You need a network namespace for it, something like:

$  DISPLAY=:1 firejail --private --net=eth0  firefox

Without --net=eth0 the main X11 display is still available, the bad guy can still connect to it. Also, programs you start directly in awesome are not sandboxed. The setup is not bad, but you can do better.

I would suggest to follow this guide: https://firejail.wordpress.com/documentation-2/basic-usage/#x11 where you replace openbox with awesome but still use the openbox profile. So, the first command should be:

$ firejail --x11=xephyr --net=none --profile=/etc/firejail/openbox.profile awesome&
(you can also use --net=eth0 instead of --net=none)

Then, you just follow with the rest of the steps there. In the end you will have your programs Xephyr/awesome/firefox each of them running in a different sandbox.

[chiraag-nataraj]

I think this question was answered. @deb75 please feel free to re-open if your questions weren't answered :)

[deb75]

Hi,

I ended up doing :

Xephyr -ac -br -noreset :455 &
DISPLAY=:455 firejail --net=none    --private=/tmp/toto awesome &
DISPLAY=:455 firejail --net=wlp1s0 --private=/tmp/toto /usr/bin/firefox &  

wlp1s0 is the name of my wifi interface.

I prefer to launch Xephyr myself so that I can better control the display number. I hope it does not introduce security holes.

Trouble is that firefox does not work well with the option --net=wlp1s0 that you advocated. It launches itself well but cannot reach internet as if there were no internet connexion. I checked that it works well without this option, what is the trouble with -net=wlp1s0 ?

Thanks in advance for your kind help

Regards

[chiraag-nataraj]

@deb75 Which version of firejail do you have? The ability to have a network namespace with wireless interfaces was only added in 0.9.56, so you should use at least that version for what you're trying to do.

[deb75]

I have just installed the 0.9.56 version :

firejail version 0.9.56

Compile time support:
	- AppArmor support is enabled
	- AppImage support is enabled
	- chroot support is enabled
	- file and directory whitelisting support is enabled
	- file transfer support is enabled
	- networking support is enabled
	- overlayfs support is enabled
	- private-home support is enabled
	- seccomp-bpf support is enabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

But when launching like this :

firejail --private --net=wlp1s0 /usr/bin/firefox-esr

I get this error :

RTNETLINK answeers; Operation not supported
Error: failed to run /usr/lib/x86_64-linux-gnu/firejail/fnet
Error ioctl: interface.c:98 net_if_up: No such device
Error: failed to run /usr/lib/x86_64-linux-gnu/firejail/fnet
Error: proc 29874 cannot sync with peer: unexpected EOF
Peer 29875 unexpectedly exited with status 1

What is the trouble ?

[chiraag-nataraj]

Are you sure the interface is called wlp1s0? Can you do an ip addr and post the output here? I had this error earlier, but it was somehow resolved by the time 0.9.56 was released.

[deb75]

Hi,

Here the output of ip addr :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether c4:9d:ed:23:e2:10 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.16/24 brd 192.168.1.255 scope global wlp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::c69d:edff:fe23:e210/64 scope link 
       valid_lft forever preferred_lft forever

I wonder what means "Operation not supported". Does it depend on the wireless driver ? That is to say some drivers did implement this feature and some others did not. My wifi card uses the mwifiex kernel module.

[deb75]

I tried with latest git version (master branch) and I still get this very same error.

In the kernel log at boot, I can read :

mwifiex_pcie 0000:01:00.0 wlp1s0: renamed from mlan0

So it seems the wlp1s0 interface name is not the original one, mlan0 is renamed wlp1s0 by the wireless kernel module for my wifi card. However calling firejail with --net=mlan0 has no more success, it just returns Error: cannot find network device mlan0

Any hints ?

Regards

[chiraag-nataraj]

@deb75

So it seems the wlp1s0 interface name is not the original one, mlan0 is renamed wlp1s0 by the wireless kernel module for my wifi card.

Yeah, that's systemd renaming interfaces (you could disable that, but it's not what's causing the issue here).

I wonder what means "Operation not supported". Does it depend on the wireless driver? That is to say some drivers did implement this feature and some others did not. My wifi card uses the mwifiex kernel module.

As I understand it, it shouldn't be an issue. firejail uses the standard ipvlan driver to shuttle traffic back and forth, so this should work. We had #2046, but I don't think there was ever a satisfactory resolution - things just started working for me and the core issue there was never resolved.

[deb75]

My bad !

I had my kernel recompiled a few months ago and forgot to include some drivers, among which ipvlan.

Once all drivers present, it works well, this explains the error "Operation not supported", without the driver ...