Return-Path: Received: from fieldses.org ([173.255.197.46]:51672 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966808AbeE2UfV (ORCPT ); Tue, 29 May 2018 16:35:21 -0400 Date: Tue, 29 May 2018 16:35:21 -0400 From: Bruce Fields To: Chuck Lever Cc: Olga Kornievskaia , Linux NFS Mailing List Subject: Re: [RFC] protect against denial-of-service on a 4.0 mount Message-ID: <20180529203521.GC16759@fieldses.org> References: <537AAFBD-62BA-4F0B-9B2E-D27500A1205B@oracle.com> <58E2765B-6238-479D-968A-0FE2F5F01928@oracle.com> <20180529195628.GB16759@fieldses.org> <1768D584-0BF8-4155-92A7-52F9CC44544C@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1768D584-0BF8-4155-92A7-52F9CC44544C@oracle.com> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Tue, May 29, 2018 at 04:03:46PM -0400, Chuck Lever wrote: > > > > On May 29, 2018, at 3:56 PM, bfields@fieldses.org 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: > > > > 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. > > > > That's left out of the later breakdown of cases in 16.33.5, > > unfortunately. > > That prevents certain denial of service attacks. A client can't > lose state because of this. However, it can do a SETCLIENTID > then later be prevented from doing its first OPEN? Yeah, I think so. Looking back at changelogs, the only motivation was to avoid annoyances in testing, where the same client might rapidly mount several different security flavors. The client may have been wrong not to change its identifier in that case, I don't know. All a bit academic for 4.1, where the client pretty much always has a session. --b.