Chapter Contents

Previous

Next
Installing and Administering the NFS Client

NFS Security Administration

The installation of NFS client software on any system should be a security concern for administrators of NFS servers. The availability of client software might enable file access by users to whom the access was not previously possible.

All security on NFS servers is via UNIX (or POSIX) UIDs and GIDs. The UID is a number that represents a user. The GID represents a group of users. The NFS design assures that all participating machines share the same UID and GID assignments. MVS users are identified by a security system such as RACF or ACF2. CMS users are identified by entries in a CP directory. UNIX UIDs and GIDs are not normally associated with mainframe users.

Administrators of NFS servers can usually control, on a file system basis, which client machines can access files via NFS. When security is a concern, the ability of the client machine to allow only authorized UID and GID associations is the most important factor. The CSL NFS client software derives its UID and GID associations from a combination of mainframe security system and UNIX servers. The exact source authorization depends on site configuration.

Because of differences between UNIX and mainframe operating systems, and because of a lack of reserved port controls in current mainframe TCP/IP implementations, the CSL NFS client software is generally less secure (in authorizing UID and GID associations) than most UNIX NFS client implementations. Methods of attack are briefly described in the SAS/C CSL installation instructions. Note that it is server file security that is of concern. An NFS client implementation can pose no additional security threat to files on the client (in this case the mainframe) unless it gives unauthorized access to files containing passwords. Note also that most UNIX NFS servers allow controls for which file systems can be accessed, thus limiting exposure to unauthorized UID associations.

Because it can use authorizations that are provided by a mainframe security system, CSL NFS client software is generally more secure than NFS client implementations on PC operating systems.


UID/GID Acquisition

The SAS/C CSL NFS client software will always retrieve the UNIX UID and GID information from a UNIX server. The retrieval of the UID information is based on a UNIX username. The association of UNIX username to UID/GID is always performed by a UNIX server.

One of two methods is used to associate a UNIX username with a mainframe user. If there is a (RACF compatible) security system installed, profiles can be established to authorize mainframe users to UNIX usernames. Users whose mainframe login ID is the same as their UNIX username are a special case that can be authorized using a single profile. There is considerable flexibility in this assignment. For example, the association between mainframe userids and UNIX usernames need not be one-to-one. When this method is used, the sascuidd login server is used to provide UID information for that username. No UNIX password is required.

A second method is for the mainframe user to supply the desired username and password to the UNIX login server PCNFSD (version 2 if available, otherwise version 1), which authorizes the username (based on the password) and supplies UID information in one step.

The first method will generally be preferred when available because it makes login easier and removes the requirement that UNIX passwords be present on the mainframe.

For TSO or CMS users, the UID information is stored in environment variables. The UID is stored in NFS_UID . The primary GID is stored in NFS_GID . The list of supplementary GIDs ( sascuidd and PCNFSD V2 only) is stored in NFS_GIDLIST . NFS_LOGINDATE is set to the date of the login.

The environment variable NFS_LOGINKEY receives an encrypted value which is used by subsequent NFS calls to determine that these environment variables have not been tampered with.

NFS logins must be reissued each time the user logs in to TSO or CMS. Authorization is also lost after about 48 hours, even if the user does not log off. This prevents users from retaining their authorization indefinitely, even after they have had their UNIX authorizations removed.

At most 16 additional GIDs are allowed. This is the maximum supported by the PCNFSD protocol. A user who can login as UID 0 (root) will probably not be given full authority by the NFS server system. Most NFS servers remap UID 0 to a UID value of (unsigned short) -2 .

SAS/C NFS client capabilities cannot be used until a successful login has occurred. Successive calls to NFSLOGIN can be made in order to access a different server or to use a different login ID. If a security system is present to allow login without a password, the actual login may be performed automatically when an NFS operation is requested. No corresponding logout is required.

When a mainframe security system is present, it can also control which login server a user is allowed to access. This prevents users from rerouting their login authorization request to a less trusted machine. It also reduces the risk of a user sending a UNIX password to a "Trojan horse" program that is running on an unauthorized system.

Use of a mainframe security system requires the definition of a generalized resource named LSNUID. The mainframe security administrator can then enter profiles that give mainframe users access to particular login servers and equate mainframe userids with UNIX usernames. The next section describes this in detail.


RACF Definitions for NFS Clients

The SAS/C CSL NFS Client mainframe security system interface is based on profiles that are defined for a generalized resource named LSNUID. Using this resource, you grant specific mainframe users access to specific UNIX userids and login servers in the same way that DATASET profiles allow you to grant users access to mainframe files.

Until this resource is defined and activated, the NFS client code behaves as it does when no security system is installed.

Here is a description of the macro parameters needed to define LSNUID (in a RACF environment).

ICHERDCE    CLASS=LSNUID
            ID=nn
            MAXLNTH=39
            FIRST=ANY
            OTHER=ANY
            POSIT= (prevented when RACF unavailable,
                    auditing if you want it,
                    statistics if you want them,
                    generic profile checking on,
                    generic command processing on
                    global access checking off)
ICHRFRTB    CLASS=LSNUID
            ACTION=RACF

In RACF, once this resource is defined, it must also be activated via the command:

SETROPTS CLASSACT(LSNUID)

The NFS client libraries make authorization inquiries about the following profile names (all requests are for "read" permission):

LOCAL_USERID
Users who are permitted to this profile are authorized to use their mainframe userid (lowercased) as the UNIX username without specifying a UNIX password.

USER_name
Users who are permitted to this profile are authorized to use the string name (lowercased) as their UNIX username without specifying a UNIX password. For example, if a mainframe user is permitted to the profile USER_BILL , then he is allowed to assume the UNIX username of bill .

Pddd.ddd.ddd.ddd
This specifies the network address (dotted decimal) of a PCNFSD server which the user can access to obtain a UID and GID. Permissions against servers prevent users from setting up unauthorized versions of PCNFSD on a less trusted machine and then directing their login queries to it. For example, if mainframe user BILL is permitted to P149.133.175.68, he can use the server at that IP address when logging in. Leading zeros are not allowed in these names. That is, the previous profile could not have been for P149.133.175.068.

Sddd.ddd.ddd.ddd
This is similar to the above, but permits access to a sascuidd server.


Configuring a Default Login Server

In most cases, it is better for users to reach a default login server. Having a correct default reduces user effort and confusion. But most importantly, the correct default must be set if the NFS client library is to perform logins automatically.

You can control the login server in three ways. One way is to set the NFSLOGIN_SERVER environment variable in the user's PROFILE EXEC or TSO startup CLIST. Another way is to apply the default login server configuration zap that is supplied in the installation instructions. The best method is to accept the default name nfsloginhost and to configure your nameserver or /etc/hosts format file accordingly.


Chapter Contents

Previous

Next

Top of Page

Copyright © 2001 by SAS Institute Inc., Cary, NC, USA. All rights reserved.