A fix is available
APAR status
Closed as new function.
Error description
z/OS NFS Server supports AT-TLS for z/OS Container Extensions.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: * * All users of z/OS NFS server who wish to * * exploit AT-TLS (Application Transparent - * * Transport Layer Security) with TTLS * * "ClientAuthType" of "SAFCheck" used for * * authentication. * **************************************************************** * PROBLEM DESCRIPTION: * * Prior to OA62357 the z/OS NFS Server * * can be configured as an AT-TLS "Basic" * * application where the network data is * * encrypted. * * * * The Transport Provider (z/OS * * Communications Server) decrypts the * * inbound network data and the z/OS NFS * * server receives the clear-text * * (non-encrypted) request (RPC CALL MSG). * * When the z/OS NFS server sends the * * clear-text (non-encrypted) reply (RPC * * REPLY MSG) the z/OS Communications * * Server encrypts the outbound network * * data. * * Both Client and Server must be properly * * configured to participate in the * * Transport Layer Security (TLS). * * * * With OA62357 the z/OS NFS Server * * becomes an AT-TLS "Aware" application. * * In this mode, when TLS client * * authentication is used, AT-TLS * * authenticates the client certificate * * sent during the TLS handshake and then * * it provides the z/OS NFS Server with * * the z/OS user ID associated with that * * certificate. The z/OS NFS Server uses * * that z/OS user ID to implicitly perform * * the equivalent MVSLOGIN (implicit * * MVSLOGIN). * **************************************************************** * RECOMMENDATION: * * Remote users who explicitly use the MVSLOGIN * * utility to authenticate themselves with z/OS * * to access z/OS resources using the NFS * * protocol can exploit this new feature of * * encrypted network data and implicit * * MVSLOGIN. * * * * Exploiters should be aware of the following * * requirements and behaviors: * * * * a) The z/OS AT-TLS components such as * * syslogd, PAGENT (Policy Agent), RACF * * digital certificate and keyring, etc.. * * and the client-side TLS proxy (such as * * HAPROXY) are properly configured. * * * * b) The AT-TLS policy must contain a * * "TTLSRule" and associated statements to * * protect the z/OS NFS Server. That rule * * must contain the following parameters * * in addition to the other settings you * * select to apply the appropriate level of * * protection: * * * * TTLSRule <NFSS_Rule> * * { * * Jobname <NFSS_Start_Procedure> * * Direction Inbound * * LocalPortRange 2043:2049 # must match * * # /etc/services * * ... * * TTLSEnvironmentAction * * { * * HandshakeRole ServerWithClientAuth * * TTLSEnvironmentAdvancedParms * * { * * ApplicationControlled Off * * ClientAuthType SAFCheck * * TLSv1.2 On * * ... * * } * * ... * * } * * ... * * } * * * * The above AT-TLS policy rule <NFSS_Rule> * * protects the z/OS NFS server associated * * with the <NFSS_Start_Procedure>. * * * * c) The z/OS NFS Server is configured with * * "nodelegation" and "security(safexp)" * * (or "security(saf)") to allow remote * * users currently using MVSLOGIN utility to * * authenticate themselves with z/OS. * * * * d) Client uses NFSv4.0 protocol (vers=4) * * with RPC AUTH_SYS authentication * * (sec=sys) and TCP transport protocol * * (proto=tcp) to access the z/OS NFS Server * * with the z/OS NFS server "mvsmnt" * * attribute (optional for z/OS, AIX, * * Solaris NFS client since these NFS * * clients support NFSv4 volatile file * * handle) and the client-side "hard" * * mount option. * * * * -> Client using RPCSEC_GSS with Kerberos * * (sec=krb5*) already enjoys the implicit * * LOGIN provided by Kerberos authentication * * and the encrypted data transmission * * (sec=krb5p), so the new feature offers * * no benefit. * * * * -> The TLS (Transport Layer Security) does * * NOT support the UDP transport protocol * * (proto=udp), it only supports the TCP * * transport protocol. * * * * ## When the client system connects (implying * * proto=tcp) to the z/OS NFS server port * * 2049 (where both systems meet ALL the * * previous requirements in #a, #b, #c, #d) * * the TLS handshake occurs in the Transport * * layer (implying Transport Provider in * * z/OS Communications Server and the * * client-side TLS proxy). * * * * -> If the TLS handshake fails the TCP * * connection is reset. * * * * -> If the TLS handshake succeeds then the * * z/OS NFS server retrieves the exchanged * * client digital certificate and creates * * the ACEE (ACcessor Environment Element) * * of the z/OS user associated with the * * certificate. * * * * -> The z/OS NFS Server issues this typical * * message * * << * * GFSA551I (MVSNFS) z/OS NFS server with * * "safexp" receives TLS connection from * * ::ffff:10.0.0.10 on port 2049 with * * HndShkRole=ServerWithClientAuth( * * SAFcheck:ZOSUSERX). * * >> * * where * * *) "safexp" is the highest aggregated * * option of the z/OS NFS "security" * * attribute (see #c above), * * *) "ServerWithClientAuth(SAFCheck,...)" * * reflects the configured TTLS statement * * (see #b above), * * *) "ZOSUSERX" is the z/OS user associated * * with the exchanged certificate. * * * * ## All subsequent RPCs with various users * * AUTH_SYS authentication on the * * established TCP and TLS connection * * inherit the ACEE of the z/OS user * * associated with the exchanged * * certificate (the "ZOSUSERX" in the * * previous example). * * Thus, the implicit MVSLOGIN is achieved. * * * * e) Client readily accepts NFSv4 user name * * and group name mapping such as its * * users are mapped to "zosUserX@domain" * * and "zosGrpX@domain" where * * *) "zosUserX" is the z/OS user * * ("ZOSUSERX" in the above GFSA551I * * example message) associated * * with the certificate, * * *) "zosGrpX" is the z/OS primary group * * name of the z/OS user associated with * * the certificate, * * *) "domain" is NFSv4 domain, please see * * o) z/OS NFS "nfsv4domain" attribute, * * o) "NFS v4 Protocol name mapping" in * * the z/OS NFS publication. * * * * -> In other words, prior to OA62357 * * * * client "user2" issues * * > mvslogin mvsnfs_host ZOSUSER2 * * and creates a file on z/OS, the NFSv4 * * file owner is "zosuser2@domain"; while * * * * client "user3" issues * * > mvslogin mvsnfs_host ZOSUSER3 * * and creates a file on z/OS, the NFSv4 * * file owner is "zosuser3@domain". * * * * -> With OA62357, client "user2" or "user3" * * (or other users) do not issue MVSLOGIN * * (because of the implicit MVSLOGIN) and * * create files on z/OS, the NFSv4 file * * owner is "zosUserX@domain" where * * "zosUserX" is the z/OS user associated * * with the certificate. * * * * -> In other words, the above implicit * * MVSLOGIN is equivalent to these actions * * {{ * * client "user2" issuing * * > mvslogin mvsnfs_host ZOSUSERX * * and client "user3" issuing * * > mvslogin mvsnfs_host ZOSUSERX * * prior to accessing the z/OS NFS server. * * }} * * Please note that both client "user2" and * * "user3" login to the same z/OS user * * "ZOSUSERX" associated with the * * certificate. * * Hence files or objects created by "user2" * * or "user3" have the same NFSv4 owner name * * of "zosUserX@domain". * * * * f) Client must be able to map the NFSv4 * * owner name of "zosUserX@domain" to its * * local user such that the "ls" (listdir) * * command can show the proper owner name * * and group name. * * * * g) It is best to have a dedicated NFS server * * such as an Application-DVIPA NFS server * * in INET to serve the NFS client system * * (that exploits the above implicit * * MVSLOGIN feature) to minimize the * * impact to the existing NFS workload. * **************************************************************** When the z/OS NFS server is configured with the "security(saf|safexp)" attribute, it exploits its AT-TLS policy (protecting the NFS server) "HandShakeRole" of "ServerWithClientAuth" and "ClientAuthType" of "SAFCheck" to perform the implicit MVSLOGIN by 1) calling ioctl(SIOCTTLSCTL) to query the TLS connection status and optionally retrieve the digital certificate from the successful TLS handshake between Client and Server on TCP connections to Server port 2049 (NFS port). 2) calling initACEE/IRRSIA00 to create the ACEE (ACcessor Environment Element) for the z/OS user associated with the client digital certificate. 3) associating the remote user AUTH_UNIX RPC Authentication with the above ACEE (thus ALL remote users from the "SAFCheck" client system associated with the z/OS user mapped by the client digital certificate). Regardless of the z/OS NFS "security(none|exports|saf|safexp)" attribute, z/OS NFS server issues GFSA551I message if it detects a TLS connection from a client (see #1 above).
Problem conclusion
Temporary fix
Comments
APAR Information
APAR number
OA62357
Reported component name
NETWORK FILE SY
Reported component ID
5695DF121
Reported release
24N
Status
CLOSED UR1
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2021-10-26
Closed date
2022-07-29
Last modified date
2024-01-19
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UJ08961 UJ08962
Modules/Macros
GFSAPXDR GFSASCLO GFSAXHOS GFSAMMTP GFSASCSE GFSAXCRE GFSAXMAI GFSAZMAI GFSAXFHD GFSANTIM GFSANMAI GFSACFSM GFSAFNPA GFSATCPR GFSATCPM GFSANEXP GFSASACC GFSASCOM GFSAMCMN GFSAMSG GFSACERT GFSAPHFS GFSACERR GFSAXLOC GFSAZCOM GFSANFSD GFSAXMSC GFSAZMSC GFSAXFB GFSAPLDS GFSAMSEN
| SC23688340 | SC23688350 |
Fix information
Fixed component name
NETWORK FILE SY
Fixed component ID
5695DF121
Applicable component levels
Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.
[{"Business Unit":{"code":"BU011","label":"Systems - zSystems software"},"Product":{"code":"SG19M"},"Platform":[{"code":"PF054","label":"z Systems"}],"Version":"24N"}]
Document Information
Modified date:
19 January 2024