Re: Kernel NFS client and Kerberos delegation

[Language Lawyer <language.lawyer@gmail.com>]

On 09/10/18 17:34, Benjamin Coddington wrote:
> On 9 Oct 2018, at 9:44, Language Lawyer wrote: 
>> On 09/10/18 16:11, Benjamin Coddington wrote:
>>> On 8 Oct 2018, at 15:46, Language Lawyer wrote:
>>>
>>>> Hi,
>>>>
>>>> AFAIU kernel NFS client keeps ID -> Name mapping in the "id_resolver"
>>>> keyring.  Do I understand it correctly that with this hard mapping it is
>>>> not possible for a service to access a kerberized NFS storage on behalf of
>>>> some user using user's delegated (for example, with S4U2Self+S4U2Proxy)
>>>> credentials?
>>>
>>> The id_resolver keyring exists to translate kerberos principles to UID and
>>> the reverse, but it doesn't really play in the mechanisms that you're
>>> interested in.
>>>
>>> I assume you want a particular process, like httpd, to have the kernel chose
>>> which kerberos principle and thus which GSS context to use when sending RPC
>>> to the NFS server.
>>>
>>> The NFS client will choose the appropriate GSS context based on the fsuid of
>>> the calling process, and then as long as the gssd daemon can find an
>>> appropriate kerberos cache and establish a context everything will work
>>> fine.  So, as long as your service changes its fsuid (like smbd does),
>>> everything generally works.
>>
>> Yes, currently one has to grant CAP_SETUID capability to a service and
>> setup a way to obtain appropriate ticket, for example, by giving gssproxy
>> permission to impersonate users, instead of just granting a service
>> permission to impersonate users.
>>
>>> If you want a process that doesn't change its fsuid to use a different GSS
>>> context, you have to find a way to communicate which context, or credential
>>> you want the kernel to choose.
>> Are there plans to support this in the kernel NFS client?
> 
> No plans that I know of.  I have been involved in projects doing this in the
> past, but the implementation details were so specific to the use case that
> they didn't make sense to mainline.
> 
> The linux keyrings are very useful here because the userspace process can
> "tack on" extra information to communicate to the kernel which context to
> use, or even provide the context itself

That's why I've mentioned "id_resolver" keyring.
My naïve idea was to provide ID -> Name mapping in the session keyring,
which is replaceable by keyctl_join_session_keyring, to override "id_resolver"
mapping.
Of course, such a naïve implementation would be very unsecure.