What is X-Win32

X-Win32 is an application that provides X-Server capability for the Microsoft Windows operating system.  This allows applications running in the Unix/Linux environment to display graphical user interfaces on the Microsoft Windows desktop.  This is needed to run Unix or Linux web browsers or xterminal commands, and to run certain applications like MatLab.

Boston University has purchased a site-license for the X-Win32 product from StarNet for use by our community. We actively promote its use on our campus for your X-server needs.

The Open Text Connectivity Solutions Group produces a software package called Exceed that provides X server software which is also quite popular but is not supported by IS&T at this time.

X-Win32 Security

Recent versions of X-Win32 have implemented a much better security model by default, but you will need to understand some aspects of how it works in order to be able to use it reliably, efficiently, and securely.

To begin, you should understand the basics of the X-Windows system and security.  If you do not know what xhost and xauth are, you should start by reading about How X-Windows Access Control Works.  You may also be interested in knowing what could happen if I fail to secure my X-Windows server.

For the impatient, you may jump to the What Should I Do section,

Access Control in X-Win32

In X-Win32 the access control system is configured through the Xconfig tool, which can be launched via the Start Menu or by double clicking the X-Win32 Icon in the Task Bar.

The default behavior of X-Win32 varies across versions, but everyone should be running version 9 or newer at this point.  In old versions, the default behavior was to allow all connections, which was part of the inspiration to create the X-Windows Security Probe.  Newer versions have more secure defaults.

If you have an older version of X-Win32 you should update to the latest version.  If for some reason you cannot, please look at our advice on Securing Older Version of X-Win32.

Inside the XConfig tool there is a Security tab which deals exclusively with access control.  The contents of the tab are shown below.

Xconfig Security Tab

Xconfig Security Tab

Allow by Xauth Cookie

In the first section, “Allow by Xauth Cookie” you can use the Xauth mechanism to provide authentication. This is a little difficult to use in the Microsoft Windows environment, but if it is the best fit for you then please read the X-Win32 help documentation for Xauth for more information on how to use it.

Allow by Address

The second section, “Allow by Address”, you can use xhost style authentication where you allow one or more hosts to connect.  There is a radio button at the top marked “Allow all host addresses”.  Selecting this is equivalent to using “xhost +” and should not be done.  Using the “Only allow these hosts addresses” radio button is equivalent to do “xhost +hostname” for some set of hosts.

Note: If you use SSH forwarding, you will need to add an entry for “localhost” (with out the quotes) to your allowed “Allowed Host Addresses” list.

Allow by Prompt

Finally, the panel offers “Allow by Prompt” which features one checkbox: “Prompt for connections not allowed by other means”.  This last option is a feature that makes X-Windows easier to use under Microsoft Windows:

If a client connects without a valid magic cookie (xauth) and isn’t in the list of allowed hosts (xhost), the X-Server may prompt and ask you if you want to accept the connection.

To check or not to check?

If you do check this box: Any time anyone attempts to connect to your X-Windows server you will get a dialogue box asking you accept or refuse the connection.  Since you cannot control how often people connect to your server, this can become an annoyance.  To reduce this annoyance, read our section on Using the Microsoft Windows Firewall to limit X-Server connections.

If you do not check this box: If a connection is made that is not authorized by the other means it will be rejected without any notice to you.  Usually this will result in a “Cannot connect to display” type error message.

What Should I Do?

Here’s what we recommend:

  1. Do not run X-Win32 except when needed.
    1. It does not need to launch at boot, launch it when you need it.
    2. When you’re done using it, single right-click the icon in the system tray and pick “Exit” to shut down the X-server.
  2. Use Xauth if you’re comfortable with it.
  3. For Allow by Address, pick “Only allow these hosts” and delete any and all hosts in the “Allowed Host Addresses” until it says “No hosts allowed”.
    1. If you use SSH X11 forwarding you will need to add an entry for “localhost” (with out the quotes) to the “Allowed Host Addresses” list.
  4. Check the “Prompt for connections not allowed by other means” in the Allow by Prompt box.
  5. Save this configuration.

Here’s an example of a well-configured system:

Example of a properly configured x-win32 security tab.

Example of a properly configured x-win32 security tab.

The Big If

Here’s the big if in this security model:

If you responsibly accept only those connection requests that you are expecting and deny all other connection requests, this will be the most secure way to go.  If, however, you accept all requests then you have not achieved any better security than the dreaded xhost +.

How this works in practice

When you get a connection request a box will appear on the screen.  If you are expecting a connection (you just launched Matlab, for example) and the host specified in the dialog box is the host you are expecting the connection from then we want to accept.  Before clicking “yes” ensure that the “Always do this” checkbox is not checked.   If you were not expecting a connection, always select “No”.  At the very worst you will refuse a connection that you wanted and the client will produce an error similar to “Cannot connect to display”.  If you refuse a connection you wanted you can always run the remote program again.