Well, I tend to agree with you that probably EXCHGID4_FLAG_BIND_PRINC_STATEID is the root-cause of this particular corner-case described by RFC. However I still feel that using the same NFS4 session (established by EXCHANGE_ID from RPCGSS) from an unprotected state is NOT something we want to allow. I understand that the guarantee of protection can happen only when NFS export allows only RPCGSS flavor (sec=krb5* on export definition and not 'sys/none'), so clients are not allowed to use AUTH_UNIX at all (in terms of security protection). Bottom line - I still can't find/reproduce some scenario where I can show this security issue due to missing spo_must_allow support: 1. NFS4 export is allowed only for sec=krb5i:krb5p (i.e. safe protection for clients' traffic). 2. Client1 makes NFS4.1 requests with gss_service_integrity (krb5i) to establish client+session and does some operation with a file (stateid is created). Client2 is able to monitor all this traffic (because the traffic is not encoded). 3. Client2 can send some NFS4 request with AUTH_UNIX (or with gss_service_none=krb5 request - leaving RPC header from a packet caught from client1 but replacing NFS4 body) to make a harm/additional information disclosure for client1 (offensive action): like close the stateid from the scope of the session by client1, write corrupted data to the same stateid, corrupt the session/client, etc. In this scenario AUTH_UNIX requests on step3 may be replied by WRONGSEC error from the server if client2 uses put filehandle, lookup or open with a name operation (only in this case server is allowed to use this error). Otherwise, all other operations cannot return WRONGSEC so AUTH_UNIX packet must be accepted and processed. But indeed - it's too hard to find some intrusive/offensive operation without putfh/lookup/open. Probably I need more time to try it and think a bit more... volodymyr. > On Mon, Nov 15, 2021 at 9:46 PM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Mon, Nov 15, 2021 at 09:35:51PM +0200, Volodymyr Khomenko wrote: > > > Does the spec require that? > > > > Unfortunately the spec is not explicit about this use-case. > > However we have a detailed rationale of the 'spo_must_allow' option there. > > It says that 'The client will be unable to send CLOSE without the > > user's credentials' if users GSS credentials are expired. > > Meaning that AUTH_UNIX credentials (with user UID/GID) is not a valid > > way to solve this issue - from my understanding: > > See the discussion of EXCHGID4_FLAG_BIND_PRINC_STATEID: > > https://datatracker.ietf.org/doc/html/rfc5661#page-502 > > When EXCHGID4_FLAG_BIND_PRINC_STATEID is set, the client > indicates that it wants the server to bind the stateid to the > principal. This means that when a principal creates a stateid, > it has to be the one to use the stateid. > > So that's what's forcing the use of GSS in this case. The OPEN that > created the used a certain GSS principal, so the CLOSE would normally > have to as well; spo_must_allow gives the client an out in this case. > > It's not meant to imply that GSS must be used for all operations > whenever state protection is used. > > --b. > > > > > > > rfc5661: > > > > > > The purpose of spo_must_allow is to allow clients to solve the > > following conundrum. Suppose the client ID is confirmed with > > EXCHGID4_FLAG_BIND_PRINC_STATEID, and it calls OPEN with the > > RPCSEC_GSS credentials of a normal user. Now suppose the user's > > credentials expire, and cannot be renewed (e.g., a Kerberos ticket > > granting ticket expires, and the user has logged off and will not be > > acquiring a new ticket granting ticket). The client will be unable > > to send CLOSE without the user's credentials, which is to say the > > client has to either leave the state on the server or re-send > > EXCHANGE_ID with a new verifier to clear all state, that is, unless > > the client includes CLOSE on the list of operations in spo_must_allow > > and the server agrees. > > > > volodymyr. > > > > On Mon, Nov 15, 2021 at 5:50 PM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > > > 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) > > > > > >
