Return-Path: Received: from fieldses.org ([173.255.197.46]:51582 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966175AbeE2T42 (ORCPT ); Tue, 29 May 2018 15:56:28 -0400 Date: Tue, 29 May 2018 15:56:28 -0400 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: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <58E2765B-6238-479D-968A-0FE2F5F01928@oracle.com> From: bfields@fieldses.org (J. Bruce Fields) Sender: linux-nfs-owner@vger.kernel.org List-ID: 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. --b.