Security in a networked environment

The UNIX operating system was originally designed for stand-alone machines, and includes effective security mechanisms for that environment. It also provides flexible mechanisms for giving privileges to application programs. Misuse of this flexibility by privileged programs can result in reduced system security.

Additional security issues arise when a machine running a UNIX system is connected to a network. Much of the current network software design assumes what is called a ``single administrative domain.'' This means that the design assumes that all machines with access to the network are maintained and controlled by a single group of trusted people.

In enterprise networks, where various groups of computer systems are administered and controlled by differing groups of people, these assumptions are no longer valid. This makes the security of the system more difficult to maintain. The computer industry is working to address these issues and expects to see rapid improvement in the security of enterprise networks.

The material in this section is intended to help system administrators to understand the security issues arising from connecting SCO OpenServer systems to enterprise networks and to provide advice on how to maintain security. The intent is to explain which system facilities might be vulnerable to attack by a ``hostile user'', and the actions you can take to reduce the risk.

More information on identifying potential security problems is available in these books:

UNIX System Security
Patrick H. Wood and Stephen G. Kochan
Hayden Books, 0-8104-6267-2

Building A Secure Computer System
Morrie Gasser
Van Nostrand Reinhold, 0-442-23022-2

Network Information Service

The Network Information Service (NIS, formerly known as ``Yellow Pages'') is designed for use on networks consisting of a single administrative domain. However, the protocol used by NIS should not be considered secure even in this type of environment. Due to the design of the NIS protocols, the use of NIS for security information (such as account administration with /etc/passwd and /etc/group), is not recommended for any network that connects to systems in another administrative domain. Even then, to prevent abuse of the NIS system, the ypserv(NADM) daemon should always be invoked with the -ypsetme option. Alternative configurations should be carefully considered by NIS experts prior to installation and configuration.

We are working along with the rest of the industry to provide a more secure distributed system management framework than NIS currently provides. In the interim, to minimize the system security risks associated with the use of NIS, we are providing as much functionality as possible while maintaining interoperability with other systems,

The graphical environment

Due to the design of the X11 windowing system, any program that is allowed to access the X display may intercept any and all keyboard events. This, combined with the common use of programs (such as rlogin, su, or telnet) which query the user for password information, can result in giving away passwords to other users.

Users of the X Window System should be very careful about which systems they grant access to their X server. When granting access is combined with the use of X terminals on unsecured networks, serious security problems can arise. Many X terminals default to allowing any and all X clients to communicate with the X display, thus making any system connected to the network a potential source of a security violation.

In previous releases, xhost was the only mechanism for controlling access to the server. xhost allows you to specify what machines are allowed to connect to your server, which is acceptable if you trust everyone who has an account on the client system.

SCO OpenServer systems support the MIT-MAGIC-COOKIE-1 Authorization Protocol, which is implemented by the X server, scologin, Xlib, and the xauth(X) client. Under this protocol, when a user uses scologin to log in to the X server, scologin adds a random access code called a ``magic cookie'' to a file in the user's home directory called .Xauthority. It also passes the magic cookie to the server where it is stored in an area that can only be read by the server. The user's .Xauthority file now contains the information needed to connect to the server. Normally, only the user has read and write permissions on this file.

When a client attempts to connect to the server, it must first read the user's .Xauthority file and pass the magic cookie to the server in order to obtain a connection. If the magic cookie is incorrect, the server refuses that connection. If the correct magic cookie is presented, then the server accepts the connection, regardless of where the client is actually running.

The xauth program allows you to edit the .Xauthority file and can be used in conjunction with rcp(TC) to pass the magic cookies to other systems and users.

To set up the Xauthorization mechanism for the system, edit the file /usr/lib/X11/scologin/Xconfig and add the following line:

   DisplayManager.display.authorize: True

Network mail

Mail received via the SMTP protocol should not be considered genuine. It is quite easy to forge mail that, when received, looks like it came from any user on any system (for example joe@your_company.COM), even though that user did not send the message.

If SMTP has been installed on the system, even mail that appears to have come from a local user may actually be a forged message. Only if the SMTP channel is removed from the mail configuration can mail be considered genuine. Even then, anyone with root privileges can create a forged mail message.

Therefore, mail headers should never be taken too seriously because they are so easily forged. Negotiations are under way for creating a more robust, secure mail system suitable for world-wide communications. Until a draft standard is written, all mail messages of vital importance should be cross-checked by some other means.