Upablo IslaNegra
Ulorca co'rdoba
This file must be owned by uucp and have permissions of 600.
Does this database sound like such a good idea that you would like to use it on normal serial logins, too? Well, in some cases you can. What you need is a getty program that you can tell to invoke uucico instead of /bin/login for your UUCP users.[102] The invocation of uucico would look like this:
/usr/lib/uucp/uucico -l -u user
The -u option tells it to use the specified user name rather than prompting for it.[103]
To protect your UUCP users from callers who might give a false system name and snarf all their mail, you should add called-login commands to each system entry in the sys file. This is described in the next section.
Protecting Yourself Against Swindlers
A major problem with UUCP is that the calling system can lie about its name; it announces its name to the called system after logging in, but the server doesn't have any way to check it. Thus, an attacker could log into his or her own UUCP account, pretend to be someone else, and pick up that other site's mail. This is particularly troublesome if you offer login via anonymous UUCP, where the password is made public.
You must guard against this sort of impostor. The cure for this disease is to require each system to use a particular login name by specifying a called-login in sys. A sample system entry may look like this:
system pablo
... usual options ...
called-login Upablo
The upshot is that whenever a system logs in and pretends it is pablo, uucico checks whether it has logged in as Upablo. If it hasn't, the calling system is turned down, and the connection is dropped. You should make it a habit to add the called-login command to every system entry you add to your sys file. It is important that you do this for all systems in your sys file, regardless of whether they will ever call your site or not. For those sites that never call you, you should probably set called-login to some totally bogus user name, such as neverlogsin.
Be Paranoid: Call Sequence Checks
Another way to fend off and detect impostors is to use call sequence checks. These help you protect against intruders who somehow manage to find out the password with which you log into your UUCP system.
When using call sequence checks, both machines keep track of the number of connections established so far. The counter is incremented with each connection. After logging in, the caller sends its call sequence number, and the receiver checks it against its own number. If they don't match, the connection attempt is rejected. If the initial number is chosen at random, attackers will have a hard time guessing the correct call sequence number.
But call sequence checks do more for you. Even if some very clever person should detect your call sequence number as well as your password, you will find out. When the attacker calls your UUCP feed and steals your mail, this will increase the feeds call sequence number by one. The next time you call your feed and try to log in, the remote uucico will refuse you, because the numbers don't match anymore!
If you have enabled call sequence checks, you should check your log files regularly for error messages that hint at possible attacks. If your system rejects the call sequence number the calling system offers, uucico will put a message into the log file saying something like, "Out of sequence call rejected." If your system is rejected by its feed because the sequence numbers are out of sync, it will put a message in the log file saying, "Handshake failed (RBADSEQ)."
To enable call sequence checks, add the following command to the system entry:
# enable call sequence checks
sequence true
In addition, you have to create the file containing the sequence number itself. Taylor UUCP keeps the sequence number in a file called .Sequence in the remote site's spool directory. It must be owned by uucp and must be mode 600 (i.e., readable and writeable only by uucp). It is best to initialize this file with an arbitrary, previously agreed-upon start value. A simple way to create this file is:
# cd /var/spool/uucp/pablo
# echo 94316 ›.Sequence
# chmod 600.Sequence
# chown uucp.uucp.Sequence
Of course, the remote site has to enable call sequence checks as well and start by using exactly the same sequence number as you.
Anonymous UUCP
If you want to provide anonymous UUCP access to your system, you first have to set up a special account for it as previously described. A common practice is to give the anonymous account a login name and a password of uucp.
In addition, you have to set a few of the security options for unknown systems. For instance, you may want to prohibit them from executing any commands on your system. However, you cannot set these parameters in a sys file entry because the system command requires the system's name, which you don't have. Taylor UUCP solves this dilemma through the unknown command. unknown can be used in the config file to specify any command that can usually appear in a system entry:
unknown remote-receive ~/incoming unknown remote-send ~/pub unknown max-remote-debug none unknown command-path /usr/lib/uucp/anon-bin unknown commands rmail
This will restrict unknown systems to downloading files from below the pub directory and uploading files to the incoming directory below /var/spool/uucppublic. The next line will make uucico ignore any requests from the remote system to turn on debugging locally. The last two lines permit unknown systems to execute rmail; but the command path specified makes uucico look for the rmail command in a private directory named anon-bin only. This restriction allows you to provide some special rmail that, for instance, forwards all mail to the superuser for examination. This allows anonymous users to reach the maintainer of the system, but at the same time prevents them from injecting any mail to other sites.
To enable anonymous UUCP, you must specify at least one unknown statement in config. Otherwise uucico will reject all unknown systems.
UUCP Low-Level Protocols
To negotiate session control and file transfers with the remote end, uucico uses a set of standardized messages. This is often referred to as the high-level protocol. During the initialization phase and the hangup phase these are simply sent across as strings. However, during the real transfer phase, an additional low-level protocol that is mostly transparent to the higher levels is employed. This protocol offers some added benefits, such as allowing error checks on data sent over unreliable links.
102
Gert Doering's mgetty is such a beast. It runs on a variety of platforms, including SCO Unix, AIX, SunOS, HP-UX, and Linux.