12 Term and Security

Trsh is insecure when it is used to access the local Linux box from the remote system. The problem with TERM and its clients is that beside the owner of the TERM connection also 'root' can execute TERM-aware programs over the connection.

This also means that 'root' on the remote system can execute trsh and thus can enter the login which owns the TERM connection quite easy. If this owner on the local box is 'root' then you will be in hell.

The solution to this problem is easy: you just have to put the following line in the termrc file on the local box:

  denyrsh on

With this set in the 'termrc' file, nobody can use trsh on the remote site anymore to access your machine. When you and others want to access your local Linux box over the TERM connection this can still be done using telnet and redirected ports.

Txconn is not terribly secure; anyone can connect to your local server via TERM and perform all sorts of mischief. I you are worried about this sort of thing, it might be a good idea to consider using xauth to authorize your connections. See the next section for an example of using xauth for securing your connections.

Sxpc in combination with 'xhost +' is very dangerous when you are not using xauth.

Using xauth is very important to maintaining security when using sxpc. If you do not use xauth when using sxpc all the dangers of running with 'xhost +' apply. These dangers include but are not limited to:

• Someone watching what is displayed on your screen
• Someone watching what you type
• Someone typing in one of your windows (for example: a command to delete all your files :-(

Xauth is available in X releases R4 and later. Here I will describe how to set up basic usage of xauth. This configuration is vulnerable to network snooping, but if you can live with that it should be fine.

NOTE: when using xauth your $DISPLAY variable must NOT be set to localhost (or localhost:whatever). If your $DISPLAY variable does use localhost the clients will be unable to find the appropriate authorization information. The workaround is to use the real hostname of the machine. If you follow the compilation instructions in the README, and compile without -DNOGETHOSTNAME then everything should work.

The machine where you will be running clients will be called C, the machine where you wish to display them will be called D.

First choose a 'key', up to 16 pairs of hexadecimal digits (so an even number of characters from the ranges 0-9 and a-f). You will need to supply this key in place of <key> in the example below.

On C:

  % xauth
  xauth:  creating new authority file $HOME/.Xauthority
  Using authority file $HOME/.Xauthority
  xauth> add Chostname:8 MIT-MAGIC-COOKIE-1 <key>
  xauth> exit

On D:

  % xauth
  xauth:  creating new authority file $HOME/.Xauthority
  Using authority file $HOME/.Xauthority
  xauth> add Dhostname/unix:0 MIT-MAGIC-COOKIE-1 <key>
  xauth> add Dhostname:0 MIT-MAGIC-COOKIE-1 <key>
  xauth> exit

When starting the X server on D you should give the flag -auth $HOME/.Xauthority. You may need to edit or create a '$HOME/.xserverrc' to control how the X server is started. For example:

  #!/bin/sh
  exec X  -auth $HOME/.Xauthority $*

Make sure that your '.Xauthority' file is readable only by you on both C and D.