Automatically Firejailing Tor Browser

Development
11

Thanks for following this up.

1 Like
12

It seems that Firejail is going to be installed by default in Whonix 15 so this seems like it’d be a good idea.

Any Xorg window has access to any other Xorg window. This makes it easier for things like keyloggers or screenshot programs that can even record the root password. [1]

Firejail has a way to sandbox these windows with an external X11 server so one window doesn’t have access to another window. It seems that there is only support for Xpra and Xephyr. I prefer Xephyr over Xpra.

Would it be good for Whonix to sandbox the Tor Browser or other programs in an X11 sandbox by default?

There is a guide on X11 sandboxing here

  1. The Linux Security Circus: On GUI isolation | The Invisible Things
3 Likes
13

A quote from @Patrick in another thread:

Though I think the implications are worth researching and asking The Tor Project about if you don’t mind posting on theirTor Browser mailing list.

2 Likes
14

Worth investing time into X11?
Wayland more suitable?
On the downside XFCE doesn’t support wayland yet.

As for firejail that’s not doable since we don’t have a firejail maintainer, see:

https://forums.whonix.org/t/looking-for-firejail-seccomp-maintainer-for-better-security/2211

1 Like
15

Wayland would be much more suitable than X11 but right now X11 is the only choice unless Whonix uses something else as the default DE.

I’ll research into if there are any fingerprinting issues with firejail.

I would volunteer to maintain firejail but I don’t have any experience with that.

1 Like
16

Yes. It’s going to be a looong time before the wayland problems are ironed out and the protocol gains the needed extension and then have the necessary libs baked in to XFCE:

When Wayland comes along I don’t believe GUI isolation needs to be explicitly handled by firejail since it is all done properly by the compositor?

2 Likes
17
1 Like
18

Why use --seccomp? Why not use the default firejail profile?

19

The default firejail profile would be used in combination with the --seccomp flag. But the default profile already uses seccomp so that flag would be redundant.

1 Like
20

Removed from wiki.

1 Like
21

Anyone managed to make firejail gui isolation work?

firejail --x11
1 Like
22

I have. It’s pretty simple but it might be a bit annoying to use as the external X server has to be set at a specific resolution which may be better or worse depending on the users monitor.

2 Likes
23

Which helper package (required as far as I understand) would be better/recommended/easier/safer/whatnot?

  • xpra
  • xserver-xephyr

Which did you use?

1 Like
24

I prefer to use Xephyr. Xpra seems a bit more complicated.

1 Like
25

What about…?

--x11=xorg

Seems to have zero usability impact?

1 Like
26

--x11=xephyr --xephyr-screen=1366x768 is also interesting since then we could get a better web fingerprint by using the most popular screen resolution on desktop computers? But xephyr looks weird in Qubes. All window contents on the left and then a lot black area on the right side. Looks incompatible. And xephyr breaks copy/paste of text from and to the browser window?

--x11=xpra crashed for me in a Qubes VM.

So for Qubes --x11=xorg seems like the way to go for now.

2 Likes
27
1 Like
28

--x11=xorg uses the X security extension which is poorly documented.

https://www.x.org/wiki/Development/Documentation/Security/

It will also allow applications which both use the security extension to interact with eachother as if there was no sandbox at all.

I found some discussion here What is up with the X11 SECURITY extension? : linux

1 Like
29
30

That’s to be expected since X handles the clipboard.

1 Like