| 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 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 © 2001
by SAS Institute Inc., Cary, NC, USA. All rights reserved.
