Re: NFS4 RPCGSS state protection (SP4_MACH_CRED) is not handled

["J. Bruce Fields" <bfields@fieldses.org>]

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)