| Installing and Administering the NFS Client |
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 for whom the access was
not previously possible.
All security on NFS servers is administered 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 ensures that all participating
machines share the same UID and GID assignments. OS/390 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
environments, 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 access 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 that contain 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 environments.
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 associate mainframe users with UNIX usernames.
For a user whose mainframe login ID is the same as the UNIX username, a single
profile can be used. There is considerable flexibility in this arrangement.
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 is preferred 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 that 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 supply 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 enable 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 that are
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
.
-
P
ddd.ddd.ddd.ddd
-
This specifies the network address (dotted
decimal) of a PCNFSD server that the user can access to obtain a UID and GID.
Requiring permission for access to servers prevents 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.
-
S
ddd.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
important, 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 © 2001
by SAS Institute Inc., Cary, NC, USA. All rights reserved.
