On Mon, Nov 15, 2021 at 04:37:10PM +0200, Volodymyr Khomenko wrote: > Hello linux-nfs, > > We have the following NFS4 test (implemented using pynfs framework, > not regular NFS4 client): > 1. NFS4 client wants to use RPCGSS (Kerberos) and starts NFS4 traffic > with NFS4 NULL request to establish RPCGSS context of a machine > account. > 2. During EXCHANGE_ID operation (client establishment), client asks > for SP4_MACH_CRED state protection with > spo_must_enforce/spo_must_allow fields set to values that are usually > used by NFS4 clients (as defined by rfc5661). > 3. CREATE_SESSION and RECLAIM_COMPLETE operations (required for NFS4 > session) are also done with RPCGSS and sevice=svc_gss_integrity - as > required by spo_must_enforce option of state protection. If > CREATE_SESSION is done with the wrong protection type, error is > returned to the client (as expected). > 4. However, when operations that are neither in spo_must_enforce nor > in spo_must_allow list are done with the wrong protection type > (flavor=AUTH_UNIX), NFS server accepts the request and replies by > unexpected result (NFS4_OK) instead of error. In our test we used > SEQUENCE + PUTROOTFH + GETFH compound operation with RPC credentials > using flavor=AUTH_UNIX instead of RPCGSS. > > As for me, it looks like a security issue: client asked for state > protection but man-in-the-middle can make unprotected requests for > state-protected client and session. Expected behaviour from my side > is: > if NFS4 operation (like GETFH) from state-protected client is neither > in spo_must_enforce nor in spo_must_allow lists of SP4_MACH_CRED, the > server must fail the request if used credentials has a different > flavor than RPCGSS (neither user GSS context nor machine account GSS > context). There are two separate questions here: - Does the spec require that? - Should the server do it anyway? I think the answer to the first question is "no". If the requirement is in the language you've quoted below, I'm not seeing it. As far as I can tell, GSS is required only for operations in spo_must_enforce. I haven't thought about #2 very much. If an operation's not in spo_must_support, I think the server just checks the sec= option on the export. If we were to require something more than that, I guess that would affect the values returned from SECINFO and friends too. I think the spec's meant to allow the client to use a combination of krb5 and sys, and that current server behavior is correct, though it's always possible there's some case I haven't thought through. --b. > > >From rfc5661 (18.35.3. DESCRIPTION): > > o For SP4_MACH_CRED or SP4_SSV state protection: > > * The list of operations (spo_must_enforce) that MUST use the > specified state protection. This list comes from the results > of EXCHANGE_ID. > > * The list of operations (spo_must_allow) that MAY use the > specified state protection. This list comes from the results > of EXCHANGE_ID. > > ... > > o SP4_MACH_CRED. If spa_how is SP4_MACH_CRED, then the client MUST > send the EXCHANGE_ID request with RPCSEC_GSS as the security > flavor, and with a service of RPC_GSS_SVC_INTEGRITY or > RPC_GSS_SVC_PRIVACY. If SP4_MACH_CRED is specified, then the > client wants to use an RPCSEC_GSS-based machine credential to > protect its state. The server MUST note the principal the > EXCHANGE_ID operation was sent with, and the GSS mechanism used. > These notes collectively comprise the machine credential. > > Please see pcap file of the traffic (attached) - EXCHANGE_ID with > SP4_MACH_CRED is the packet #41 and problematic PUTROOTFH + GETFH > request is the packet #49. > > User linux NFS4 server was: > [centos@rnd-nfs4-srv01 ~]$ uname -a > Linux rnd-nfs4-srv01 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 > 23:49:17 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux > > [centos@rnd-nfs4-srv01 ~]$ cat /etc/redhat-release > CentOS Linux release 7.7.1908 (Core)
