Return-Path: Received: from mail-ua0-f174.google.com ([209.85.217.174]:41429 "EHLO mail-ua0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966179AbeE2UOL (ORCPT ); Tue, 29 May 2018 16:14:11 -0400 Received: by mail-ua0-f174.google.com with SMTP id a3-v6so10887919uad.8 for ; Tue, 29 May 2018 13:14:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180529195628.GB16759@fieldses.org> References: <594BD2F7-35FC-4E26-81D7-404194B7005A@oracle.com> <537AAFBD-62BA-4F0B-9B2E-D27500A1205B@oracle.com> <58E2765B-6238-479D-968A-0FE2F5F01928@oracle.com> <20180529195628.GB16759@fieldses.org> From: Olga Kornievskaia Date: Tue, 29 May 2018 16:14:09 -0400 Message-ID: Subject: Re: [RFC] protect against denial-of-service on a 4.0 mount To: "J. Bruce Fields" Cc: Chuck Lever , Linux NFS Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-nfs-owner@vger.kernel.org List-ID: On Tue, May 29, 2018 at 3:56 PM, J. Bruce Fields wrote: > On Tue, May 22, 2018 at 03:36:12PM -0700, Chuck Lever wrote: >> > On May 22, 2018, at 3:11 PM, Olga Kornievskaia 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. > > That's left out of the later breakdown of cases in 16.33.5, > unfortunately. > > --b.