Return-Path: Received: from userp2130.oracle.com ([156.151.31.86]:48658 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966362AbeE2UD5 (ORCPT ); Tue, 29 May 2018 16:03:57 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: [RFC] protect against denial-of-service on a 4.0 mount From: Chuck Lever In-Reply-To: <20180529195628.GB16759@fieldses.org> Date: Tue, 29 May 2018 16:03:46 -0400 Cc: Olga Kornievskaia , Linux NFS Mailing List Message-Id: <1768D584-0BF8-4155-92A7-52F9CC44544C@oracle.com> 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> To: Bruce Fields Sender: linux-nfs-owner@vger.kernel.org List-ID: > 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? -- Chuck Lever