NFS4 RPCGSS state protection (SP4_MACH_CRED) is not handled

NFS4 RPCGSS state protection (SP4_MACH_CRED) is not handled

[Volodymyr Khomenko]

[-- Attachment #1: Type: text/plain, Size: 3038 bytes --]

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 #2: test_krb_protection_rpcgss_then_authsys.pcapng --]
[-- Type: application/x-pcapng, Size: 17780 bytes --]

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

[J. Bruce Fields]

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)

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

[Volodymyr Khomenko]

> 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:


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@fieldses.org> 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)
>
>

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

[J. Bruce Fields]

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@fieldses.org> 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)
> >
> >

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

[Volodymyr Khomenko]

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@fieldses.org> 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@fieldses.org> 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)
> > >
> > >

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

[J. Bruce Fields]

On Tue, Nov 16, 2021 at 10:46:27AM +0200, Volodymyr Khomenko wrote:
> 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...

You may be able to get the slot sequence numbers out of sync,
effectively a DoS--though perhaps that's not any worse than you could
already do at the TCP level.

I don't know, maybe there's something here.

If so, this would be discussion for the ietf working group list, I think
(nfsv4@ietf.org).  And if we were tighten requirements, we'd also need
to check that we aren't breaking interoperability with existing clients.

--b.

> 
> volodymyr.
> 
> > On Mon, Nov 15, 2021 at 9:46 PM J. Bruce Fields <bfields@fieldses.org> 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@fieldses.org> 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)
> > > >
> > > >