Security
========

   This discussion of UUCP security applies only to Unix.  It is a bit
cursory; suggestions for improvement are solicited.

   UUCP is traditionally not very secure.  Taylor UUCP addresses some
security issues, but is still far from being a secure system.

   If security is very important to you, then you should not permit any
external access to your computer, including UUCP.  Any opening to the
outside world is a potential security risk.

   When local users use UUCP to transfer files, Taylor UUCP can do
little to secure them from each other.  You can allow somewhat increased
security by putting the owner of the UUCP programs (normally `uucp')
into a separate group; the use of this is explained in the following
paragraphs, which refer to this separate group as `uucp-group'.

   When the `uucp' program is invoked to copy a file to a remote
system, it will, by default, copy the file into the UUCP spool
directory.  When the `uux' program is used, the `-C' switch must be
used to copy the file into the UUCP spool directory.  In any case, once
the file has been copied into the spool directory, other local users
will not be able to access it.

   When a file is requested from a remote system, UUCP will only permit
it to be placed in a directory which is writable by the requesting user.
The directory must also be writable by UUCP.  A local user can create a
directory with a group of `uucp-group' and set the mode to permit group
write access.  This will allow the file be requested without permitting
it to be viewed by any other user.

   There is no provision for security for `uucp' requests (as opposed
to `uux' requests) made by a user on a remote system.  A file sent over
by a remote request may only be placed in a directory which is world
writable, and the file will be world readable and writable.  This will
permit any local user to destroy or replace the contents of the file.
A file requested by a remote system must be world readable, and the
directory it is in must be world readable.  Any local user will be able
to examine, although not necessarily modify, the file before it is sent.

   There are some security holes and race conditions that apply to the
above discussion which I will not elaborate on.  They are not hidden
from anybody who reads the source code, but they are somewhat technical
and difficult (though scarcely impossible) to exploit.  Suffice it to
say that even under the best of conditions UUCP is not completely
secure.

   For many sites, security from remote sites is a more important
consideration.  Fortunately, Taylor UUCP does provide some support in
this area.

   The greatest security is provided by always dialing out to the other
site.  This prevents anybody from pretending to be the other site.  Of
course, only one side of the connection can do this.

   If remote dialins must be permitted, then it is best if the dialin
line is used only for UUCP.  If this is the case, then you should
create a call-in password file (see Configuration File Names.) and
let `uucico' do its own login prompting.  For example, to let remote
sites log in on a port named `entry' in the port file (*note port
File::.), you might invoke `uucico -e -p entry'.  This would cause
`uucico' to enter an endless loop of login prompts and daemon
executions.  The advantage of this approach is that even if remote users
break into the system by guessing or learning the password, they will
only be able to do whatever `uucico' permits them to do.  They will not
be able to start a shell on your system.

   If remote users can dial in and log on to your system, then you have
a security hazard more serious than that posed by UUCP.  But then, you
probably knew that already.

   Once your system has connected with the remote UUCP, there is a fair
amount of control you can exercise.  You can use the `remote-send' and
`remote-receive' commands to control the directories the remote UUCP
can access.  You can use the `request' command to prevent the remote
UUCP from making any requests of your system at all; however, if you do
this it will not even be able to send you mail or news.  If you do
permit remote requests, you should be careful to restrict what commands
may be executed at the remote system's request.  The default is `rmail'
and `rnews', which will suffice for most systems.

   If different remote systems call in and they must be granted
different privileges (perhaps some systems are within the same
organization and some are not) then the `called-login' command should
be used for each system to require that they use different login names.
Otherwise, it would be simple for a remote system to use the `myname'
command and pretend to be a different system.  The `sequence' command
can be used to detect when one system pretended to be another, but,
since the sequence numbers must be reset manually after a failed
handshake, this can sometimes be more trouble than it's worth.