Return-Path: linux-nfs-owner@vger.kernel.org Received: from mail-ie0-f172.google.com ([209.85.223.172]:51227 "EHLO mail-ie0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756832AbaDHQWz convert rfc822-to-8bit (ORCPT ); Tue, 8 Apr 2014 12:22:55 -0400 Received: by mail-ie0-f172.google.com with SMTP id as1so1172532iec.17 for ; Tue, 08 Apr 2014 09:22:55 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: v4.0 CB_COMPOUND authentication failures From: Trond Myklebust In-Reply-To: <20140408144652.GE3882@fieldses.org> Date: Tue, 8 Apr 2014 12:22:51 -0400 Cc: Layton Jeff , NFS , Adamson William Andros , Lever Charles Edward Message-Id: References: <20140408082140.340c1328@tlielax.poochiereds.net> <20140408123501.GA3532@fieldses.org> <20140408094903.33e42de2@tlielax.poochiereds.net> <20140408140333.GD3882@fieldses.org> <6CC79B2A-8AE2-4A36-BB57-380C2F9813C0@primarydata.com> <20140408144652.GE3882@fieldses.org> To: Dr Fields James Bruce Sender: linux-nfs-owner@vger.kernel.org List-ID: On Apr 8, 2014, at 10:46, Dr Fields James Bruce wrote: > On Tue, Apr 08, 2014 at 10:23:37AM -0400, Trond Myklebust wrote: >> >> On Apr 8, 2014, at 10:03, J. Bruce Fields wrote: >> >>> On Tue, Apr 08, 2014 at 09:49:03AM -0400, Jeff Layton wrote: >>>> On Tue, 8 Apr 2014 08:35:01 -0400 >>>> "J. Bruce Fields" wrote: >>>> >>>>> On Tue, Apr 08, 2014 at 08:21:40AM -0400, Jeff Layton wrote: >>>>>> I've recently been hunting down some problems with delegation handling >>>>>> and have run across a problem with the client authenticates CB_COMPOUND >>>>>> requests. I could use some advice on how best to fix it. >>>>>> >>>>>> Specifically, check_gss_callback_principal() tries to look up the >>>>>> callback client and then tries to compare the ticket in it against the >>>>>> clp->cl_hostname: >>>>>> >>>>>> /* Expect a GSS_C_NT_HOSTBASED_NAME like "nfs@serverhostname" */ >>>>>> >>>>>> if (memcmp(p, "nfs@", 4) != 0) >>>>>> return 0; >>>>>> p += 4; >>>>>> if (strcmp(p, clp->cl_hostname) != 0) >>>>>> return 0; >>>>>> return 1; >>>>>> >>>>>> The problem is that there is no guarantee that those hostnames will be >>>>>> the same. If, for instance, I mount "foo:/" and the SPN is >>>>>> "nfs/foo.bar.baz" that strcmp will return true, and the CB_COMPOUND >>>>>> request will get tossed out [1]. Ditto if I happen to mount a CNAME of the >>>>>> server. >>>>> >>>>> It sounds like a bug to me that the mount is succeeding without the name >>>>> matching. >>>>> >>>>> The security provided by krb5 is much weaker if we don't check that the >>>>> name provided on the commandline matches what the server authenticates >>>>> as. >>>>> >>>> >>>> The logic in gssd for this is pretty awful. >>>> >>>> It will basically trust DNS if there is no '.' in the hostname that was >>>> used at mount time. That'll make it take the address and >>>> reverse-resolve it. >>> >>> Argh, OK, I guess this is the compromise Simo made in "Avoid DNS reverse >>> resolution for server names (take 3)". >>> >>>> We could add yet another band-aid and make it so that DNS is never >>>> trusted. I'll note that for cifs, we took that route. You have to mount >>>> the canonical name of the server in order to use krb5. >>> >>> I wish we could do that, but I suppose it's too harsh to break >>> already-working fstabs. Maybe we could phase it in somehow. >>> >>>>>> Now that we try to use krb5 on the callback channel even when sec=sys >>>>>> is specified, this is very problematic. >>>>> >>>>> And similarly I think the attempt to opportunistically use krb5 for >>>>> state management should fail and fall back on auth_sys if the server's >>>>> name doesn't match. >>>>> >> >> This suggestion makes no sense to me at all. How does it help to fall back to using weak security when the strong security checks fail? > > It'd fix this particular problem. It weakens the state management security for no good reason. How is it not better just to rip out that hostname comparison in the back channel? > But, I don't know, I'm frankly confused about our security design for > the NFSv4 state. > > When we insist on krb5 (and checked the server name correctly), and > failed without it, then I feel like I understand what we're doing. Once > we start trying it and then falling back (as I understand happens for > the krb5 state in the auth_sys case) I get confused. Now you have me confused. I?m aware that we call nfs_create_rpc_client() with a krb5i argument and then fall back to auth_sys if the RPC layer says that we don?t have a running gss daemon or that we can?t load the rpcsec_gss_krb5 module. I?m not aware of us falling back if rpc.gssd is running and tells us that security negotiation failed; we should be returning a mount error in that case. >>>> Like Trond pointed out, the problem is that gssd doesn't give us that >>>> info currently. We could change it to do that of course, but that >>>> basically means revving the downcall. >>> >>> It might be easier to rev the upcall so that the kernel could ask gssd >>> to do strict checking? Since it's just a bunch of name=value pairs it >>> shouldn't be a huge pain to revise. >> >> So what would trigger the kernel to ask for strict checking? Do we add a mount option that says ?fail if the server doesn?t authenticate itself?? That would be hard to combine with security negotiation, since it only makes sense for RPCSEC_GSS authentication. > > I was thinking about only doing it in the state-establishment case. > (Since we won't know how to authenticate the callbacks in that case.) > > But that would screw up krb5 mounts, I guess, never mind. > > Using a fqdn implicitly requests strict checking so a mount option would > seem redundant. _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com