UUCP READ and WRITE Options
These options specify the various parts of the file system that uucico can read from or write to. You can designate READ and WRITE options with either MACHINE or LOGNAME entries.
The default for both the READ and WRITE options is the uucppublic directory, as shown in the following strings:
READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic |
The strings READ=/ and WRITE=/ specify permission to access any file that can be accessed by a local user with Other permissions.
The value of these entries is a colon-separated list of path names. The READ option is for requesting files, and the WRITE option is for depositing files. One of the values must be the prefix of any full path name of a file entering or exiting. To grant permission to deposit files in /usr/news as well as the public directory, use the following values with the WRITE option:
WRITE=/var/spool/uucppublic:/usr/news |
If the READ and WRITE options are used, all path names must be specified because the path names are not added to the default list. For instance, if the /usr/news path name were the only path specified in a WRITE option, permission to deposit files in the public directory would be denied.
Be careful which directories you make accessible for reading and writing by remote systems. For example, the /etc directory contains many critical system files. Remote users should not have permission to deposit files in this directory.
UUCP NOREAD and NOWRITE Options
The NOREAD and NOWRITE options specify exceptions to the READ and WRITE options or defaults. The following entry permits reading any file except those files in the /etc directory (and its subdirectories--remember, these options are prefixes).
READ=/ NOREAD=/etc WRITE=/var/spool/uucppublic |
This entry permits writing only to the default /var/spool/uucppublic directory. NOWRITE works in the same manner as the NOREAD option. You can use the NOREAD and NOWRITE options in both LOGNAME and MACHINE entries.
UUCP CALLBACK Option
You can use the CALLBACK option in LOGNAME entries to specify that no transaction occurs until the calling system is called back. The reasons to set up CALLBACK are as follows:
For security purposes - If you call back a machine, you can be sure it is the right machine.
For accounting purposes - If you are doing long data transmissions, you can choose the machine that is billed for the longer call.
The string CALLBACK=yes specifies that your computer must call back the remote computer before any file transfers can occur.
The default for the CALLBACK option is CALLBACK=no. If you set CALLBACK to yes, the permissions that affect the rest of the conversation must be specified in the MACHINE entry that corresponds to the caller. Do not specify these permissions in the LOGNAME, or in the LOGNAME entry that the remote machine might have set for your host.
Note - If two sites have the CALLBACK option set for each other, a conversation never is started.
UUCP COMMANDS Option
Caution - The COMMANDS option can compromise
the security of your system. Use it with extreme care.
You can use the COMMANDS option in MACHINE entries to specify the commands that a remote computer can execute on your machine. The uux program generates remote execution requests and queues them to be transferred to the remote computer. Files and commands are sent to the target computer for remote execution. This is an exception to the rule that MACHINE entries apply only when your system calls out.
Note that COMMANDS is not used in a LOGNAME entry. COMMANDS in MACHINE entries defines command permissions, whether you call the remote system or it calls you.
The string COMMANDS=rmail specifies the default commands that a remote computer can execute on your computer. If a command string is used in a MACHINE entry, the default commands are overridden. For instance, the following entry overrides the COMMAND default so that the computers that are named owl, raven, hawk, and dove can now execute rmail, rnews, and lp on your computer.
MACHINE=owl:raven:hawk:dove COMMANDS=rmail:rnews:lp |
In addition to the names as just specified,you can have full path names of commands. For example, the following entry specifies that command rmail uses the default search path.
COMMANDS=rmail:/usr/local/rnews:/usr/local/lp |
The default search path for UUCP is /bin and /usr/bin. When the remote computer specifies rnews or /usr/local/rnews for the command to be executed, /usr/local/rnews is executed regardless of the default path. Likewise, /usr/local/lp is the lp command that is executed.
Including the ALL value in the list means that any command from the remote computers that are specified in the entry is executed. If you use this value, you give the remote computers full access to your machine.
Caution - This value allows far more access than normal users have. You
should use this value only when both machines are at the same site, are closely
connected, and the users are trusted.
Here is the string with the ALL value added:
COMMANDS=/usr/local/rnews:ALL:/usr/local/lp |
This string illustrates two points:
The path names that are specified for rnews and lp are used (instead of the default) if the requested command does not contain the full path names for rnews or lp.
You should use the VALIDATE option whenever you specify potentially dangerous commands, such as cat and uucp with the COMMANDS option. Any command that reads or writes files is potentially dangerous to local security when it is executed by the UUCP remote execution daemon (uuxqt).
UUCP VALIDATE Option
Use the VALIDATE option in conjunction with the COMMANDS option whenever you specify commands that are potentially dangerous to your machine's security. VALIDATE is merely an added level of security on top of the COMMANDS option, though it is a more secure way to open command access than ALL.
VALIDATE provides a certain degree of verification of the caller's identity by cross-checking the host name of a calling machine against the login name it uses. The following string ensures that if any machine other than widget or gadget tries to log in as Uwidget, the connection is refused.
LOGNAME=Uwidget VALIDATE=widget:gadget |
The VALIDATE option requires privileged computers to have a unique login and password for UUCP transactions. An important aspect of this validation is that the login and password that are associated with this entry are protected. If an outsider obtains that information, that particular VALIDATE option can no longer be considered secure.
Carefully consider which remote computers you are granting privileged logins and passwords for UUCP transactions. Giving a remote computer a special login and password with file access and remote execution capability is like giving anyone on that computer a normal login and password on your computer. Therefore, if you cannot trust someone on the remote computer, do not provide that computer with a privileged login and password.
The following LOGNAME entry specifies that if one of the remote computers that claims to be eagle, owl, or hawk logs in on your computer, it must have used the login uucpfriend:
LOGNAME=uucpfriend VALIDATE=eagle:owl:hawk |
If an outsider obtains the uucpfriend login and password, masquerading is easy.
But what does this entry have to do with the COMMANDS option, which appears only in MACHINE entries? This entry links the MACHINE entry (and COMMANDS option) with a LOGNAME entry that is associated with a privileged login. This link is needed because the execution daemon is not running while the remote computer is logged in. Actually, the link is an asynchronous process that does not know which computer sent the execution request. Therefore, the real question is, how does your computer know where the execution files came from?
Each remote computer has its own spool directory on your local machine. These spool directories have write permission that is given only to the UUCP programs. The execution files from the remote computer are put in its spool directory after being transferred to your computer. When the uuxqt daemon runs, it can use the spool directory name to find the MACHINE entry in the Permissions file and get the COMMANDS list. Or, if the computer name does not appear in the Permissions file, the default list is used.
This example shows the relationship between the MACHINE and LOGNAME entries:
MACHINE=eagle:owl:hawk REQUEST=yes \ COMMANDS=rmail:/usr/local/rnews \ READ=/ WRITE=/ LOGNAME=uucpz VALIDATE=eagle:owl:hawk \ REQUEST=yes SENDFILES=yes \ READ=/ WRITE=/ |
The value in the COMMANDS option means that remote users can execute rmail and /usr/local/rnews.
In the first entry, you must assume that when you want to call one of the computers that is listed, you are really calling either eagle, owl, or hawk. Therefore, any files that are put into one of the eagle, owl, or hawk spool directories is put there by one of those computers. If a remote computer logs in and says that it is one of these three computers, its execution files are also put in the privileged spool directory. You therefore have to validate that the computer has the privileged login uucpz.
UUCP MACHINE Entry for OTHER
You might want to specify different option values for remote machines that are not mentioned in specific MACHINE entries. The need might arise when many computers are calling your host, and the command set changes from time to time. The name OTHER for the computer name is used for this entry as shown in this example:
MACHINE=OTHER \ COMMANDS=rmail:rnews:/usr/local/Photo:/usr/local/xp |
All other options available for the MACHINE entry can also be set for the computers that are not mentioned in other MACHINE entries.
Combining MACHINE and LOGNAME Entries for UUCP
You can combine MACHINE and LOGNAME entries into a single entry when the common options are the same. For example, the two sets of entries that follow share the same REQUEST, READ, and WRITE options:
MACHINE=eagle:owl:hawk REQUEST=yes \ READ=/ WRITE=/ |
and
LOGNAME=uupz REQUEST=yes SENDFILES=yes \ READ=/ WRITE=/ |
You can merge these entries, as shown:
MACHINE=eagle:owl:hawk REQUEST=yes \ logname=uucpz SENDFILES-yes \ READ=/ WRITE=/ |
Combining MACHINE and LOGNAME entries makes the Permissions file more manageable and efficient.