Security Concerns During Log Off

Whenever UUCP is used, security must be considered for the host system. To illustrate how the use of UUCP can create security problems, suppose that when the last user to use the port exited, he or she didn’t log out, and the remote system is not set up to drop the line when the connection closes. This type of scenario should be immediately reported to the system administrator of the other machine.

When this occurs, anyone who placed a call to this machine gets a terminal session with a shell and the access privileges of the last user, which is root in this case.

Correcting the problem involves making sure that your cable has the appropriate RS-232 signals to receive Carrier Detect, and the hardware flow control signals. It is also important to ensure that the correct device is being used. On SCO Systems, for example, the /dev/tty1a device does not use modem control signals; therefore, a modem on this device will not hang up properly. This is solved by using the /dev/tty1A device.

This is only an example because the actual device name used on your system may be different for operating system implementation.

A successful UUCP transaction is shown in the following sequence of commands (the author’s comments are enclosed in brackets):

chare@unilabs> /usr/lib/uucp/uucico -r1 -x9 -sbugs
conn(bugs)
[Connection wanted for bugs]
Device Type bugs wanted
[I want a device type known as bugs to make the connection]
getto ret 6
[Set the speed ]
expect: (“”)
[Start the chat script - expect nothing ]
got it
[ OK ]
sendthem (DELAY
^MDELAY
^M^M)
[Send \d\r\d\r ]
expect: (login:)
^M^Jlogin:got it
[ OK ]
sendthem (unilabs^M)
imsg > ^M^J^M^Jlogin: login: unilabs^M^JWelcome to Unilabs
 Research^M^J^M^J
     ^M^J|              SPECTRIX Microsystems Inc.
|^M^J|      Xenix-68000      Vers. 3.0      Release 1.0
|^M^J|______________________________________________________|^M^J^
M^JCONNECTED TO: thumper.unilabs.org    (613) 834-1439^M^JSYS
MANAGER : Chris Hare      ^M^JMAIL TO      :
chare@unilabs^M^JWARNING     : Full System Security is
operational.^M^M^JPRIMARY ON-LINE STORAGE^M^J^PShere^@Login
Successful: System=o bugs
[ Login established ]
imsg >^PROK^@imsg >^PPg^@wmesg ‘U’g
Proto started g
[ Protocol negotiation ]
wmesg ‘H’
[ I have no work - request hangup ]
wmesg ‘H’Y
[ Remote has no work - hang up ]
send OO 0,imsg >^P^I^H*”^I^P^B^Q^^^R^_HY^@imsg
>^@^@^@^@^@^@^@@@^@^@^@^@^@^@^@^@^@^@^@^@^@@@^@^@^@^@^A^R^X^@^_vJ
^@^AAn^@^@^@2^@^@^@^@    }@@^@^@^@^@^@^@^@^P^I”*^H^I^P^I”*^H^I^POOOOOO
^@Conversation Complete: Status SUCCEEDED
 [ Call terminated ]

Through this seemingly simple transaction, you now know that the UUCP connection is working. An important transaction on the first imsg line takes place concerning the validation of the calling systems. This transaction ensures that the two machines know each other.

The slave machine, usually the one being called, prints the message Shere=nodename, which means “system here”— nodename is its machine name. The master usually replies with Snodename-Qseq-xnum.nodename is the master’s nodename; seq is the sequence number or zero if not used; and num is the level of debugging in effect. This is not consistent across implementations; as in the earlier example, the slave only prints Shere.

If the two machines agree to talk to each other, the slave prints the message ROK, and the call continues. Another place to look for debugging information is in the Log files that are kept by the various UUCP commands. These are presented later in this chapter under the heading “UUCP Log Files.”

During the debugging process, it may be necessary to circumvent the normal retry mechanism so that you can fix a problem and immediately call back. UUCP status files are kept on a machine-by-machine basis in the directory /usr/spool/uucp/.Status. Currently this directory on this system has the following files that record status information on these three systems:

$ ls -l
total 3
-rw-rw-rw-   1 uucp     other         32 Dec 30 00:04 bugs
-rw-rw-rw-   1 uucp     other         45 Dec 30 00:11 thumper
-rw-rw-rw-   1 uucp     other         38 Dec 30 00:11 wabbit

The status file looks like this:

    Type  Count   Time         Retry    Status         System
    0     0       725691861    0        SUCCESSFUL     bugs
    6     1       725692313    300      LOGIN FAILED   wabbit

These two examples were retrieved from separate files. The fields are defined as follows:

•  Type. A code that indicates the status of the job. This is explained in the status field.

•  count. The number of call attempts made by the local system. This is incremented each time uucico tries to call the remote system.

•  time. The time in seconds since January 1, 1970, when this system was last called. Listing 1 at the end of the chapter has a program called gtimes that will print the correct text for this time.

•  retry. When should the system retry the connection again. This value is stored in seconds.

•  status. A text description of the status of the last call.

•  system. The name of the system.

Status files are updated and removed periodically during the normal course of operation. In the event that UUCP fails abnormally, however, you may have to remove status files. In the case of the line for the system wabbitt, you won’t be able to call this system for 300 seconds. To circumvent this retry limit, remove the status file for the desired system from /usr/spool/uucp/.Status/system. This will make uucp think that there wasn’t a problem, and the call will be made immediately.