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
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
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! $
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0