SunOS 4.x already has a very large user community. The system provides a transparent file access service by means of a Secure RPC implementation of client and server NFS. The use of Secure RPC for NFS is a great improvement over the user ID/group ID authentication mechanism, referred to as ``UNIX authentication,'' used in most NFS configurations (see sec. 9.2.8 and sec. 10.2.8).
A remote execution service, similar to rsh, is provided by rpc.rexd. The server process rpc.rexd must be configured in the inetd.conf file with the ``-s'' option to insure that Secure RPC is used for authentication. Without the ``-s'' option, rpc.rexd is invoked using only the user ID/group ID as a means of identifying the user. As is the case with NFS, using the user ID/group ID as a means of authentication is a weak mechanism. When used with rpc.rexd, the vulnerability is even greater. With NFS, the ability to authorize client systems to mount exported file systems makes it difficult for unauthorized client systems to exploit the weaknesses of the user ID/group ID authentication mechanism. When rpc.rexd is invoked without the ``-s'' option, any system on the network can attempt to exploit the weaknesses of the user ID/group ID authentication mechanism.
Some measure of protection can be achieved by using a ``wrapper'' (see sec. 10.3.2 and [LeF92]). The technique described in [LeF92] provides a capability for a rpc.rexd server to restrict access to specified clients. Note that the technique of [Ven92] is not applicable.
The technique of [LeF92] only restricts access by IP address. Once access is provided to a client workstation, the user ID/group ID is still used as an authentication mechanism. Thus, a client with access can still exploit the weaknesses of this authentication mechanism. With NFS, the server can be configured to export to a client only those files which belong to the owner of that client. Consequently, if the owner of that client should try to impersonate another user, no harm is done since only the owner's files are exported to the client. However, the rpc.rexd server (in the absence of the ``-s'' option) initiates commands on behalf of the user ID/group ID which initiated the call. The server implicitly trusts the user ID/group ID it is given.
In addition, the technique of [LeF92] does not protect against IP address impersonation. This is easy to accomplish on a subnet when a system is turned off frequently or its network connection is not functioning.
To summarize, rpc.rexd should almost never be run without some added security. The technique of [LeF92] offers some measure of protection by allowing only certain client systems access but provides no method of user authentication other than the default user ID/group ID mechanism. Using Secure RPC (rpc.rexd with the ``-s'' option) is the preferred method of providing proper user authentication.
The client side of rpc.rexd is the on command. The rpc.rexd server may also be called from an application program using the rex protocol defined in /usr/include/rpcsvc/rex.x. When the on command is invoked, the current default directory on the on client must be part of a file system exported to the rpc.rexd server. Since this may not be desirable, implementing a version of on that does not require this may be required. Such an implementation is relatively straightforward [SUN90a]. An example of such an implementation is given in Appendix C.
A remote login service, similar to rlogin, can be provided in SunOS 4.x either by using the command:
on -i <server>or by combining the capabilities of on/rpc.rexd and the X application xterm. The command:
on <server> xterm <options>provides an xterm window to <server>. If rpc.rexd is configured with the ``-s'' option, then the user is authenticated to the server by means of Secure RPC. Using this method of providing a remote login capability implies that the X security mechanism used by the client workstation's X Server is SUN-DES-1 which uses the same facilities which support Secure RPC (see Chapter 7). While this is not required, using the SUN-DES-1 X security option with the X server is likely the most convenient. If some other X security option is configured, that choice should at least provide the robustness of the SUN-DES-1 option. Note that the SUN-DES-1 option requires the X11R5 X server. Neither Open Windows versions 2.x or 3.x provide an X11R5 X server. An X11R5 X server can be obtained from MIT.
While NFS implemented using Secure RPC should provide most of the requirements for a file transfer service, i.e., most files needed from a server could be at least exported read-only, some files located on a server may not be exported. A file transfer service can be provided by combining the capabilities of on/rpc.rexd and NFS. By using the remote login or remote execution services provided by on/rpc.rexd, a needed file can be copied to the user's exported file system. From there, the file can be copied to a local file system.
Although SunOS 4.x provides some services authenticated by Secure RPC, the NIS Name Service which is needed by Secure RPC is not provided with that level of authentication. This can be a serious weakness.