 | Chapter 15 UUCP |  |
| Chapter 15 UUCP | |
Version 2 of UUCP provides five files that control what type of access remote systems are allowed on your computer (see Table 15.1).
File | Meaning |
|---|---|
USERFILE | Determines access to files and directories. |
L.cmds | Specifies commands that can be executed locally by remote sites. |
SEQFILE | Specifies machines for which to keep conversation counts. |
FWDFILE | Specifies a list of systems to which your system will forward files. (Not available in all implementations.) |
ORGFILE | Specifies a list of systems (and optionally, users on those systems) who can forward files through your system. (Not available in all implementations.) |
The two files of primary concern are USERFILE and L.cmds; for a detailed description of the other files, please see the book Managing UUCP and Usenet referenced above.
The /usr/lib/uucp/USERFILE file controls which files on your computer can be accessed through the UUCP system. Normally, you specify one entry in USERFILE for each UUCP login in the /etc/passwd file. You can also include entries in USERFILE for particular users on your computer: this allows you to give individual users additional UUCP privileges.
USERFILE entries can specify four things:
Which directories can be accessed by remote systems
The login name that a remote system must use to talk to the local system
Whether a remote system must be called back by the local system to confirm its identity before communication can take place
Which files can be sent out over UUCP by local users
USERFILE is one of the more complicated parts of Version 2 UUCP. In some cases, making a mistake with USERFILE can prevent UUCP from working at all. In other cases, it can result in a security hole.
Entries in USERFILE take the form:
username,system-name [c] pathname(s)
An entry in USERFILE that uses all four fields might look like this:
Ugarp,garp c /usr/spool/uucppublic
These fields are described in Table 15.2.
Field | Example | Function in USERFILE |
|---|---|---|
username | Ugarp | Login name in /etc/passwd that will be used |
system name | garp | System name of the remote system. |
c | c | Optional callback flag. If present, uucico on the local computer halts conversation after the remote machine calls the local machine; uucico on the local machine then calls back the remote machine to establish the remote machine's identity |
pathname | /usr/spool/uucppublic | List of absolute pathname prefixes separated by blanks. The remote system can access only those files beginning with these pathnames. A blank field indicates open access to any file in the system, as does a pathname of /. |
You should have at least one entry in USERFILE without a username field, and at least one other entry without a system name field:
The line that has no username field is used by uucico when it is transmitting files, to determine if it is allowed to transmit the file that you have asked to transmit.
The line that has no system name field is used by uucico when it is receiving files and cannot find a name in the USERFILE that has a system name matching the current system. uucico uses this line to see if it is allowed to place a file in the requested directory. This line is also used by the uuxqt program.
To make things more interesting, almost every implementation of UUCP parses USERFILE a little differently. The key rules that apply to all versions are:
When uucp and uux are run by users, and when uucico runs in the Master role (a connection originating from your local machine), UUCP uses only the username part of the username and system name fields.
When uucico runs in the Slave role, UUCP looks only at the system name field.
There must be at least one line that has an empty system name, and one line that has an empty username. (In most BSD-derived systems, they can be the same line. Every other implementation requires two separate lines. You are safest in using two lines if you don't understand what your version allows.) The locations of these lines in the file is not important, but both lines must be present.
You can have an entry in your USERFILE for every user who will be allowed to transfer files. For example, the following entries give the local users lance and annalisa permission to transfer a file in or out of any directory on your computer to which they have access:
lance, / annalisa, /
This USERFILE entry gives the local user casper permission to transfer files in or out of the UUCP public directory or the directory /usr/ghost:
casper, /usr/spool/uucppublic /usr/ghost
Be aware that USERFILE allows a maximum of 20 entries in Version 7 and System V Release 1.0.
Instead of specifying a USERFILE entry for each user on your system, you can specify a USERFILE entry without a username. This default entry covers all users on your system that are not otherwise specified. To give all users access to the UUCP public directory, you might use the following USERFILE entry:
,localhost /usr/spool/uucppublic
(The hostname localhost is ignored by the UUCP software and is included only for clarity.)
To allow file transfer from other systems to your system, and to allow files to be accessed by uuxqt (even when it is started from your system), you must have at least one entry in USERFILE for which the system name is not specified. For example:
nuucp, /usr/spool/uucppublic
Although you might expect that this line would mean that any system logging in with the name nuucp would have access to /usr/spool/uucppublic, such is not the case for all versions of UUCP.
In System V Release 2.0 and in Ultrix, UUCP will actually check both the username field and the blank system name field, and will allow logins by any system using nuucp.
In other UUCP implementations, however, the fact that nuucp appears on this line is completely irrelevant to a system calling in. The system name is used only to validate file transfers for files that are received by your system. If this is the first entry with a missing system name, UUCP will actually allow access to uucppublic by any system for which there is no explicit USERFILE entry containing that system's system name. If this is not the first entry with a blank system name, it will have no effect.
You may wish to make special directories on your system available to particular users on your system or to particular systems with which you communicate. For example:
Ugarp,garp /usr/spool/uucppublic /usr/spool/news
This line will make both the directories /usr/spool/uucppublic and /usr/spool/news available to the system name garp when you call it, and to any system that logs in with the UUCP login Ugarp. You might want to add this line if you anticipate transferring news articles between your computer and garp directly, without going through the Usenet news software.
Version 2 UUCP has a callback feature that you can use if you are extremely concerned about security. With callback, when a remote system calls your computer, your system immediately hangs up on the remote system and calls it back. In this way, you can be sure that the remote system is who it claims to be.
If you put a c as the first entry in the USERFILE path list, no files will be transferred when the remote system's uucico logs in. Instead, your system will call back the remote system. No special callback hardware is required to take advantage of UUCP callback, because it is performed by the system software, not by the modem.
For example, here is garp's USERFILE entry modified so the local system will always call garpback whenever garp calls the local system:
Ugarp,garp c /usr/spool/uucppublic /usr/spool/news
Callback adds to the security of UUCP. Normally there is no way to be sure that a computer calling up and claiming to be garp, for example, is really garp. It might be another system that belongs to a computer cracker who has learned garp's UUCP login and password. If you call back the remote system, however, you can be reasonably sure that you are connecting to the right system.
NOTE: Only one system out of each pair of communicating systems can have a c in its USERFILE to enable the callback feature. If both ends of a connection enable callback, they will loop endlessly - calling each other, hanging up, and calling back. For more information, see the comments on callback in Chapter 14, Telephone Security.
Here is a sample USERFILE:
, /usr/spool/uucppublic # Next line not needed in BSD 4.2 or 4.3 nuucp, /usr/spool/uucppublic dan, /usr/spool/uucppublic /u1/dan csd, /usr/spool/uucppublic /u1/csd root, / udecwrl,decwrl /usr/spool/uucppublic /usr/spool/news upyrnj,pyrnj /usr/spool/uucppublic /usr/src
As noted earlier, in some systems the first line defines both the missing username and the missing system name and gives access to the directory /usr/spool/uucppublic. In other implementations of UNIX, two separate lines are required: The first line will suffice for the missing username, and another line, such as the second one shown here (the line beginning with nuucp), will account for the missing system name.
The effect of these lines is to allow any local user, and any remote machine, to transfer files only from the public directory.
If you don't have any particularly trusted sites or users, you may want to stop at this point. However, if you want to give special privileges to particular local users, you'll include lines such as the next three (the lines beginning with dan, csd, and root). Users dan and csd can transfer files to or from their home directories as well as from the public directory. Users logged in as root can transfer files to or from any directory. (This structure makes sense, as they can do anything else, including modifying USERFILE to suit their needs or whims.)
Finally, you may need to specify particular permissions for known local systems. In the example, decwrl is able to transfer files to /usr/spool/news as well as to the public directory. The site pyrnj is able to transfer files to and from /usr/src as well as to and from the public directory.
If you are not very concerned about security, the following USERFILE might suffice:
# A wide open USERFILE nuucp, /usr/spool/uucppublic , /
However, we recommend against it! This USERFILE will allow remote systems (assuming that they all log in as nuucp) to transfer files to or from the public directory, but will give complete UUCP access to local users. This is dangerous and is not recommended, as it allows local users access to any protected file and directory that is owned by uucp.
If you don't talk to the outside world and are using UUCP only for communication with UNIX sites inside your organization, you might use the following USERFILE:
# A completely open USERFILE , / , /
This userfile will allow any user on your system, or any remote system, to transfer files to or from any directory. This example is even more dangerous than the previous one. (Note that on many systems, two lines are necessary, even though they are identical. The first line defines the missing username, and the other line defines the missing system name. In some systems, a single line will suffice, but you will never be wrong if you include both of them.)
Remember that even with complete access specified in USERFILE, UUCP is still subject to UNIX file permissions. A user requesting outbound transfer of a file must have read access to it. For a remote system to have access to a file or directory, the file or directory must be readable and writable by all users, or by UUCP.
NOTE: If you wish to run a secure system, the directory /usr/lib/uucp (or /etc/uucp) must not be in the permission list! If users from the outside are allowed to transfer into these directories, they can change the USERFILE or the L.cmds files to allow them to execute any command that they wish. Local users can similarly use the uucp command to change these files, and subvert UUCP. Giving all access from the / directory is also dangerous - such access makes it possible for people outside your organization to subvert your system easily, as they can then modify any directory on your system that is world writable.
For example, granting access to / lets an outsider read the contents of your /etc/passwd file, and also allows him to read and change the contents of your /usr/lib/uucp/L.sys file. As an added precaution, the home directory for the uucp user should not be in /usr/spool/uucp/uucppublic, or any other directory that can be written to by a uucp user. Doing so may allow an outside user to subvert your system.
You will probably want to limit the commands that can be executed by a remote system via uucp. After all, if any command could be executed by UUCP, then people on other computers could use the /bin/rm command to delete files in any writable directory on your computer! [7]
[7] This gives a new definition to the phrase "world writable."
For this reason, UUCP allows you to specify which commands remote systems are allowed to execute on your computer. The list of valid commands is contained in the directory /usr/lib/uucp in the file L.cmds, L-cmds, or uuxqtcmds (different versions store the command list in different files). Some early UNIX systems (Version 7 or earlier) may not have this file at all (and have no way of changing the defaults without modifying the source code to the uuxqt program.) For further information, check your own system's documentation.
In some versions of UUCP, the L.cmds file can also include a PATH= statement that specifies which directories uuxqt should check when searching for the command to execute.
A typical L.cmds file might contain the following list of commands:
PATH=/bin:/usr/bin:/usr/ucb rmail rnews lpr who finger
If a command is not in the commands file, uux cannot execute it. L.cmds should at least contain the rmail program (the remote mail program that decides whether mail is to be delivered locally or forwarded on to yet another system). If rmail is not listed in L.cmds, a local user will not be able to receive mail from remote users via UUCP.
Add commands to this file carefully; commands like cat or rm may place your system at risk. You should be careful about commands that allow shell escapes (such as man). Even finger can be dangerous if you are very concerned about security, because it might provide a cracker with a list of usernames to try when guessing passwords.
Look carefully at the L.cmds file that comes with your system: you may wish to remove some of the commands that it includes. For example, some BSD-derived systems include the ruusend command in this file, which allows file forwarding. This command is a security hole, because a remote system could ask your system to forward protected files that are owned by the uucp user, such as the file L.sys.
If the L.cmds file does not exist, UUCP will use a default set of commands. If the file exists but is empty, remote commands cannot be executed on your system. In this event, the UUCP system can be used only for transferring files.
|  | |
| 15.3 UUCP and Security |  | 15.5 Security in BNU UUCP |