0

Classic command to run Xephyr:

Xephyr -br -ac -noreset -screen 800x600 :1

As far as I understand, the -ac key is an analogue of xhost +, and this is a vulnerability, because almost everyone can access the monitor, mouse, keyboard.

How can this be fixed in the Xephyr example?

UPD: mosvy thank you very much for the very detailed answer! Indeed, even without “ac” access is open to all. Your answer opened my eyes to xorg and ssh from a security point of view. Regular Xorg server on my LiveCD/USB really through -auth:

$ pgrep -ai Xorg
551 /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
My5555
  • 3

1 Answers1

0

If you don't use the -auth auth-file option, Xephyr :1 already allows anybody from the same host to connect to it, even without the -ac option. Try this:

hinz$ Xephyr :1 &

then, as another user

kunz$ xclock -display :1

This also applies to any X server, not just Xephyr; if you look at your regular Xorg server, you will see that the -auth option is passed explicitly:

$ pgrep -ai Xorg
2347 /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3

According to the Xserver(1) manpage (emphasis mine):

The X server also uses a host-based access control list for deciding whether or not to accept connections from clients on a particular machine. If no other authorization mechanism is being used, this list initially consists of the host on which the server is running as well as any machines listed in the file /etc/Xn.hosts

As already mentioned in another answer, some Xorg servers (eg. Xwayland) don't support any authenticating mechanism beyond checking who opened the unix socket via getsockopt(SO_PEERCRED) -- the "localuser & localgroup server interpreted access type" from Xsecurity(7); also, some distros like Debian gapped the regular Xorg server via xhost +si:localuser:$(id -un) from an xsession script. Since a socket fd can be passed around and a client could be proxied by programs like xscope, that's a VERY foolish thing to do.

What to do

If you want to prevent other users from connecting to your X server, you have to use some form of authentication.

Create an authorization file, pass it via the -auth option to the X server, and then let the client use the same when connecting to the server.

   # create a MIT-COOKIE authfile
$ xauth -f ~/.xauth-junk add :1 . "$(hexdump -n 16 -e '4/4 "%08x"' /dev/urandom)"
xauth:  file /home2/ahq/.xauth-junk does not exist # it will be created

$ Xephyr :1 -auth ~/.xauth-junk &

Then either merge it in your usual $XAUTHORITY file (~/.Xauthority if not overridden in the environment)

$ xauth merge - < ~/.xauth-junk
$ xclock -display :1

Or pass it explicitly in the XAUTHORITY environment variable:

$ XAUTHORITY=~/.xauth-junk xclock -display :1

You can check it the -auth option really had any effect by trying to connect with a bogus auth file:

$ XAUTHORITY=/dev/null xdpyinfo -display :1 >/dev/null 2>&1 && echo OOPS, anybody can connect!
$
  • Tell me please how to determine whether "-auth" is applied or not? I want to create 2 users: offline and online, so that I can constantly work from under offline, and run Firefox from under a user online. I execute the command Xephyr :1 -auth ~/.xauth-junk &, but if there is no .xauth-junk file, it still creates a window to which anyone can connect. – My5555 Mar 05 '20 at 11:12
  • Is there a way to check if -auth is loaded or not? If I execute the code: Xephyr :1 -auth ~/.xauth-junk & but there is no file .xauth-junk, in any case a window will open, and anyone can connect to it. – My5555 Mar 06 '20 at 06:06
  • In any case, a new window opens, and if the file was not read (the file is missing, rights are not allowed, the owner of the file does not match, etc.), anyone can connect as if there was no parameter -auth – My5555 Mar 06 '20 at 06:17
  • @My5555 Yes, it's bad that the X server doesn't warn about inexistent -auth file. I don't know of any special way to check, but you could try running some client with a bogus authority file and see if it succeeds: XAUTHORITY=/dev/null xdpyinfo -display :1 >/dev/null 2>&1 && echo OOPS, anybody can connect or XAUTHORITY=/dev/null DISPLAY=:1 xhost >/dev/null 2>&1 && .... –  Mar 06 '20 at 06:57
  • As mentioned in the linked answer, if you run that on Xwayland or on the main Xorg server in Debian, it will succeed; that's because they configured it to authenticate the clients by checking who opened the socket via getsockopt(SO_PEERCRED) (configured via eg. xhost +si:localuser:username -- see the Xsecurity(7) manpage (and /etc/X11/Xsession.d/35x11-common_xhost-local on any Debian machine). That's very bad, and I always disable it on Xorg, but that's not possible on Xwayland, because it's the only auth mechanism that Xwayland supports. –  Mar 06 '20 at 07:08
  • I apologize for being off topic. Tell me please how to open the application in full screen in Xephyr? An open application in Xephyr has a fixed size and does not respond to F11. I tried different keys, but on my Debian system the application in Xephyr always opens with a fixed size, everything else is black – My5555 Mar 07 '20 at 14:24
  • @My5555 Xephyr :1 -resizeable and using my wm's keybinding to make a window full screen works for me. And the resolution appears correctly in Xrandr. –  Mar 07 '20 at 15:26
  • A window created by Xephyr itself becomes full-screen, but the content remains fixed. – My5555 Mar 07 '20 at 19:58
  • Are you using a window-manager inside Xephyr? If no, use one. Otherwise apps like firefox, chromium, etc won't run properly -- they depend on a wm, unfortunately. And not only for resizing; drop menus won't open, input boxes won't focus, etc. –  Mar 07 '20 at 20:32