Re: [RFC] protect against denial-of-service on a 4.0 mount

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 29, 2018 at 04:14:09PM -0400, Olga Kornievskaia wrote:
> On Tue, May 29, 2018 at 3:56 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
> > On Tue, May 22, 2018 at 03:36:12PM -0700, Chuck Lever wrote:
> >> > On May 22, 2018, at 3:11 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote:
> >> >> If an AUTH_UNIX client can tamper with a lease established
> >> >> by an AUTH_GSS client, that's a pretty serious server bug.
> >> >>
> >> >> Which server implementation is this?
> >> >
> >> > This is linux 4.16-rc1.
> >>
> >> Would it be easy for you confirm if two AUTH_GSS clients are
> >> appropriately protected from each other? It would be good to
> >> file a bug on bugzilla.linux-nfs.org to document the full
> >> extent of the badness.
> >
> > If you try a setclientid with a client name matching an
> > already-established client with state, then nfsd4_setclientid() should
> > be returning CLID_INUSE:
> 
> This is not what I see. I see that the 2nd SETCLIENTID succeed. Then
> the RENEW from the 1st client gets ERR_EXPIRED. 1st client does the
> SETCLIENTID/SETCLIENT_CONFIRM. Then when the 2nd client's RENEW is
> sent it gets ERR_EXPIRED and it sends SETCLIENTID.
> 
> >
> >         if (conf && client_has_state(conf)) {
> >                 ...
> >                 status = nfserr_clid_inuse;
> >                 ...
> >                 if (!same_creds(&conf->cl_cred, &rqstp-.rq_cred)) {
> >                         ...
> >                         goto out;
> >                 }
> >         }
> >
> > So if you're seeing SETCLIENTID succeed then maybe same_creds() or
> > client_has_state() is failing.
> >
> > Maybe client_has_state()?--that will fail (and allow the setclientid) if
> > the v4.0 client doesn't currently have any opens or delegations.
> >
> > I think that's correct:
> >
> >         https://tools.ietf.org/html/rfc7530#section-9.1.2
> >
> >         when the server gets a SETCLIENTID for a client ID that
> >         currently has no state, or it has state but the lease has
> >         expired, rather than returning NFS4ERR_CLID_INUSE, the server
> >         MUST allow the SETCLIENTID and confirm the new client ID if
> >         followed by the appropriate SETCLIENTID_CONFIRM.
> 
> At the time the "competing" SETCLIENTID arrives the other client
> definitely does not have an expired lease.

Right, but does it have opens or delegations?  That's what I took as the
definition of "state" for the code above.  Could be wrong, I don't know.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux