You may not know that anyone with access to Internet anywhere on the world can peek at your X Window screen with a few UNIX commands at their finger tips. Giving others unlimited access to our display leaves a lot of potential for serious damage. Therefore, it is necessary to have access control on our X servers.
In this section, we will introduce Host-based access control, User-based access control and other schemes to secure our X server.
Host-base access control only allows clients from authorized hosts to have access to your display. Command xhost adds or deletes host names to the list allowed to make connections to your X server.
restricts clients from other hosts to connect to your X server. To add a host, ccf.pppl.gov, to your authorized host list, type:
On the Unix Cluster SUNs, it is not necessary to
include each host in the authorized host list because the home directory
~/.Xauthority' is shared on the UNIX cluster.
To check the status of Host-based acess control, type:
If you see
access control disabled, clients can connect from any host
on the screen, your X terminal is not secured. You can put
xhost - > /dev/null xhost a.nersc.gov ccf.pppl.gov ...
in your .xsession file to enable the access control and add authorized
hosts automatically when you start an X session. No one should have
xhost + in their `
The major drawback of Host-base access control is that all users on your authorized hosts have access to you X server.
User-based access control is more restricted than the Host-based access control. Only authorized users from other hosts can connect to your X server. When you start an X session through the normal procedure, a machine-readable code is generated and stored in .Xauthority in your home directory. This authority code is like a key to the user's host and the server. A client from other hosts must present this code to connect to your X server. Suppose you start an X session on carl.pppl.gov and turn on the Host-based access control using xhost -. You will not be able to run a client on f.nersc.gov before exporting the authority code from carl.pppl.gov to f.nersc.gov.
On Unix Cluster, the command to export the authority code to other
target hosts is Xauth. Xauth runs xauth on the target host. Therefore,
xauth must be in the PATH on that host. This is usually achieved by
/usr/X11R6/bin' (or perhaps `
/usr/bin/X11') in PATH
To export the authority code from carl.pppl.gov to Cray UNIX machines like f.nersc.gov, on carl type:
Xauth -l Cray-user-name f.nersc.gov
contains 'machine f.nersc.gov login Cray-user-name password Cray-password' on carl.pppl.gov, no password is needed.
To export the authority code from carl.pppl.gov to other UNIX machines like ccf.pppl.gov, on carl type:
Xauth -l ccf-user-name ccf.pppl.gov
Password to ccf.pppl.gov is required. If you have a .rhosts file which contains 'carl.pppl.gov carl-user-name' on ccf.pppl.gov, no password is needed. You can compare the authority code with command 'xauth list' on all machines.
With correct settings in the `
.rhosts' file on the target host or
on the local host, you can put command lines
xhost - > /dev/null Xauth f.nersc.gov a.netsc.gov ccf etc.
in your `
.xsession' file to transfer the authority code to other hosts
automatically at the beginning of an X session.
The other element of security with X terminals is restricting access to the X terminal itself. Key points.
"Lock" !"xlock -remote -mode pyro -nice 1 -delay 100000 &"
xautolock -locker 'xlock -remote -mode blank' &
in your `
.xsession'. When no activity is performed within
10 minutes, the screen is automatically locked. The screen is
blanked and a changing pattern is put on the screen. If a key or
a mouse button is pressed, then the user is prompted for the password.
After entering the correct password, the screen is unlocked and
the X sever is restored.
For more information, please read xauth, xhost, Xauth and Xsecurity manual pages.Customizing XWindows