SAS/C Cross-Platform Compiler and C++ Development System User's Guide, Release 6.50 |
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.
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.
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.
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.
Copyright © 1998 by SAS Institute Inc., Cary, NC, USA. All rights reserved.