Protecting the file system on z/OS with the NFS V4 protocol

The NFS version 4 protocol improves on the NFS version 2 and 3 protocols with stronger authentication and network transmission protection for NFS data. The NFS V4 protections include encryption algorithms for data privacy, multiple protections per file, and the means to negotiate security as NFS clients explore the file system. The NFS V4 protocol provides these protections through the required RPCSEC_GSS security authentication flavor and the SECINFO operation.

The z/OS NFS server enforces these protections, for client RPC requests that use RPCSEC_GSS, through the site attributes mvssec, hfssec, and pubsec. These attributes provide the Kerberos V5 Security Mechanism (RFC1964) subset of the V4 protocol, at the file-system level. The z/OS NFS server also continues to support NFS V2 and V3, as well as V4 protocol requests with the protections provided by the security site attribute, as described in Protecting the file system on z/OS with the Security site attribute.

The export data set also contains a security keyword, sec, that specifies the Kerberos authentication level that clients must have to access individual files and data sets on the z/OS NFS server. That is, specific export entries can be further constrained with different authentication flavors by using this security keyword. For example, an important export entry can be protected with krb5p level set by the security keyword, while other exported entries in the file system can be accessed by all authentication levels which are specified by the mvssec, hfssec and pubsec site attributes. The authentication flavors specified by the sec keyword in the export entries should be a subset of the authentication flavors of site attributes mvssec, hfssec and pubsec. In other words, an authentication level is effective only if it is specified by the site attribute logically AND’ed with the security keyword. For this reason, if the sec keyword is not specified, meaning all flavors are on, the authentication level is defaulted to the site attribute mvssec, hfssec and pubsec. For more information on the export security sec keyword, see Exports data set.

The mvssec, hfssec, and pubsec attributes let you specify the default network security flavors, and order, that can be used by requests accessing MVS, z/OS UNIX, and public file systems, respectively. These attributes only apply when the RPCSEC_GSS security mechanism is being used for communicating with the NFS client. These site attributes apply to all NFS versions. If you protect a data set with any one of these transmission attributes, NFS V2/V3 requests will get responses of AUTH TOOWEAK unless 'sys' is listed as a valid authentication flavor. NFS V4 requests that do not comply with these protections will get WRONG SEC. For more information on these site attributes, see Site attributes syntax.

Note: Since z/OS NFS only supports RPCSEC_GSS security for NFS version 4, if one of the site attributes is set to require RPCSEC_GSS, then clients using NFS versions 2 and 3, which only support AUTH_SYS security, cannot access those file systems. On the other hand, if the attribute is specified at a mount point, then only that mount point will be affected.

To use the NFS V4 RPCSEC_GSS security flavors, the following changes to the security infrastructure are required:

Kerberos services must be activated on the z/OS system where the NFS server is running. This activation includes the definition of Realms, Inter-Realm relationships, and the Kerberos Principal for the z/OS NFS server. For details on these definitions, see the z/OS Integrated Security Services Network Authentication Service Administration.
The Kerberos principals on NFS clients need to be defined to RACF and assigned a RACF identity. In addition, for Linux clients a principal nfs/hostname.domain should be defined to RACF. This is because Linux Clients use this principal for mounts and some state operations. For further details on defining principals, see z/OS Security Server RACF Security Administrator's Guide.
When acquiring Kerberos tickets, NFS clients must use MD5 Checksum with DES encryption.
No UNIX style user ID checking will be performed. Clients will always be validated to check for authorization based on their GSS credentials.
The z/OS NFS server must have READ access to the IRR.RUSERMAP resource in the FACILITY class.

Note: For more information on setting up the z/OS NFS server with RPCSEC_GSS security, see Configuring a secure z/OS NFS server.

The z/OS NFS client always uses the mvsnfsc kerberos principal during mount operation for a secure mount (krb5, krb5i or krb5p) regardless of the user's current principal identity.

For accesses to an already established secure (krb5, krb5i, krb5p) mount point, the NFS client uses the kerberos principal that was used by the user to obtain the kerberos ticket via the kinit command. This principal is used to establish security contexts with the server and the NFS data is exchanged on these contexts.

The effect of a principal switch in the same user session (where a user does a kinit with a different Kerberos principal) may not be reflected immediately in the client's communications on established secure mount points with the NFS server (not until the contexts created using the prior principal have expired).