On Tue, 08 Apr 2014 13:25:04 -0400 Simo Sorce <simo@xxxxxxxxxx> wrote: > On Tue, 2014-04-08 at 11:13 -0400, Dr Fields James Bruce wrote: > > On Tue, Apr 08, 2014 at 11:04:20AM -0400, Jeff Layton wrote: > > > On Tue, 8 Apr 2014 10:46:52 -0400 > > > Dr Fields James Bruce <bfields@xxxxxxxxxxxx> wrote: > > > > > > > On Tue, Apr 08, 2014 at 10:23:37AM -0400, Trond Myklebust wrote: > > > > > > > > > > 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? > > > > > > > > It'd fix this particular problem. > > > > > > > > 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. > > > > > > > > > >> 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. > > > > > > > > > > So I guess we have two options to fix this: > > > > > > 1) Change gssd to require the canonical fqdn and not rely on name > > > resolution. Unfortunately, I think the MIT krb5 libs will still > > > canonicalize the hostnames by default, so this might not actually fix > > > anything. See: > > > > > > http://web.mit.edu/kerberos/krb5-devel/doc/admin/princ_dns.html > > > > > > ...or... > > > > > > 2) Loosen or somehow fix the check in check_gss_callback_principal(). > > > One possibility might be to do a dns_resolver upcall for the host > > > portion of the SPN, and then compare the address with the server's > > > address. Ugly, but since we already trust DNS implicitly I guess it's > > > no less secure... > > > > I thought Kerberos wasn't supposed to require trust in DNS. So I feel > > confused. Cc'ing Simo in hopes he can set us all straight. > > RFC4120 indeed warns against relying on DNS. > Here[1] is my old writeup about why it shouldn't be done, at least until > DNSSEC gets deployed, then things may change. > > Simo. > > [1] https://ssimo.org/blog/id_015.html There's the additional problem that the MIT krb5 libs will silently canonicalize the name for you as well. Do you know of any way for a program to request that that *not* be done? -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
