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).
>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)
Attachment:
test_krb_protection_rpcgss_then_authsys.pcapng
Description: application/pcapng
