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. 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. 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? Or should we simply use the "sec=" setting in this case and call it a day? -- 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
