7

Is there any part of my system that I can block access to from the firefox process on a Linux system that will break screen sharing?

I noticed during a video call that Firefox has the ability to do screen sharing, which means the process can read the contents displayed on my screen.

I don't like the idea of everything on my screen being available to my browser; what's the mechanism behind this?

4
  • 1
    I thank you for asking this, as I have no clue on what mechanism is used. Also after a quick research (to try to understand the mechanism and answer you): support.mozilla.org/en-US/kb/screenshare-safety : screen sharing also allows the site you screenshare with to control your browser's windows (and thus quickly can surf to other sites as yourself, using the credentials you already entered and thus gain access to information they shouldn't get access to!). I never knew this could be even a possibility! (probably not limited to FireFox, and coming from the mechanism involved?) – Olivier Dulac May 5 at 6:41
  • 1
    I also would be willing to bet theres a vulnerability that allows bypassing of the user dialog setting to allow screen sharing without the user accepting it. – john doe May 5 at 6:47
  • 3
    The problem is definitely not limited to Firefox only. I think every program running on your $DISPLAY can read the contents of the display. Try to run xwd -root -out screen.xwd. This ancient tool makes a screenshot of your display. Running without -root only take a screenshot of one window. Almost all graphical environments (Xfce, mwm, Plasma, Gnome,...) have their own screenshot apps. This was never a privacy problem until videoconferencing. I think it should be resolved sometime in the future on a system level. – nobody May 5 at 6:52
  • 1
    reading more in the linked blog from the url I posted above: blog.mozilla.org/webrtc/… : the browsing-as-you is probably already available to websites (.. via javascript?), & the screen sharing part allows those website to then read the information on those pages. (I hope someone here will help understand this better). I am flabbergasted by all this! – Olivier Dulac May 5 at 6:53
2
+50

Why does screen sharing work under X11?

In the X11 security model every client that can access the X server and isn't restricted by a X server extension is trusted by default and can use queries like XCopyArea or XGetImage to capture the content of every window on the screen. The reasons for this are mostly historical, as the first version of the X11 protocol was released in 1987 and security features were later "bolted on".

Wayland has a stricter security design. There only the compositor or designated trusted applications can access the content of other windows.

The X Access Control Extension framework

One elaborate solution to block screen sharing would be to write a X server extension module using the X Access Control Extension (XACE). This extension provides hooks for other extension modules to allow fine-grained access control decisions.

Unfortunately, I didn't find any pre-existing module that can block specific applications from accessing foreign windows, so you'd need to write one such extension yourself. This will probably be a quite time-consuming task.

The X Security Extension

An easier solution is the Security extension. It predates XACE and only differentiates between "trusted" and "untrusted" clients, so it doesn't only block screen sharing but also things like graphics acceleration, cursor capturing, custom cursors and fullscreen windows. So it may cause buggy behaviour and will slow down rendering.

The basic idea is that applications use a "magic cookie" to authorize with the X server. These "cookies" are essentially random numbers written in some file (~/.Xauthority or a file like /tmp/xauth-* referenced in the environment variable XAUTHORITY) that applications can use to prove to the X server that they are allowed to connect. Cookies can be "trusted" or "untrusted". The default cookie generated on login is trusted.

So to restrict Firefox you need to generate a new untrusted cookie into a new X authority file and use the XAUTHORITY environment variable to provide Firefox with the untrusted cookie on startup. This is possible using the xauth command.

The following wrapper script will execute the program given as an argument as an untrusted X client:

#!/bin/sh
# Create empty file only accessible by the current user or empty it if already existing
(umask 0077; : > ~/.Xauthority-untrusted)
# Generate an untrusted magic cookie expiring 30 seconds after last use
xauth -f ~/.Xauthority-untrusted generate "$DISPLAY" MIT-MAGIC-COOKIE-1 untrusted timeout 30
# Set the environment variable
XAUTHORITY=~/.Xauthority-untrusted
export XAUTHORITY
# Replace the shell with the program given on the command line
exec "$@"

Save it as e.g. untrusted.sh and make it executable. Then you'll be able to start Firefox in untrusted mode by using ./untrusted.sh firefox.

Please note that this won't fully protect from malicious applications. That protection can be circumvented as long as the application runs on your local machine and under your user account, because a malicious application could guess the location of the original authority file or make use of some fallback rules provided by e.g. the xhost access control, but it's enough to prevent a browser from screen sharing.

3
  • Thank you. I have a basic understanding of Xauthority because I have to use it when I su to a different user and want to launch X11 apps under it (e.g. copying my $HOME/.Xauthority over to the other account). But I was not aware there were two variants of these cookies - I'll start using the untrusted ones more, for sure. – ttsiodras May 12 at 11:41
  • 1
    I also only knew about it because of SSH. When ForwardX11Trusted is set to no in ssh_config, ssh -X copies only an untrusted magic cookie to the remote host. – cg909 May 12 at 13:42
  • Now I know why people started working on Wayland.... – john doe May 12 at 19:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.