On Tue, Apr 08, 2014 at 08:42:10AM -0400, Trond Myklebust wrote: > > On Apr 8, 2014, at 8:35, J. Bruce Fields <bfields@xxxxxxxxxxxx> 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. > > Where would the client find that information? I don’t think that rpc.gssd passes that information down to us. gssd should get the server name passed on the commandline from the info file or the upcall, if I remember right, and then it's up to gssd to match names. I thought gssd was already doing that, but I guess not. So maybe I'm confused about how this all works. --b. > > >> 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. > > > >> I think that the ideal thing would be to stash the SPN that we use to > >> do the SETCLIENTID call and use that in the comparison above. > >> Unfortunately, the rpc_cred doesn't really seem to carry this info and > >> I don't see where we get enough information in the rpc.gssd downcall to > >> figure out what that SPN should be. > >> > >> Anyone have thoughts or should we just remove the above check until we > >> come up with a better way to do this? > >> > >> [1]: there's another bug that can cause the client to send a bogus > >> reply instead of dropping the request as intended, but that's > >> relatively simple to fix. > > > > So I believe the matching really is a requirement and that it would be > > wrong to weaken it. > > > > It sounds like there's also a server bug here if it's giving out > > delegations to a client that isn't responding to callbacks. > > > > --b. > > _________________________________ > Trond Myklebust > Linux NFS client maintainer, PrimaryData > trond.myklebust@xxxxxxxxxxxxxxx > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
