On Nov 8, 2013, at 8:14 AM, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Fri, Nov 08, 2013 at 07:54:19AM -0800, Chuck Lever wrote: >> >> On Nov 8, 2013, at 7:04 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> >> wrote: >> >>> On Fri, Nov 08, 2013 at 08:22:02AM -0500, Jeff Layton wrote: >>>> On Fri, 08 Nov 2013 07:41:32 -0500 Steve Dickson >>>> <SteveD@xxxxxxxxxx> wrote: >>>>> No. I think the concern here, at least my concern, is the lack of >>>>> management. We are forcing admins to use krb5i in lease >>>>> management when its not necessary and there is no way to turn it >>>>> off. >>>>> >>>> >>>> I don't think that's really the case. The idea was to have the >>>> client attempt to use krb5i if it's available, and then to fall >>>> back to AUTH_SYS if it isn't. This would be *absolutely* no big >>>> deal if the GSSAPI upcall succeeded or failed immediately instead >>>> of requiring this timeout when the daemon isn't running. >>> >>> I'm also still a little confused about the security model. We >>> discussed it before but I can't remember if it was really resolved. >>> >>> It makes sense to me as long as we insist on krb5i whenever we find >>> a keytab. >>> >>> But my understanding was that with the current implementation it's >>> possible we could find a keytab, attempt the krb5i connection, and >>> *then* fallback silently on auth_sys if krb5i fails. Is that right? >>> >>> In that case I don't see the point of the krb5i any more: any >>> attacker that can spoof rpc replies can force the fallback to >>> auth_sys. >> >> The point is to use a consistent security flavor for lease management >> to avoid NFS4ERR_CLID_INUSE. This really isn't about thwarting a MiTM >> attack on lease management. > > OK, but then you still do want to ensure you thwart that attack in the > case krb5 is explicitly asked for. > > So for example does a krb5 mount fail if a previous non-krb5 mount fell > back on auth_sys for clientid establishment? > >> The fallback mechanism can be fixed, somewhat. I've got a patch to >> have gssd return ENOKEY if it can't find a machine credential. Then >> the kernel will use AUTH_SYS. > > To get that right you'd then need to fail on errors *other* than ENOKEY. > Since old gssd doesn't return ENOKEY that would mean failing all > auth_sys mounts on kernel upgrade, wouldn't it? > >> The issue though is what to do in the other cases. Can gssd >> distinguish between the case where the server has no Kerberos >> principal, and the case where gssd simply failed to establish a GSS >> context? > > I don't know. I suppose the client should get some kind of > no-such-principal error and use that. > >> Or should we simply use the "sec=" setting in this case and >> call it a day? > > I think falling back works as long as we still are strict in the case > the mount explicitly requests some security and don't just use > whatever's already established in that case. Agreed. That is what we want to strive for. So: use the fallback mechanism only if Kerberos was _not_ specified via the mount options, I think? > And if we do that then I don't think the ENOKEY/no-such-principal cases > are worth sorting out. > > OK, sorry for the noise. > > --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 -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
