On Apr 8, 2014, at 10:03, J. Bruce Fields <bfields@xxxxxxxxxxxx> 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" <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. >>> >> >> 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? >> 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 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. >>> >> >> The server uses CB_NULL requests to probe the callback port, and those >> aren't affected by this problem. Worse, since CB_NULL requests don't >> even contain the callback_ident, we can't even use them to hook up the >> nfs_client with the SPN used in them. > > Ah, got it. > > The server should still stop delegations as soon as a CB_RECALL times > out, though, so at least the problem should clear up after that? > > --b. > -- > 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 _________________________________ 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
