Re: [PATCH] Adding the nfs4_use_min_auth module parameter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Nov 8, 2013, at 9:58 AM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:

> 
> 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.

The fly in this ointment is allowing clients with no keytab to mount with sec=krb5.

We can use ENOKEY to allow lease management with AUTH_SYS but data access using Kerberos and a user's credential.

Otherwise, a user has to login as root, kinit as themselves, and then mount.  That makes automounter configurations a little dodgy.


--
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




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux