3

I want to install X on a system I'm in charge of. I plan on running it with local connections only, e.g. with startx -- -nolisten tcp (which I understand is the default these days).

Some relatively old notes on security, Crash Course in X Windows Security, imply that displays are inherently insecure:

Running your display with access control enabled by using 'xhost -' will guard you from XOpenDisplay attempts through port number 6000. But there is one way an eavesdropper can bypass this protection. If he can log into your host, he can connect to the display of the localhost. ... Of course, an intruder must have an account on your system and be able to log into the host where the specific X server runs. On sites with a lot of X terminals, this means that no X display is safe from those with access. If you can run a process on a host, you can connect to (any of) its X displays.

The implication here is that there's no way to provide even elementary security for X displays locally.

Is that true? If not, are there configuration settings one needs to consider that can prevent it?

  • 3
    In section 8 of that link it also says: Xauthority is simple and powerful, and eliminates many of the security problems with X. This is also the default these days. – meuh Apr 11 '16 at 16:06
4

The document you're reading is from the last century. I don't remember any system I've used this century that didn't use cookies (described in §8 of the document). With cookies, the first thing an application needs to do when it connects to the X server is to present the “cookie”, which is a password that's randomly generated when the server starts and stored in a file that only you can read. Applications know the location of the cookie file because it's the value of the XAUTHORITY environment variable, defaulting to ~/.Xauthority. If a process can read your cookie, it means that it has access to the private files on your account, so the security of the X server is a moot point.

Since this is the default, you don't need to take explicit steps to secure the X server.

You do need to restrain from some behaviors:

  • Obviously, don't reveal the content of the cookie file.
  • Don't use TCP connections to the X server unless they're on a trusted network where you're sure there can't be any eavesdropper. (The loopback interface is fine.) If someone snoops on the TCP connection, they'd see the cookie. Instead, use SSH and tell it to forward the X11 connection (ForwardX11 yes in the configuration file, ssh -X on the command line).
  • When you run SSH from machine A (running an X server) to machine B, if X11 forwarding is activated, applications running on your account on the remote machine get access to the local X server. The X server doesn't perform any isolation based on the machine on which the application is running. Note that this means that you must trust the remote administrator.

If an application has access to the X server, consider that it has access to your account. While some applications disable the most obvious keystroke monitoring and injection features, there are features that can't be disabled; X doesn't distinguish between a screenshot app, a keyboard macro app, and some random app that you don't trust. If you want to run a GUI application that you don't trust, run it in a virtual machine (with the display in the VM), or run it on a separate account and have it display on a separate X server such as Xnest.

  • Thanks for the details. As you say, it's a very old document. Unfortunately most of the information I can find on X security is very dated (and hence harder for me to evaluate for current relevance), which I assume reflects the fact that X itself is long in the tooth. – user1071847 Apr 13 '16 at 15:25

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.