 | Chapter 15 UUCP |  |
| Chapter 15 UUCP | |
Any system that allows files to be copied from computer to computer and allows commands to be remotely executed raises a number of security concerns. What mechanisms exist to prevent unauthorized use? What prevents an attacker from using the system to gain unauthorized entry? What prevents an attacker from reverse engineering the system to capture confidential information? Fortunately, UUCP has many security measures built into it to minimize the dangers posed by its capabilities. For example:
The uucico program must log into your system to transfer files or run commands. By assigning a password to the uucp account, you can prevent unauthorized users from logging in.
The UUCP programs run SUID uucp, not SUID root. Other than being able to read the spooled UUCP files, the uucp user doesn't have any special privileges. It can read only files that are owned by uucp or that are readable by everybody on the system; likewise, it can create files only in directories that are owned by uucp or in directories that are world writable.
The UUCP login does not receive a normal shell, but instead invokes another copy of uucico. The only functions that can be performed by this copy of uucico are those specified by the system administrator.
As system administrator, you have a few more tools for controlling the level of security:
You can create additional /etc/passwd entries for each system that calls your machine, allowing you to grant different privileges and access to different remote computers.
You can configure UUCP so remote systems can retrieve files only from particular directories. Alternatively, you can turn off remote file retrieval altogether.
You can require callback for certain systems, so you can be reasonably sure that the UUCP system you are communicating with is not an impostor.
But even with these protective mechanisms, UUCP can compromise system security if it is not properly installed. And once one system is compromised, it can be used to compromise others, because UUCP passwords are stored unencrypted.
NOTE: If you run an NFS server on the same computer that you use for UUCP, the NFS server must not export the UUCP configuration, program, or data directories. This is because the UUCP files are owned by the uucp user, not by the user root. In standard NFS, only files owned by root are protected. Thus, an attacker could use NFS to modify the UUCP files on your system, and use that modification as a means for gaining further access.
Most Berkeley UNIX systems come with two UUCP logins. The first is used by computers that call and exchange information using uucico:
uucp:Ab1zDIdS2/JCQ:4:4:Mr. UUCP:/usr/spool/uucppublic/:/usr/lib/uucp/uucico
The second UUCP login, usually called uucpa or nuucp, has a regular shell as its login shell. It is used for administration. (The "a" stands for "administrator.")
uucp:Ab1zDIdS2/JCQ:4:4:Mr. UUCP:/usr/lib/uucp/uucico uucpa:3jd912JFK31fa:4:4:UUCP Admin:/usr/lib/uucp/:/bin/csh
(System V systems usually use the account name uucp as the administrative login and nuucp as the uucico login.)
These two logins are all that you need to use UUCP. Every machine that calls you uses the same uucp login. In most cases, every machine will be granted the same type of access on your machine.
Alternatively, you may wish to assign a different login to each machine that calls you. This lets you grant different classes of access to each machine, and gives you a lot more control over each one.
For example, if you are called by the machines garp, idr, and prose, you might want to have a separate login for each of these machines[6]:
[6] Many system administrators capitalize the "U" at the beginning of dedicated UUCP login names. This notation helps to distinguish the login names from usernames that might begin with a lower-case "u" (e.g., ursula and ulrich). Furthermore, some software uses this convention to trigger special behavior - such as mgetty in Linux, which will switch to uucico instead of login. Reliance on such naming is a questionable design from a security point of view, but we do note the convention.
uucp:asXN3sQefHsh:4:4:Mr. UUCP:/usr/spool/uucppublic/:/usr/lib/uucp/uucico Ugarp:ddGw1opxMz1MQ:4:4:UUCP Login for garp:/usr/spool/uucppublic/ :/usr/lib/uucp/uucico Uprose:777uf2KOKdbkY:4:4:UUCP Login for prose:/usr/spool/uucppublic/ :/usr/lib/uucp/uucico Uidr:asv.nbgMNy/cA:4:4:UUCP Login for idr:/usr/spool/uucppublic/ :/usr/lib/uucp/uucico
The only differences between these logins are their usernames, passwords, and full names; the UIDS, home directories, and shells all remain the same. Having separate UUCP logins lets you use the last and finger commands to monitor who is calling you. Separate logins also make the task of tracing security leaks easier: for example, one machine dialing in with one username and password, but pretending to be another. Furthermore, if you decide that you no longer want a UUCP link with a particular system, you can shut off access to that site by changing the password of one of the UUCP logins without affecting other systems.
If you have many UUCP connections within your organization and only a few to the outside, you may wish to compromise by having one UUCP login for your local connections and separate UUCP logins for all of the systems that dial in from outside.
Many UNIX systems come without passwords for their UUCP accounts; be sure to establish passwords for these accounts immediately, whether or not you intend to use UUCP.
Because the shell for UUCP accounts is uucico (rather than sh, ksh, or csh), you can't set the passwords for these accounts by su-ing to them and then using the passwd command. If you do, you'll get a copy of uucico as your shell, and you won't be able to type sensible commands. Instead, to set the password for the UUCP account, you must become the superuser and use the passwd command with its optional argument - the name of the account whose password you are changing. For example:
% /bin/su password: bigtime! Superuser password # passwd uucp New password: longcat! New password for the uucp account Re-enter new password: longcat!
Because it logs in to remote systems, uucico has to keep track of the names, telephone numbers, account names, and passwords it uses to log into these machines. This information is kept in a special file called /usr/lib/uucp/L.sys (in Version 2) or /usr/lib/uucp/Systems (in BNU).
The information in the L.sys or Systems file can easily be misused. For example, somebody who has access to this file can program his or her computer to log into one of the machines that you exchange mail with, pretending to be your machine, and in this way get all of your electronic mail!
To protect the L.sys or Systems file, make sure that the file is owned by the uucp user and is mode 400 or 600 - that is, unreadable to anybody but UUCP.
You should check to make sure that there is no way to read or copy your L.sys or Systems file by using the uucp program. You should also make sure that the uucp program does not allow people on remote machines to retrieve your /etc/passwd file when they specify pathnames such as "../../../../etc/passwd."
NOTE: When debugging a UUCP connection to a remote site, you may wish to run the uucico command in debug mode. When you do so, the command prints a running account of the data exchanged with the remote machine. On most systems, if you do this as root (or as a user with read permission on the L.sys or Systems file, e.g., a user in group uucp), then the debug text will include the telephone number, account name, and possibly the password(s) of the remote site. Thus, run in debug mode as a non-privileged user, or in a secured location to prevent someone from snooping.
|  | |
| 15.2 Versions of UUCP |  | 15.4 Security in Version 2 UUCP |