Kernel NFS client and Kerberos delegation

Kernel NFS client and Kerberos delegation

[Language Lawyer]

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?

Re: Kernel NFS client and Kerberos delegation

[Benjamin Coddington]

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.

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.

Ben

Re: Kernel NFS client and Kerberos delegation

[Language Lawyer]

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?

Re: Kernel NFS client and Kerberos delegation

[Benjamin Coddington]

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, and it is possible implement 
the
rpc_authops to change how the NFS client handles credentials.

Ben

Re: Kernel NFS client and Kerberos delegation

[Language Lawyer]

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.