S 5.35 Use of the security mechanisms of UUCP

Initiation responsibility: Administrator, IT Security Officer

Implementation responsibility: Administrator

The UUCP (Unix-to-Unix Copy) program package included in the standard scope of Unix systems and also available for other operating systems allows the exchange of data between IT systems and execution of commands on remote IT systems. The only prerequisite is the compatibility of the uucico programs on both systems involved. UUCP is widespread even if its importance has declined, e.g. due to the option of connecting computers using ISDN with the help of TCP/IP.

UUCP is normally used in order to exchange emails and news between computers (uucp). It also enables logging in (cu) and execution of programs (uux) on third party computers.

There are different UUCP variants: Along with the implementation developed by Peter Honeyman, David Nowitz, and Brian E. Redman in1983 (HoneyDanBer UUCP), the initial UUCP system of AT&T UNIX version 7, the second version of which is up to date (this UUCP implementation is therefore also called version 2 UUCP), or the Tahoe-UUCP (delivered together with BSD 4.3) are also frequently used.

The UUCP variant used can be recognised when looking at the files in the /usr/lib/uucp directory (/etc/uucp on some systems): In version 2 UUCP, the L.sys file can be found here; for HoneyDanBer UUCP, the Systems file.

Version 2 UUCP is characterised by severe security problems (error in uucico, risk of misconfiguration due to the complex form of the security-relevant administration files). Therefore, it should not be used and the HoneyDanBer UUCP should be used instead.

In general, the following security questions should be considered when using UUCP:

• The administration of UUCP requires intense engagement with the configuration options and the related files. It must be taken into consideration that there may be deviations between the UUCP packages of the different Unix derivatives, even if these are based on the HoneyDanBer UUCP.
• The administration of the UUCP files, programs, and directories is subject to the same requirements as the administration of system files and directories (see S 2.25 Documentation of the system configuration, S 2.31 Documentation of authorised users and rights profiles, S 4.19 Restrictive allocation of attributes for Unix system files and directories).
• The majority of the systems include a user called uucp. This user is the owner of the UUCP files, programs, and directories. It must be ensured that this account has a password corresponding to the specifications of safeguard S 2.11 Provisions governing the use of passwords.
  
  The home directory for the uucp user must not be the public directory /usr/spool/uucppublic, but a separate directory only accessible by the uucp user.
• For every IT system that is to be able to register with the local IT system via UUCP, the /etc/passwd file must contain a separate user identifier and a password. The selected UID must not be the UID of the uucp user, but any individual UID must be selected for every remote IT system.
• UUCP passwords are transmitted in an unencrypted manner during communication requests and are stored in an unencrypted manner in the corresponding UUCP configuration file for requirements regarding remote computers. Depending on the application and the environment (particularly when using wide area networks), corresponding security safeguards must be taken, e.g. the use of one-time passwords.

Different configuration files must be created in order to use UUCP. All settings must be documented and deviations from the settings mentioned below must include a short justification so that the purpose of this change can be comprehended later.

The following files must be administered with particular care, because they contain security-critical information. They are located in the directory /usr/lib/uucp and/or /etc/uucp). Only the uucp user must be provided write access to these directories.

• Systems: This file contains the information required to establish connections to remote IT systems. Here, the periods when the transmission via UUCP is permissible can be defined for every single IT system. These periods must be as short as possible. Furthermore, the file contains the phone numbers and login sequences of the IT systems a connection can be established to via UUCP. The Systems file must only be accessed (write access) by the uucp owner, since the passwords for the remote IT systems are also transferred.
• Permissions: Here, access rights for remote systems are specified. At the time of delivery, the Permissions file does not contain any IT systems, i.e. no accesses are possible using UUCP. For every computer allowed to call and log in and for every computer allowed to be called, settings regarding the definition of the respectively necessary access rights and other conditions must be performed here. The access rights for the IT systems called by the local IT system are specified in the entries following below MACHINE; those for the calling IT systems in those following below LOGNAME. These security options can be used to the full extent in order to significantly increase the security.
  
  The uucheck -v command should be used to regularly check the options set in the Permissions file. The options should be set as follows:
  • REQUEST
    This option should be set to NO (default setting) to prevent remote systems from reading local data.
  • COMMANDS
    On no account should ALL be entered here; only required commands like rnews or rmail should be allowed. The commands should be stated with the full path name.
  • WRITE/READ
    If this option is not specified, write/read access is only possible to the /usr/spool/uucppublic directory. Directories to which access is allowed by means of this option must be documented together with the reasons for access. On no account should the root directory or the one containing the UUCP configuration files be entered here.
  • NOWRITE/NOREAD
    This specifies exceptions to the WRITE/READ option. Directories containing sensitive information should generally be listed here. This prevents access to such directories by remote IT systems resulting from negligence to impose restrictions if higher-level directories are released with READ/WRITE.
  • PUBDIR
    This can be used to specify a public UUCP directory in place of /usr/spool/uucppublic. For UUCP communication involving several IT systems, a separate UUCP directory must be stated here for each of these systems.
  • CALLBACK
    If CALLBACK is set to YES, the local IT system must call back the calling IT system before data exchange can commence. Of course, this is only useful for LOGNAME entries. The communication partners should agree on who is to activate a CALLBACK:
  • MYNAME
  • If MYNAME=name is set, the local system identities itself with name instead of the computer designation when a UUCP connection is established with a remote system. This feature should be used for identification with a name which is intended exclusively for this connection and thus is not easy to figure out.
  • VALIDATE
    If VALIDATE=name is set, only IT systems listed under name can establish a connection via the systems listed under LOGNAME. This option absolutely must contain an entry, otherwise remote IT systems will be capable of masquerading by impersonating another computer name using MYNAME:
  • SENDFILES
    The default setting (SENDFILE=CALL) should be retained here, so that jobs in the local queue are only transferred outside on establishment of a connection by the local IT system.
  
  
  
• The /usr/lib/uucp/remote.unknown file of the HoneyDanBer UUCP is executed if an unknown IT system, i.e. an IT system not contained in the Systems file, attempts to establish a connection. It logs the attempt and rejects it. If remote.unknown cannot be executed, the local IT system accepts all connection requests of remote IT systems. Therefore, it must be ensured that remote.unknown can be executed at all times. remote.unknown is implemented as executable shell script or C program depending on the Unix system. If remote.unknown is implemented as shell script on the local IT system, it should be replaced by a program due to reasons of security. Otherwise, there is the risk of a calling IT command entering a command such as "cat < /etc/passwd" as system name, which then may be executed.
• for UUCP, there are a couple of cleanup shell scripts executed automatically via the crontab daemon. This must not be initiated by root, as is usual on many systems, but must be performed by the uucp user.

When using UUCP, different log files are created automatically. For the HoneyDanBer UUCP, these can be found in the subdirectories of /usr/spool. Here, successful and rejected connection attempts, the sent and received amounts of data, error messages, and data transfer statistics are documented. These log files must be evaluated regularly (see also S 4.25 Use of logging in Unix systems).

Review questions:

• Are the security mechanisms of uucp used?
• Does the level of security regarding the administration of uucp files, programs, and directories correspond to the system files and directories?