Hi Steve,

GSSAPI and krb5 as implemented in system krb5 libraries exists from longer than Samba has implemented those capabilities, I do not think it make sense to reason along those lines.

GSS-Proxy has been built with a protocol to talk from the kernel that resolved a number of issues for knfsd (eg big packet sizes when a MS- PAC is present).

And Samba uses internally exactly the same krb5 mechanism as it defers to the kerberos libraries as well.

Additionally GSS-Proxy can be very easily extended to also do NTLMSSP using the same interface as I have built the gssntlmssp long ago from the MS spec, and is probably the most correct NTLMSSP implementation you can find around.

Gssntlmssp also has a Winbind backend so you get automaticaly access to whatever cached credentials Winbindd has for users as a bonus (although the integration can be improved there), yet you *can* use it w/o Winbindd just fine providing a credential file (smbpasswd format compatible).

GSS-Proxy is already integrated in distributions because it is used by knfsd, and can be as easily used by cifsd, and you *should* really use it there, so we can have a single, consistent, maintained, mechanism for server side GSS authentication, and not have to repeat and reinvent kernel to userspace mechanisms.

And if you add it for cifsd you have yet another reason to do it for cifs.ko as well.

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

For the client we'll need to add some XDR parsing functions in kernel, they were omitted from my original patches because there was no client side kernel consumer back then, but it i an easy, mechanical change.

HTH, Simo.

On Wed, 2020-12-16 at 16:43 -0600, Steve French wrote:

generally I would feel more comfortable using something (library or utility) in Samba (if needed) for additional SPNEGO support if something is missing (in what the kernel drivers are doing to encapsulate Active Directory or Samba AD krb5 tickets in SPNEGO) as Samba is better maintained/tested etc. than most components. Is there something in Samba that could be used here instead of having a dependency on another project - Samba has been doing Kerberos/SPNEGO longer than most ...? There are probably others (jra, Metze etc.) that have would know more about gssproxy vs. Samba equivalents though and would defer to them ...

On Wed, Dec 16, 2020 at 8:33 AM Simo Sorce simo@redhat.com wrote:

...

Hi Michael, as you say the best course of action would be for cifs.ko to move to use the RPC interface we defined for knfsd (with any extensions that may be needed), and we had discussions in the past with cifs upstream developers about it. But nothing really materialized.

If something is needed in the short term, I thjink the quickest course of action is indeed to change the userspace helper to use gssapi function calls, so that they can be intercepted like we do for rpc.gssd (nfs client's userspace helper).

Unfortunately I do not have the cycles to work on that myself at this time :-(

HTH, Simo.

On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote:

...

Hello,

I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1].

My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2]

From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials.

Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]).

Assuming my understanding is correct so far:

Is anyone doing any work on this and could use some help (testing, coding)? What would be expected complexity and possible roadblocks when trying to make a start at implementing this? Or is the idea moot due to some constraint or recent development I'm not aware of?

I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though.

As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on. Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)?

[1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-... [2] https://pagure.io/gssproxy/issue/56 [3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md [4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server [5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client [6] https://www.spinics.net/lists/linux-cifs/msg20182.html -- Thanks, Michael _______________________________________________ gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or...

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

One big worry we had about the user space upcalls to larger libraries is low memory situations (could be especially dangerous when network booted) - since during reconnect if the system is low on memory, freeing up pages in the cache could require writing network frames with the cached data which when it requires upcalls can consume more memory (we want to reduce the risk of deadlock especially as SMB3 is often used in very small devices, not just large VMs). Any idea of the memory consumption of these libraries and their dependencies?

On Thu, Dec 17, 2020 at 3:22 PM Steve French smfrench@gmail.com wrote:

A couple of more specific questions:

1. Do you have a link to how the various user space tools that would

often need to use kerberos (e.g. "smbclient" and "smbcacls") integrate with this so I could see some examples of how they tie into your proxy?

2. Does it use the kernel keyring to store credentials or rely on the

traditional kerberos key cache? Presumably there continues to be a drive to keep as many credentials as possible in the kernel for maximal security in this very challenging recent security landscape.

3. Besides Kerberos and NTLMSSP what other auth protocols do you

support in gssproxy (e.g. PKU2U is one I see commonly in the list of SPNEGO OIDs during auth). There has been a push recently to move away from NTLMv2/NTLMSSP (which is often encapsulated in SPNEGO) to stronger 'peer to peer' protocols. Macs IIRC have peer to peer Kerberos and presumably PKU2U (see https://tools.ietf.org/id/draft-zhu-pku2u-07.html) is reasonably common in Windows. It would be useful if you already have support for PKU2U in your libraries or know how to tie them in so we would not have to rely on NTLMSSP/NTLMv2 for peer to peer (systems that are joined to a domain like Samba AD or Active Directory or AAD) and could improve security in non domain joined cases.

4. Does gssproxy integrate in any way with Samba server? There would

be strong interest in having easy ways to plug in additional security protocols transparently into the client (cifs.ko and user space tools like smbclient and smbcacls and Ronnie's libsmb3 etc.) and servers (Samba and ksmbd) - so e.g. if O_AUTH became useful for file sharing, could gssproxy help transparently enable this on the client and server (since the SPNEGO flows, at least for SMB3 are fairly opaque and the client and server don't really care what auth is negotiated as long as the underlying libraries send the right list of auth protocols and negotiate the correct 'preferred' one that was requested on mount or in the /etc config files).

On Thu, Dec 17, 2020 at 7:39 AM Simo Sorce simo@redhat.com wrote:

...

Hi Steve,

GSSAPI and krb5 as implemented in system krb5 libraries exists from longer than Samba has implemented those capabilities, I do not think it make sense to reason along those lines.

GSS-Proxy has been built with a protocol to talk from the kernel that resolved a number of issues for knfsd (eg big packet sizes when a MS- PAC is present).

And Samba uses internally exactly the same krb5 mechanism as it defers to the kerberos libraries as well.

Additionally GSS-Proxy can be very easily extended to also do NTLMSSP using the same interface as I have built the gssntlmssp long ago from the MS spec, and is probably the most correct NTLMSSP implementation you can find around.

Gssntlmssp also has a Winbind backend so you get automaticaly access to whatever cached credentials Winbindd has for users as a bonus (although the integration can be improved there), yet you *can* use it w/o Winbindd just fine providing a credential file (smbpasswd format compatible).

GSS-Proxy is already integrated in distributions because it is used by knfsd, and can be as easily used by cifsd, and you *should* really use it there, so we can have a single, consistent, maintained, mechanism for server side GSS authentication, and not have to repeat and reinvent kernel to userspace mechanisms.

And if you add it for cifsd you have yet another reason to do it for cifs.ko as well.

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

For the client we'll need to add some XDR parsing functions in kernel, they were omitted from my original patches because there was no client side kernel consumer back then, but it i an easy, mechanical change.

HTH, Simo.

On Wed, 2020-12-16 at 16:43 -0600, Steve French wrote:

...

generally I would feel more comfortable using something (library or utility) in Samba (if needed) for additional SPNEGO support if something is missing (in what the kernel drivers are doing to encapsulate Active Directory or Samba AD krb5 tickets in SPNEGO) as Samba is better maintained/tested etc. than most components. Is there something in Samba that could be used here instead of having a dependency on another project - Samba has been doing Kerberos/SPNEGO longer than most ...? There are probably others (jra, Metze etc.) that have would know more about gssproxy vs. Samba equivalents though and would defer to them ...

On Wed, Dec 16, 2020 at 8:33 AM Simo Sorce simo@redhat.com wrote:

...

Hi Michael, as you say the best course of action would be for cifs.ko to move to use the RPC interface we defined for knfsd (with any extensions that may be needed), and we had discussions in the past with cifs upstream developers about it. But nothing really materialized.

If something is needed in the short term, I thjink the quickest course of action is indeed to change the userspace helper to use gssapi function calls, so that they can be intercepted like we do for rpc.gssd (nfs client's userspace helper).

Unfortunately I do not have the cycles to work on that myself at this time :-(

HTH, Simo.

On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote:

...

Hello,

I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1].

My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2]

From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials.

Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]).

Assuming my understanding is correct so far:

Is anyone doing any work on this and could use some help (testing, coding)? What would be expected complexity and possible roadblocks when trying to make a start at implementing this? Or is the idea moot due to some constraint or recent development I'm not aware of?

I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though.

As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on. Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)?

[1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-... [2] https://pagure.io/gssproxy/issue/56 [3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md [4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server [5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client [6] https://www.spinics.net/lists/linux-cifs/msg20182.html -- Thanks, Michael _______________________________________________ gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or...

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Thanks,

Steve

On Thu, 2020-12-17 at 15:22 -0600, Steve French wrote:

A couple of more specific questions:

1. Do you have a link to how the various user space tools that would

often need to use kerberos (e.g. "smbclient" and "smbcacls") integrate with this so I could see some examples of how they tie into your proxy?

Tools will not need to change one bit.

For client applications the proxy simply allows access to user's ccaches, or (and this is a feature) allows unattended use of user's credentials either via user's keytabs or via constrained delegation using server credentials.

The latter two features are implemented w/o needing any changes on most client applications (some may need minor changes to the way they invoke APIs to be less prescriptive, but the changes are generally very minimal and straightforward).

For the latter two feature the proxy also offers privilege separation, by handing to user processes an encrypted ccache, and intercepting GSSAPI calls (via libgssapi mechglue, hence transparent to applciations).

2. Does it use the kernel keyring to store credentials or rely on the

traditional kerberos key cache?

The latter.

Presumably there continues to be a drive to keep as many credentials as possible in the kernel for maximal security in this very challenging recent security landscape.

You can use the KEYRING ccacche type if you want, or you can use the KCM daemon, or as I said above you could use the gss-proxy privsep feature. IT really is up to distro defaults/admin preference/choice.

3. Besides Kerberos and NTLMSSP what other auth protocols do you

support in gssproxy (e.g. PKU2U is one I see commonly in the list of SPNEGO OIDs during auth).

Currently GSS-Proxy handles only Krb5, but extending it to cover GSS- NTLMSSP is trivial. PKU2U would need to be implemented by the krb5 mechanism, but we've never seen any real demand for that.

There has been a push recently to move away from NTLMv2/NTLMSSP (which is often encapsulated in SPNEGO) to stronger 'peer to peer' protocols. Macs IIRC have peer to peer Kerberos and presumably PKU2U (see https://tools.ietf.org/id/draft-zhu-pku2u-07.html) is reasonably common in Windows. It would be useful if you already have support for PKU2U in your libraries or know how to tie them in so we would not have to rely on NTLMSSP/NTLMv2 for peer to peer (systems that are joined to a domain like Samba AD or Active Directory or AAD) and could improve security in non domain joined cases.

PKU2U is not supported in any library available, so that work would need to be done there first.

Just to be clear, GSS-Proxy does not implement any mecahnism directly, It is a mechglue layer used to "proxy" a mechanism so that execution happens in another context, it still uses libkrb5/libgssapi internally, so any support needs to be implemented there first.

4. Does gssproxy integrate in any way with Samba server? There would

be strong interest in having easy ways to plug in additional security protocols transparently into the client (cifs.ko and user space tools like smbclient and smbcacls and Ronnie's libsmb3 etc.) and servers (Samba and ksmbd) - so e.g. if O_AUTH became useful for file sharing,

No, what you are looking for is for Samba to use libgssapi instead of re-implementing most of it on it's own. GSS-Proxy is a GSSAPI mechanism fundamentally.

could gssproxy help transparently enable this on the client and server (since the SPNEGO flows, at least for SMB3 are fairly opaque and the client and server don't really care what auth is negotiated as long as the underlying libraries send the right list of auth protocols and negotiate the correct 'preferred' one that was requested on mount or in the /etc config files).

GSS-Proxy is 2 things:

- A GSSAPI daemon for the kernel so you do not need to implement GSS or krb5 in there. In this sense it could definitely do that for cifs.ko/cifsd, as *all* GSSAPI processing is deferred to the proxy, the kernel only shuffles the blobs of data from kernel to userspace using a gssapi-like interface implemented via RPC (XDR encoding). If you look at knfsd you will see zero gssapi work in the kernel.

- A privilege separation daemon so you can allow an app to use GSSAPIwithout having access to "naked" keytabs, via interposing the krb5 mechanism. At the moment, SPNEGO is *entirely* handled in libgssapi, as it is a meta-mechanism. So for userspace applications GSS-Proxy (and libgssapi's mechglue layer) would need to be changed to intercept SPNEGO, and change the list of mechanisms available, and then hope the application doesn't make assumptions about those mechanisms ... in practice it will always be easier to simply provide a gssapi mechanism (you can provide them as shared objects and load them into GSSAPI at runtime via /etc/gss/mech.d/*.conf files, Which is how gssproxy and gss-ntlmssp are loaded into MIT's libgssapi).

Note that for the kernel case, given the protocol is used directly even SPNEGO can be easily proxied, so the capabalities for user-space and kernel are slightly different at this time.

HTH, Simo.

On Thu, Dec 17, 2020 at 7:39 AM Simo Sorce simo@redhat.com wrote:

...

Hi Steve,

GSSAPI and krb5 as implemented in system krb5 libraries exists from longer than Samba has implemented those capabilities, I do not think it make sense to reason along those lines.

GSS-Proxy has been built with a protocol to talk from the kernel that resolved a number of issues for knfsd (eg big packet sizes when a MS- PAC is present).

And Samba uses internally exactly the same krb5 mechanism as it defers to the kerberos libraries as well.

Additionally GSS-Proxy can be very easily extended to also do NTLMSSP using the same interface as I have built the gssntlmssp long ago from the MS spec, and is probably the most correct NTLMSSP implementation you can find around.

Gssntlmssp also has a Winbind backend so you get automaticaly access to whatever cached credentials Winbindd has for users as a bonus (although the integration can be improved there), yet you *can* use it w/o Winbindd just fine providing a credential file (smbpasswd format compatible).

GSS-Proxy is already integrated in distributions because it is used by knfsd, and can be as easily used by cifsd, and you *should* really use it there, so we can have a single, consistent, maintained, mechanism for server side GSS authentication, and not have to repeat and reinvent kernel to userspace mechanisms.

And if you add it for cifsd you have yet another reason to do it for cifs.ko as well.

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

For the client we'll need to add some XDR parsing functions in kernel, they were omitted from my original patches because there was no client side kernel consumer back then, but it i an easy, mechanical change.

HTH, Simo.

On Wed, 2020-12-16 at 16:43 -0600, Steve French wrote:

...

generally I would feel more comfortable using something (library or utility) in Samba (if needed) for additional SPNEGO support if something is missing (in what the kernel drivers are doing to encapsulate Active Directory or Samba AD krb5 tickets in SPNEGO) as Samba is better maintained/tested etc. than most components. Is there something in Samba that could be used here instead of having a dependency on another project - Samba has been doing Kerberos/SPNEGO longer than most ...? There are probably others (jra, Metze etc.) that have would know more about gssproxy vs. Samba equivalents though and would defer to them ...

On Wed, Dec 16, 2020 at 8:33 AM Simo Sorce simo@redhat.com wrote:

...

Hi Michael, as you say the best course of action would be for cifs.ko to move to use the RPC interface we defined for knfsd (with any extensions that may be needed), and we had discussions in the past with cifs upstream developers about it. But nothing really materialized.

If something is needed in the short term, I thjink the quickest course of action is indeed to change the userspace helper to use gssapi function calls, so that they can be intercepted like we do for rpc.gssd (nfs client's userspace helper).

Unfortunately I do not have the cycles to work on that myself at this time :-(

HTH, Simo.

On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote:

...

Hello,

I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1].

My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2]

From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials.

Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]).

Assuming my understanding is correct so far:

Is anyone doing any work on this and could use some help (testing, coding)? What would be expected complexity and possible roadblocks when trying to make a start at implementing this? Or is the idea moot due to some constraint or recent development I'm not aware of?

I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though.

As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on. Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)?

[1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-... [2] https://pagure.io/gssproxy/issue/56 [3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md [4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server [5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client [6] https://www.spinics.net/lists/linux-cifs/msg20182.html -- Thanks, Michael _______________________________________________ gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or...

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

On Fri, 2021-02-19 at 03:30 -0800, Shyam Prasad N wrote:

Hi Simo,

...

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

Could you please point me to the documentation for doing this?

I do not know if the kernel documents this, but the way gssproxy works is that when you start the daemon it pokes at the kernel to let it know the socket is available. So then the kernel opens the socket in the namespace the proxy is running into (detected from the poking operation, which is a write in a proc file).

HTH, Simo.

Regards, Shyam

On Thu, Dec 17, 2020 at 5:41 AM Simo Sorce simo@redhat.com wrote:

...

Hi Steve,

GSSAPI and krb5 as implemented in system krb5 libraries exists from longer than Samba has implemented those capabilities, I do not think it make sense to reason along those lines.

GSS-Proxy has been built with a protocol to talk from the kernel that resolved a number of issues for knfsd (eg big packet sizes when a MS- PAC is present).

And Samba uses internally exactly the same krb5 mechanism as it defers to the kerberos libraries as well.

Additionally GSS-Proxy can be very easily extended to also do NTLMSSP using the same interface as I have built the gssntlmssp long ago from the MS spec, and is probably the most correct NTLMSSP implementation you can find around.

Gssntlmssp also has a Winbind backend so you get automaticaly access to whatever cached credentials Winbindd has for users as a bonus (although the integration can be improved there), yet you *can* use it w/o Winbindd just fine providing a credential file (smbpasswd format compatible).

GSS-Proxy is already integrated in distributions because it is used by knfsd, and can be as easily used by cifsd, and you *should* really use it there, so we can have a single, consistent, maintained, mechanism for server side GSS authentication, and not have to repeat and reinvent kernel to userspace mechanisms.

And if you add it for cifsd you have yet another reason to do it for cifs.ko as well.

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

For the client we'll need to add some XDR parsing functions in kernel, they were omitted from my original patches because there was no client side kernel consumer back then, but it i an easy, mechanical change.

HTH, Simo.

On Wed, 2020-12-16 at 16:43 -0600, Steve French wrote:

...

generally I would feel more comfortable using something (library or utility) in Samba (if needed) for additional SPNEGO support if something is missing (in what the kernel drivers are doing to encapsulate Active Directory or Samba AD krb5 tickets in SPNEGO) as Samba is better maintained/tested etc. than most components. Is there something in Samba that could be used here instead of having a dependency on another project - Samba has been doing Kerberos/SPNEGO longer than most ...? There are probably others (jra, Metze etc.) that have would know more about gssproxy vs. Samba equivalents though and would defer to them ...

On Wed, Dec 16, 2020 at 8:33 AM Simo Sorce simo@redhat.com wrote:

...

Hi Michael, as you say the best course of action would be for cifs.ko to move to use the RPC interface we defined for knfsd (with any extensions that may be needed), and we had discussions in the past with cifs upstream developers about it. But nothing really materialized.

If something is needed in the short term, I thjink the quickest course of action is indeed to change the userspace helper to use gssapi function calls, so that they can be intercepted like we do for rpc.gssd (nfs client's userspace helper).

Unfortunately I do not have the cycles to work on that myself at this time :-(

HTH, Simo.

On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote:

...

Hello,

I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1].

My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2]

From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials.

Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]).

Assuming my understanding is correct so far:

Is anyone doing any work on this and could use some help (testing, coding)? What would be expected complexity and possible roadblocks when trying to make a start at implementing this? Or is the idea moot due to some constraint or recent development I'm not aware of?

I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though.

As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on. Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)?

[1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-... [2] https://pagure.io/gssproxy/issue/56 [3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md [4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server [5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client [6] https://www.spinics.net/lists/linux-cifs/msg20182.html -- Thanks, Michael _______________________________________________ gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or...

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

Nice work!

Notice that GSS-Proxy can already perform access control, so you do not have to create additional sockets or the systemd script, but you can simply create service files in gssproxy that filter based on uid or even SELinux context if you like.

There are additional filters based on the calling program too, but those are not to be used to enforce security measures as argv[0] is under the control of the user.

HTH, Simo.

On Tue, 2021-02-23 at 12:42 -0500, Jacob Shivers wrote:

I have tested the patches for cifs.upcall and can say that with some additional modifications to gssproxy the end setup brings a degree of feature parity to SMB clients that had been previously exclusive to NFS clients. Deployment does require some additional configuration, including the creation of a drop-in file for gssproxy under /etc/gssproxy and for the gssproxy service managed by systemd

### KDC configuration

*** delegation ***

Constrained Delegation (CD) for the SMB host to the Kerberized SMB server Resource Based Constrained Delegation (RBCD) on the Kerberized SMB server to determine which SMB clients can delegate

### SMB client configuration

*** sssd ***

Configuration file modification.

Disable using fully qualified domain names as impersonation does not correctly handle fully qualified names at time of ticket acquisition.

use_fully_qualified_names = False

*** gssproxy ***

Drop file creation

Add a drop file for gssproxy to create the necessary socket and corresponding settings.

# cat /etc/gssproxy/99-cifs-client.conf with contents [service/cifs] mechs = krb5 socket = /var/lib/gssproxy/cifs.sock cred_store = keytab:/etc/krb5.keytab cred_usage = initiate euid = 0 impersonate = yes allow_any_uid = yes

Service drop-in file.

Create a drop-in file to limit socket access for an unattended user, if desired.

# cat /etc/systemd/system/gssproxy.service.d/90-cifs.conf [Service] # Limit cifs.sock socket file accessiblility to just the unattended user. ExecStartPost=/bin/bash -c 'chmod 660 /var/lib/gssproxy/cifs.sock && setfacl -m u:chang:rw /var/lib/gssproxy/cifs.sock'

*** cifs.upcall ***

cifs.spnego.conf modification

Allow for gssprxy to be used and specify socket file

# cat /etc/request-key.d/cifs.spnego.conf create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall %k

include the '-t' flag to allow for accessing a Kerberized DFS namespace using a domain based mount, i.e //example.net/dfs/share

create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall -t %k

The above does allow for unattended users to access a Kerberized SMB share while limiting access to only a specific user:

# mount //win2k16-dfs1.example.net/greendale/ /mnt -o sec=krb5,username='TEST-BOX$@EXAMPLE.NET',multiuser

# su - jeff Last login: Fri Feb 5 12:14:42 EST 2021 on pts/0 [jeff@test-box ~]$ ll /mnt ls: cannot access '/mnt': Permission denied [jeff@test-box ~]$ logout

# su - chang Last login: Fri Feb 5 12:14:46 EST 2021 on pts/0 [chang@test-box ~]$ klist klist: No credentials cache found (filename: /tmp/krb5cc_602001123) [chang@test-box ~]$ ls -l /mnt total 143

drwxr-xr-x. 2 chang domain users 0 Oct 4 2018 DfsrPrivate -rwxr-xr-x. 1 chang domain users 0 Sep 22 10:07 test_file -rwxr-xr-x. 1 chang domain users 0 Dec 14 15:22 whoami drwxr-xr-x. 2 chang domain users 0 Dec 7 12:54 winhome

[chang@test-box ~]$ klist klist: No credentials cache found (filename: /tmp/krb5cc_602001123)

Feb 23 12:22:44.857956 test-box.example.net su[1672]: (to jeff) root on pts/1 Feb 23 12:22:44.866263 test-box.example.net su[1672]: pam_systemd(su-l:session): Cannot create session: Already running in a session or user slice Feb 23 12:22:44.867158 test-box.example.net su[1672]: pam_unix(su-l:session): session opened for user jeff by root(uid=0) Feb 23 12:22:46.253310 test-box.example.net cifs.upcall[1700]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cedc;creduid=0x23e1cedc;pid=0x6a3 Feb 23 12:22:46.253335 test-box.example.net cifs.upcall[1700]: ver=2 Feb 23 12:22:46.253338 test-box.example.net cifs.upcall[1700]: host=win2k16-dfs1.example.net Feb 23 12:22:46.253342 test-box.example.net cifs.upcall[1700]: ip=192.168.124.132 Feb 23 12:22:46.253344 test-box.example.net cifs.upcall[1700]: sec=1 Feb 23 12:22:46.253348 test-box.example.net cifs.upcall[1700]: uid=602001116 Feb 23 12:22:46.253352 test-box.example.net cifs.upcall[1700]: creduid=602001116 Feb 23 12:22:46.253365 test-box.example.net cifs.upcall[1700]: pid=1699 Feb 23 12:22:46.253978 test-box.example.net cifs.upcall[1700]: get_cachename_from_process_env: pathname=/proc/1699/environ Feb 23 12:22:46.254995 test-box.example.net cifs.upcall[1700]: get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001116 Feb 23 12:22:46.255015 test-box.example.net cifs.upcall[1700]: get_tgt_time: unable to get principal Feb 23 12:22:46.255021 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net Feb 23 12:22:46.255024 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: using GSS-API Feb 23 12:22:46.259295 test-box.example.net cifs.upcall[1700]: GSS-API error init_sec_context: Unspecified GSS failure. Minor code may provide more information Feb 23 12:22:46.259306 test-box.example.net cifs.upcall[1700]: GSS-API error init_sec_context: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_602001116) Feb 23 12:22:46.259311 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: failed to obtain service ticket via GSS (851968) Feb 23 12:22:46.259314 test-box.example.net cifs.upcall[1700]: Unable to obtain service ticket Feb 23 12:22:46.259323 test-box.example.net cifs.upcall[1700]: Exit status 851968 Feb 23 12:22:46.262827 test-box.example.net kernel: CIFS VFS: \win2k16-dfs1.example.net Send error in SessSetup = -126 Feb 23 12:22:47.398266 test-box.example.net su[1672]: pam_unix(su-l:session): session closed for user jeff Feb 23 12:22:49.159640 test-box.example.net su[1702]: (to chang) root on pts/1 Feb 23 12:22:49.173264 test-box.example.net su[1702]: pam_systemd(su-l:session): Cannot create session: Already running in a session or user slice Feb 23 12:22:49.173967 test-box.example.net su[1702]: pam_unix(su-l:session): session opened for user chang by root(uid=0) Feb 23 12:22:51.878743 test-box.example.net cifs.upcall[1729]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cee3;creduid=0x23e1cee3;pid=0x6c0 Feb 23 12:22:51.878765 test-box.example.net cifs.upcall[1729]: ver=2 Feb 23 12:22:51.878769 test-box.example.net cifs.upcall[1729]: host=win2k16-dfs1.example.net Feb 23 12:22:51.878773 test-box.example.net cifs.upcall[1729]: ip=192.168.124.132 Feb 23 12:22:51.878776 test-box.example.net cifs.upcall[1729]: sec=1 Feb 23 12:22:51.878780 test-box.example.net cifs.upcall[1729]: uid=602001123 Feb 23 12:22:51.878783 test-box.example.net cifs.upcall[1729]: creduid=602001123 Feb 23 12:22:51.878786 test-box.example.net cifs.upcall[1729]: pid=1728 Feb 23 12:22:51.879060 test-box.example.net cifs.upcall[1729]: get_cachename_from_process_env: pathname=/proc/1728/environ Feb 23 12:22:51.879799 test-box.example.net cifs.upcall[1729]: get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001123 Feb 23 12:22:51.879819 test-box.example.net cifs.upcall[1729]: get_tgt_time: unable to get principal Feb 23 12:22:51.879824 test-box.example.net cifs.upcall[1729]: handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net Feb 23 12:22:51.879827 test-box.example.net cifs.upcall[1729]: handle_krb5_mech: using GSS-API Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [2021/02/23 17:22:51]: Client [2021/02/23 17:22:51]: (/usr/sbin/cifs.upcall) [2021/02/23 17:22:51]: connected (fd = 14)[2021/02/23 17:22:51]: (pid = 1729) (uid = 602001123) (gid = 602000513)[2021/02/23 17:22:51]: (context = system_u:system_r:kernel_t:s0)[> Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:51]: Connection matched service cifs Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:51]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "cifs", euid: 602001123,socket: /var/lib/gssproxy/cifs.sock Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> time_req: 0 desired_mechs: { } cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 ) Feb 23 12:22:52.346639 test-box.example.net gssproxy[1000]: GSSX_RES_ACQUIRE_CRED( status: { 0 { 1 2 840 113554 1 2 2 } 0 "" "" [ ] } output_cred_handle: { "chang@EXAMPLE.NET" [ { "chang@EXAMPLE.NET" { 1 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 } ) Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: Connection matched service cifs Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 602001123,socket: /var/lib/gssproxy/cifs.sock Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: GSSX_ARG_INIT_SEC_CONTEXT( call_ctx: { "" [ ] } context_handle: <Null> cred_handle: { "chang@EXAMPLE.NET" [ { "chang@EXAMPLE.NET" { 1 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 } target_name: "cifs@win2k16-dfs1.example.net" mech> Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: Credentials allowed by configuration Feb 23 12:22:52.357103 test-box.example.net gssproxy[1000]: GSSX_RES_INIT_SEC_CONTEXT( status: { 0 { 1 2 840 113554 1 2 2 } 0 "" "" [ ] } context_handle: { [ ......H............ ] [ ] 0 { 1 2 840 113554 1 2 2 } "chang@EXAMPLE.NET" "cifs/win2k16-dfs1.example.net@EXAMPLE.NET" 36000 432 1 1 } output_token: [ .....> Feb 23 12:22:52.357419 test-box.example.net cifs.upcall[1729]: Exit status 0

Ultimately a helper-script packaged with cifs-utils or a separate package entirely could be responsible for adding the file under /etc/gssproxy and the drop-in file for systemd. The helper script could take a series of users/groups as arguments that would limit access to the socket file or there could be a separate config file that is read from to determine if access to the cifs.sock socket should be limited.

On Fri, Feb 19, 2021 at 12:38 PM Simo Sorce simo@redhat.com wrote:

...

On Fri, 2021-02-19 at 03:30 -0800, Shyam Prasad N wrote:

...

Hi Simo,

...

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

Could you please point me to the documentation for doing this?

I do not know if the kernel documents this, but the way gssproxy works is that when you start the daemon it pokes at the kernel to let it know the socket is available. So then the kernel opens the socket in the namespace the proxy is running into (detected from the poking operation, which is a write in a proc file).

HTH, Simo.

...

Regards, Shyam

On Thu, Dec 17, 2020 at 5:41 AM Simo Sorce simo@redhat.com wrote:

...

Hi Steve,

GSSAPI and krb5 as implemented in system krb5 libraries exists from longer than Samba has implemented those capabilities, I do not think it make sense to reason along those lines.

GSS-Proxy has been built with a protocol to talk from the kernel that resolved a number of issues for knfsd (eg big packet sizes when a MS- PAC is present).

And Samba uses internally exactly the same krb5 mechanism as it defers to the kerberos libraries as well.

Additionally GSS-Proxy can be very easily extended to also do NTLMSSP using the same interface as I have built the gssntlmssp long ago from the MS spec, and is probably the most correct NTLMSSP implementation you can find around.

Gssntlmssp also has a Winbind backend so you get automaticaly access to whatever cached credentials Winbindd has for users as a bonus (although the integration can be improved there), yet you *can* use it w/o Winbindd just fine providing a credential file (smbpasswd format compatible).

GSS-Proxy is already integrated in distributions because it is used by knfsd, and can be as easily used by cifsd, and you *should* really use it there, so we can have a single, consistent, maintained, mechanism for server side GSS authentication, and not have to repeat and reinvent kernel to userspace mechanisms.

And if you add it for cifsd you have yet another reason to do it for cifs.ko as well.

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

For the client we'll need to add some XDR parsing functions in kernel, they were omitted from my original patches because there was no client side kernel consumer back then, but it i an easy, mechanical change.

HTH, Simo.

On Wed, 2020-12-16 at 16:43 -0600, Steve French wrote:

...

generally I would feel more comfortable using something (library or utility) in Samba (if needed) for additional SPNEGO support if something is missing (in what the kernel drivers are doing to encapsulate Active Directory or Samba AD krb5 tickets in SPNEGO) as Samba is better maintained/tested etc. than most components. Is there something in Samba that could be used here instead of having a dependency on another project - Samba has been doing Kerberos/SPNEGO longer than most ...? There are probably others (jra, Metze etc.) that have would know more about gssproxy vs. Samba equivalents though and would defer to them ...

On Wed, Dec 16, 2020 at 8:33 AM Simo Sorce simo@redhat.com wrote:

...

Hi Michael, as you say the best course of action would be for cifs.ko to move to use the RPC interface we defined for knfsd (with any extensions that may be needed), and we had discussions in the past with cifs upstream developers about it. But nothing really materialized.

If something is needed in the short term, I thjink the quickest course of action is indeed to change the userspace helper to use gssapi function calls, so that they can be intercepted like we do for rpc.gssd (nfs client's userspace helper).

Unfortunately I do not have the cycles to work on that myself at this time :-(

HTH, Simo.

On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote: > Hello, > > I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1]. > > My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2] > > From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials. > > Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]). > > Assuming my understanding is correct so far: > > Is anyone doing any work on this and could use some help (testing, coding)? > What would be expected complexity and possible roadblocks when trying to make a start at implementing this? > Or is the idea moot due to some constraint or recent development I'm not aware of? > > I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though. > > As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on. > Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)? > > [1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-... > [2] https://pagure.io/gssproxy/issue/56 > [3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md > [4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server > [5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client > [6] https://www.spinics.net/lists/linux-cifs/msg20182.html > -- > Thanks, > Michael > _______________________________________________ > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org > To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or...

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

On Tue, 2021-03-02 at 15:46 -0500, Jason Keltz wrote:

Hi.

I'm running gssproxy on many hosts with CentOS 7.9. gssproxy is constantly generating this error in syslog for every host, repeatedly:

Mar 02 15:41:53 sel01 gssproxy[977]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No creden...che found Mar 02 15:41:53 sel01 gssproxy[881]: gssproxy[977]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more informa...che found M

Looking in more detail, it's constantly trying to open /var/lib/gssproxy/clients/krb5cc_42. UID 42 is gdm. It's a local user not in Kerberos. When I strace the gdm process, I don't see it constantly trying to access any particular share that would required Kerberos. I want gssproxy to completely ignore gdm altogether. How would I go about doing this?

So normally the GSS-Proxy mechglue is not invoked at all, as it is dependent on having an envronment variable set up. Did you set the env var to enable gssproxy system wide ? It is normally preferred to prepend it only for applications that you want to intercept by modifying unit files individually.

Simo.

On Tue, 2021-03-02 at 16:57 -0500, Jason Keltz wrote:

On 3/2/2021 4:48 PM, Simo Sorce wrote:

...

On Tue, 2021-03-02 at 15:46 -0500, Jason Keltz wrote:

...

Hi.

I'm running gssproxy on many hosts with CentOS 7.9. gssproxy is constantly generating this error in syslog for every host, repeatedly:

Mar 02 15:41:53 sel01 gssproxy[977]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No creden...che found Mar 02 15:41:53 sel01 gssproxy[881]: gssproxy[977]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more informa...che found M

Looking in more detail, it's constantly trying to open /var/lib/gssproxy/clients/krb5cc_42. UID 42 is gdm. It's a local user not in Kerberos. When I strace the gdm process, I don't see it constantly trying to access any particular share that would required Kerberos. I want gssproxy to completely ignore gdm altogether. How would I go about doing this?

So normally the GSS-Proxy mechglue is not invoked at all, as it is dependent on having an envronment variable set up. Did you set the env var to enable gssproxy system wide ? It is normally preferred to prepend it only for applications that you want to intercept by modifying unit files individually.

Hi Simo,

All the clients are running gssproxy by default. As far as I know, I haven't changed anything at all except adding to 99-nfs-client.conf krb5_principal.

I assumed this was the default behaviour. /etc/gssproxy/gssproxy.conf contains nothing but "[gssproxy]".

Where would I look?

Ah NFS, well what is seem to be happening is that GDM is trying to access some NFS mounts, and causing the NFS client to try to authenticate on behalf of the gdm user.

I assume gdm is trying to check some user home directory you mount over NFS?

If that's the case (and you want to grant gdm the ability to perform those accesses) you could define an additional configuration section for NFS in gssproxy.conf with euid=42

As that is a more specific configuration it should match first, you can then configure it to let gdm use the host keytab for authentication (using the machine krb5 principal), this will generally end up granting "nobody" user access on the NFS server, or similar (depending on your id mapping configuration there.

HTH, Simo.

On Wed, 2021-03-03 at 11:26 -0500, Jason Keltz wrote:

On 3/3/2021 10:38 AM, Simo Sorce wrote:

...

On Tue, 2021-03-02 at 16:57 -0500, Jason Keltz wrote:

...

On 3/2/2021 4:48 PM, Simo Sorce wrote:

...

On Tue, 2021-03-02 at 15:46 -0500, Jason Keltz wrote:

...

Hi.

I'm running gssproxy on many hosts with CentOS 7.9. gssproxy is constantly generating this error in syslog for every host, repeatedly:

Mar 02 15:41:53 sel01 gssproxy[977]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No creden...che found Mar 02 15:41:53 sel01 gssproxy[881]: gssproxy[977]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more informa...che found M

Looking in more detail, it's constantly trying to open /var/lib/gssproxy/clients/krb5cc_42. UID 42 is gdm. It's a local user not in Kerberos. When I strace the gdm process, I don't see it constantly trying to access any particular share that would required Kerberos. I want gssproxy to completely ignore gdm altogether. How would I go about doing this?

So normally the GSS-Proxy mechglue is not invoked at all, as it is dependent on having an envronment variable set up. Did you set the env var to enable gssproxy system wide ? It is normally preferred to prepend it only for applications that you want to intercept by modifying unit files individually.

Hi Simo,

All the clients are running gssproxy by default. As far as I know, I haven't changed anything at all except adding to 99-nfs-client.conf krb5_principal.

I assumed this was the default behaviour. /etc/gssproxy/gssproxy.conf contains nothing but "[gssproxy]".

Where would I look?

Ah NFS, well what is seem to be happening is that GDM is trying to access some NFS mounts, and causing the NFS client to try to authenticate on behalf of the gdm user.

I assume gdm is trying to check some user home directory you mount over NFS?

If that's the case (and you want to grant gdm the ability to perform those accesses) you could define an additional configuration section for NFS in gssproxy.conf with euid=42

As that is a more specific configuration it should match first, you can then configure it to let gdm use the host keytab for authentication (using the machine krb5 principal), this will generally end up granting "nobody" user access on the NFS server, or similar (depending on your id mapping configuration there.

Hi Simo,

I assume, as you said, that gdm is trying to access the NFS home directories, but why would it be doing that? GDM home directory is not on an NFS share. Before a user logs in, it's not clear what it would be doing over and over again. Any idea how I could track it (and stop it)?

Before login, GDM, I assume should only read the Init startup. Init does indeed refer to some NFS mounts. However, Init runs as root, and root is mapped to the machine account. I've verified that those accesses are by root, and they work exactly as expected getting the proper access.

Rather than giving gdm user access to the share, can I tell gssproxy to ignore requests from this user instead? I'd like to know what it's doing and why. I'm just not sure how to find it.

We do not have a way in gssproxy to drop requests on the floor at this time, unfortunately.

Simo.

On Wed, 2021-03-03 at 16:28 -0500, Jason Keltz wrote:

On 3/3/2021 12:20 PM, Simo Sorce wrote:

...

On Wed, 2021-03-03 at 11:26 -0500, Jason Keltz wrote:

...

On 3/3/2021 10:38 AM, Simo Sorce wrote:

...

On Tue, 2021-03-02 at 16:57 -0500, Jason Keltz wrote:

...

On 3/2/2021 4:48 PM, Simo Sorce wrote:

...

On Tue, 2021-03-02 at 15:46 -0500, Jason Keltz wrote: > Hi. > > I'm running gssproxy on many hosts with CentOS 7.9. gssproxy is > constantly generating this error in syslog for every host, repeatedly: > > Mar 02 15:41:53 sel01 gssproxy[977]: (OID: { 1 2 840 113554 1 2 2 }) > Unspecified GSS failure. Minor code may provide more information, No > creden...che found > Mar 02 15:41:53 sel01 gssproxy[881]: gssproxy[977]: (OID: { 1 2 840 > 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more > informa...che found > M > > Looking in more detail, it's constantly trying to open > /var/lib/gssproxy/clients/krb5cc_42. UID 42 is gdm. It's a local user > not in Kerberos. When I strace the gdm process, I don't see it > constantly trying to access any particular share that would required > Kerberos. I want gssproxy to completely ignore gdm altogether. How > would I go about doing this? So normally the GSS-Proxy mechglue is not invoked at all, as it is dependent on having an envronment variable set up. Did you set the env var to enable gssproxy system wide ? It is normally preferred to prepend it only for applications that you want to intercept by modifying unit files individually.

Hi Simo,

All the clients are running gssproxy by default. As far as I know, I haven't changed anything at all except adding to 99-nfs-client.conf krb5_principal.

I assumed this was the default behaviour. /etc/gssproxy/gssproxy.conf contains nothing but "[gssproxy]".

Where would I look?

Ah NFS, well what is seem to be happening is that GDM is trying to access some NFS mounts, and causing the NFS client to try to authenticate on behalf of the gdm user.

I assume gdm is trying to check some user home directory you mount over NFS?

If that's the case (and you want to grant gdm the ability to perform those accesses) you could define an additional configuration section for NFS in gssproxy.conf with euid=42

As that is a more specific configuration it should match first, you can then configure it to let gdm use the host keytab for authentication (using the machine krb5 principal), this will generally end up granting "nobody" user access on the NFS server, or similar (depending on your id mapping configuration there.

Hi Simo,

I assume, as you said, that gdm is trying to access the NFS home directories, but why would it be doing that? GDM home directory is not on an NFS share. Before a user logs in, it's not clear what it would be doing over and over again. Any idea how I could track it (and stop it)?

Before login, GDM, I assume should only read the Init startup. Init does indeed refer to some NFS mounts. However, Init runs as root, and root is mapped to the machine account. I've verified that those accesses are by root, and they work exactly as expected getting the proper access.

Rather than giving gdm user access to the share, can I tell gssproxy to ignore requests from this user instead? I'd like to know what it's doing and why. I'm just not sure how to find it.

We do not have a way in gssproxy to drop requests on the floor at this time, unfortunately.

I figured out that /etc/fonts/local.conf included a font from the NFS share which was causing gdm to constantly try the share, and gssproxy to constantly bang on syslog. I resolved that, and the constant errors generated from gdm went away. When I reboot the machine, I see no gssproxy errors.

Great.

However, when any user logs in, I see a few "Unspecified GSS failure" errors, but my home directory is mounted, and everything is fine. Why would I get these errors?

Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]: [status] Handling query input: 0x56413aeb64f0 (116) Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]: [status] Processing request [0x56413aeb64f0 (116)] Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]: [status] Executing request 6 (GSSX_ACQUIRE_CRED) from [0x56413aeb64f0 (116)] Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "nfs-client", euid: 1004,socket: (null) Mar 03 15:29:35 sel01 gssproxy[853]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } cred_usage: INITIATE initiator_time_r\ eq: 0 acceptor_time_req: 0 )

Is euid 1004 your user's uid ? I wonder if there is a race between creation of the cache and NFS access attempt.

Mar 03 15:29:35 sel01 gssproxy[896]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Mar 03 15:29:35 sel01 gssproxy[853]: gssproxy[896]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Mar 03 15:29:35 sel01 gssproxy[853]: GSSX_RES_ACQUIRE_CRED( status: { 851968 { 1 2 840 113554 1 2 2 } 2529639107 "Unspecified GSS failure. Minor code may provide more information" "No credentials cache found" [ ] } output_cred_handle: <Null>\ ) Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]: [status] Returned buffer 6 (GSSX_ACQUIRE_CRED) from [0x56413aeb64f0 (116)]: [0x7fe17c003370 (176)]

I can give you a much more detailed log if it would help.

Is anything in a level 3 log file (context_handle strings) confidential?

It may contain tokens, should be just encrypted data, but better not post from production systems. You can send it directly to me if you like.

On Fri, 2021-03-05 at 16:29 -0500, Jacob Shivers wrote:

if nfs-client is to be used as well as cifs-client, then wouldn't a different socket be required? Testing with cifs-client using the same socket returns an error from gssproxy:

"cifs sets allow_any_uid with the same socket, selinux_context, and program as nfs-client!".

The point is that you do not need a separate service definition if you are configuring them the same way :-) If you want different configurations but same access pattern, then yeah different sockets help. So it is just a metter of figuring out what works best.

Leveraging the built-in functionality of gssproxy is preferable as that addresses use cases where the process was started manually and not via systemd. Would it be reasonable to ever add gid filtering to gssproxy? I ask as that would allow for a group of batch processes/applications to have access where say applications could be added to a fixed group name/gid but, different uids may be deployed over time as different applications are used.

Yes I think adding gid filtering is a feature I find useful, feel free to open an issue describing the semantics you think would make more sense for your use case. Implementation is not hard, but nailing the semantics is important.

Simo.

On Tue, Feb 23, 2021 at 2:54 PM Simo Sorce simo@redhat.com wrote:

...

Nice work!

Notice that GSS-Proxy can already perform access control, so you do not have to create additional sockets or the systemd script, but you can simply create service files in gssproxy that filter based on uid or even SELinux context if you like.

There are additional filters based on the calling program too, but those are not to be used to enforce security measures as argv[0] is under the control of the user.

HTH, Simo.

On Tue, 2021-02-23 at 12:42 -0500, Jacob Shivers wrote:

...

I have tested the patches for cifs.upcall and can say that with some additional modifications to gssproxy the end setup brings a degree of feature parity to SMB clients that had been previously exclusive to NFS clients. Deployment does require some additional configuration, including the creation of a drop-in file for gssproxy under /etc/gssproxy and for the gssproxy service managed by systemd

### KDC configuration

*** delegation ***

Constrained Delegation (CD) for the SMB host to the Kerberized SMB server Resource Based Constrained Delegation (RBCD) on the Kerberized SMB server to determine which SMB clients can delegate

### SMB client configuration

*** sssd ***

Configuration file modification.

Disable using fully qualified domain names as impersonation does not correctly handle fully qualified names at time of ticket acquisition.

use_fully_qualified_names = False

*** gssproxy ***

Drop file creation

Add a drop file for gssproxy to create the necessary socket and corresponding settings.

# cat /etc/gssproxy/99-cifs-client.conf with contents [service/cifs] mechs = krb5 socket = /var/lib/gssproxy/cifs.sock cred_store = keytab:/etc/krb5.keytab cred_usage = initiate euid = 0 impersonate = yes allow_any_uid = yes

Service drop-in file.

Create a drop-in file to limit socket access for an unattended user, if desired.

# cat /etc/systemd/system/gssproxy.service.d/90-cifs.conf [Service] # Limit cifs.sock socket file accessiblility to just the unattended user. ExecStartPost=/bin/bash -c 'chmod 660 /var/lib/gssproxy/cifs.sock && setfacl -m u:chang:rw /var/lib/gssproxy/cifs.sock'

*** cifs.upcall ***

cifs.spnego.conf modification

Allow for gssprxy to be used and specify socket file

# cat /etc/request-key.d/cifs.spnego.conf create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall %k

include the '-t' flag to allow for accessing a Kerberized DFS namespace using a domain based mount, i.e //example.net/dfs/share

create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall -t %k

The above does allow for unattended users to access a Kerberized SMB share while limiting access to only a specific user:

# mount //win2k16-dfs1.example.net/greendale/ /mnt -o sec=krb5,username='TEST-BOX$@EXAMPLE.NET',multiuser

# su - jeff Last login: Fri Feb 5 12:14:42 EST 2021 on pts/0 [jeff@test-box ~]$ ll /mnt ls: cannot access '/mnt': Permission denied [jeff@test-box ~]$ logout

# su - chang Last login: Fri Feb 5 12:14:46 EST 2021 on pts/0 [chang@test-box ~]$ klist klist: No credentials cache found (filename: /tmp/krb5cc_602001123) [chang@test-box ~]$ ls -l /mnt total 143

drwxr-xr-x. 2 chang domain users 0 Oct 4 2018 DfsrPrivate -rwxr-xr-x. 1 chang domain users 0 Sep 22 10:07 test_file -rwxr-xr-x. 1 chang domain users 0 Dec 14 15:22 whoami drwxr-xr-x. 2 chang domain users 0 Dec 7 12:54 winhome

[chang@test-box ~]$ klist klist: No credentials cache found (filename: /tmp/krb5cc_602001123)

Feb 23 12:22:44.857956 test-box.example.net su[1672]: (to jeff) root on pts/1 Feb 23 12:22:44.866263 test-box.example.net su[1672]: pam_systemd(su-l:session): Cannot create session: Already running in a session or user slice Feb 23 12:22:44.867158 test-box.example.net su[1672]: pam_unix(su-l:session): session opened for user jeff by root(uid=0) Feb 23 12:22:46.253310 test-box.example.net cifs.upcall[1700]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cedc;creduid=0x23e1cedc;pid=0x6a3 Feb 23 12:22:46.253335 test-box.example.net cifs.upcall[1700]: ver=2 Feb 23 12:22:46.253338 test-box.example.net cifs.upcall[1700]: host=win2k16-dfs1.example.net Feb 23 12:22:46.253342 test-box.example.net cifs.upcall[1700]: ip=192.168.124.132 Feb 23 12:22:46.253344 test-box.example.net cifs.upcall[1700]: sec=1 Feb 23 12:22:46.253348 test-box.example.net cifs.upcall[1700]: uid=602001116 Feb 23 12:22:46.253352 test-box.example.net cifs.upcall[1700]: creduid=602001116 Feb 23 12:22:46.253365 test-box.example.net cifs.upcall[1700]: pid=1699 Feb 23 12:22:46.253978 test-box.example.net cifs.upcall[1700]: get_cachename_from_process_env: pathname=/proc/1699/environ Feb 23 12:22:46.254995 test-box.example.net cifs.upcall[1700]: get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001116 Feb 23 12:22:46.255015 test-box.example.net cifs.upcall[1700]: get_tgt_time: unable to get principal Feb 23 12:22:46.255021 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net Feb 23 12:22:46.255024 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: using GSS-API Feb 23 12:22:46.259295 test-box.example.net cifs.upcall[1700]: GSS-API error init_sec_context: Unspecified GSS failure. Minor code may provide more information Feb 23 12:22:46.259306 test-box.example.net cifs.upcall[1700]: GSS-API error init_sec_context: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_602001116) Feb 23 12:22:46.259311 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: failed to obtain service ticket via GSS (851968) Feb 23 12:22:46.259314 test-box.example.net cifs.upcall[1700]: Unable to obtain service ticket Feb 23 12:22:46.259323 test-box.example.net cifs.upcall[1700]: Exit status 851968 Feb 23 12:22:46.262827 test-box.example.net kernel: CIFS VFS: \win2k16-dfs1.example.net Send error in SessSetup = -126 Feb 23 12:22:47.398266 test-box.example.net su[1672]: pam_unix(su-l:session): session closed for user jeff Feb 23 12:22:49.159640 test-box.example.net su[1702]: (to chang) root on pts/1 Feb 23 12:22:49.173264 test-box.example.net su[1702]: pam_systemd(su-l:session): Cannot create session: Already running in a session or user slice Feb 23 12:22:49.173967 test-box.example.net su[1702]: pam_unix(su-l:session): session opened for user chang by root(uid=0) Feb 23 12:22:51.878743 test-box.example.net cifs.upcall[1729]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cee3;creduid=0x23e1cee3;pid=0x6c0 Feb 23 12:22:51.878765 test-box.example.net cifs.upcall[1729]: ver=2 Feb 23 12:22:51.878769 test-box.example.net cifs.upcall[1729]: host=win2k16-dfs1.example.net Feb 23 12:22:51.878773 test-box.example.net cifs.upcall[1729]: ip=192.168.124.132 Feb 23 12:22:51.878776 test-box.example.net cifs.upcall[1729]: sec=1 Feb 23 12:22:51.878780 test-box.example.net cifs.upcall[1729]: uid=602001123 Feb 23 12:22:51.878783 test-box.example.net cifs.upcall[1729]: creduid=602001123 Feb 23 12:22:51.878786 test-box.example.net cifs.upcall[1729]: pid=1728 Feb 23 12:22:51.879060 test-box.example.net cifs.upcall[1729]: get_cachename_from_process_env: pathname=/proc/1728/environ Feb 23 12:22:51.879799 test-box.example.net cifs.upcall[1729]: get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001123 Feb 23 12:22:51.879819 test-box.example.net cifs.upcall[1729]: get_tgt_time: unable to get principal Feb 23 12:22:51.879824 test-box.example.net cifs.upcall[1729]: handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net Feb 23 12:22:51.879827 test-box.example.net cifs.upcall[1729]: handle_krb5_mech: using GSS-API Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [2021/02/23 17:22:51]: Client [2021/02/23 17:22:51]: (/usr/sbin/cifs.upcall) [2021/02/23 17:22:51]: connected (fd = 14)[2021/02/23 17:22:51]: (pid = 1729) (uid = 602001123) (gid = 602000513)[2021/02/23 17:22:51]: (context = system_u:system_r:kernel_t:s0)[> Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:51]: Connection matched service cifs Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:51]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "cifs", euid: 602001123,socket: /var/lib/gssproxy/cifs.sock Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> time_req: 0 desired_mechs: { } cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 ) Feb 23 12:22:52.346639 test-box.example.net gssproxy[1000]: GSSX_RES_ACQUIRE_CRED( status: { 0 { 1 2 840 113554 1 2 2 } 0 "" "" [ ] } output_cred_handle: { "chang@EXAMPLE.NET" [ { "chang@EXAMPLE.NET" { 1 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 } ) Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: Connection matched service cifs Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 602001123,socket: /var/lib/gssproxy/cifs.sock Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: GSSX_ARG_INIT_SEC_CONTEXT( call_ctx: { "" [ ] } context_handle: <Null> cred_handle: { "chang@EXAMPLE.NET" [ { "chang@EXAMPLE.NET" { 1 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 } target_name: "cifs@win2k16-dfs1.example.net" mech> Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: Credentials allowed by configuration Feb 23 12:22:52.357103 test-box.example.net gssproxy[1000]: GSSX_RES_INIT_SEC_CONTEXT( status: { 0 { 1 2 840 113554 1 2 2 } 0 "" "" [ ] } context_handle: { [ ......H............ ] [ ] 0 { 1 2 840 113554 1 2 2 } "chang@EXAMPLE.NET" "cifs/win2k16-dfs1.example.net@EXAMPLE.NET" 36000 432 1 1 } output_token: [ .....> Feb 23 12:22:52.357419 test-box.example.net cifs.upcall[1729]: Exit status 0

Ultimately a helper-script packaged with cifs-utils or a separate package entirely could be responsible for adding the file under /etc/gssproxy and the drop-in file for systemd. The helper script could take a series of users/groups as arguments that would limit access to the socket file or there could be a separate config file that is read from to determine if access to the cifs.sock socket should be limited.

On Fri, Feb 19, 2021 at 12:38 PM Simo Sorce simo@redhat.com wrote:

...

On Fri, 2021-02-19 at 03:30 -0800, Shyam Prasad N wrote:

...

Hi Simo,

...

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

Could you please point me to the documentation for doing this?

I do not know if the kernel documents this, but the way gssproxy works is that when you start the daemon it pokes at the kernel to let it know the socket is available. So then the kernel opens the socket in the namespace the proxy is running into (detected from the poking operation, which is a write in a proc file).

HTH, Simo.

...

Regards, Shyam

On Thu, Dec 17, 2020 at 5:41 AM Simo Sorce simo@redhat.com wrote:

...

Hi Steve,

GSSAPI and krb5 as implemented in system krb5 libraries exists from longer than Samba has implemented those capabilities, I do not think it make sense to reason along those lines.

GSS-Proxy has been built with a protocol to talk from the kernel that resolved a number of issues for knfsd (eg big packet sizes when a MS- PAC is present).

And Samba uses internally exactly the same krb5 mechanism as it defers to the kerberos libraries as well.

Additionally GSS-Proxy can be very easily extended to also do NTLMSSP using the same interface as I have built the gssntlmssp long ago from the MS spec, and is probably the most correct NTLMSSP implementation you can find around.

Gssntlmssp also has a Winbind backend so you get automaticaly access to whatever cached credentials Winbindd has for users as a bonus (although the integration can be improved there), yet you *can* use it w/o Winbindd just fine providing a credential file (smbpasswd format compatible).

GSS-Proxy is already integrated in distributions because it is used by knfsd, and can be as easily used by cifsd, and you *should* really use it there, so we can have a single, consistent, maintained, mechanism for server side GSS authentication, and not have to repeat and reinvent kernel to userspace mechanisms.

And if you add it for cifsd you have yet another reason to do it for cifs.ko as well.

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

For the client we'll need to add some XDR parsing functions in kernel, they were omitted from my original patches because there was no client side kernel consumer back then, but it i an easy, mechanical change.

HTH, Simo.

On Wed, 2020-12-16 at 16:43 -0600, Steve French wrote: > generally I would feel more comfortable using something (library or > utility) in Samba (if needed) for additional SPNEGO support if > something is missing (in what the kernel drivers are doing to > encapsulate Active Directory or Samba AD krb5 tickets in SPNEGO) as > Samba is better maintained/tested etc. than most components. Is there > something in Samba that could be used here instead of having a > dependency on another project - Samba has been doing Kerberos/SPNEGO > longer than most ...? There are probably others (jra, Metze etc.) > that have would know more about gssproxy vs. Samba equivalents though > and would defer to them ... > > On Wed, Dec 16, 2020 at 8:33 AM Simo Sorce simo@redhat.com wrote: > > Hi Michael, > > as you say the best course of action would be for cifs.ko to move to > > use the RPC interface we defined for knfsd (with any extensions that > > may be needed), and we had discussions in the past with cifs upstream > > developers about it. But nothing really materialized. > > > > If something is needed in the short term, I thjink the quickest course > > of action is indeed to change the userspace helper to use gssapi > > function calls, so that they can be intercepted like we do for rpc.gssd > > (nfs client's userspace helper). > > > > Unfortunately I do not have the cycles to work on that myself at this > > time :-( > > > > HTH, > > Simo. > > > > On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote: > > > Hello, > > > > > > I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1]. > > > > > > My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2] > > > > > > From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials. > > > > > > Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]). > > > > > > Assuming my understanding is correct so far: > > > > > > Is anyone doing any work on this and could use some help (testing, coding)? > > > What would be expected complexity and possible roadblocks when trying to make a start at implementing this? > > > Or is the idea moot due to some constraint or recent development I'm not aware of? > > > > > > I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though. > > > > > > As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on. > > > Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)? > > > > > > [1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-... > > > [2] https://pagure.io/gssproxy/issue/56 > > > [3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md > > > [4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server > > > [5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client > > > [6] https://www.spinics.net/lists/linux-cifs/msg20182.html > > > -- > > > Thanks, > > > Michael > > > _______________________________________________ > > > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org > > > To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org > > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or... > > > > -- > > Simo Sorce > > RHEL Crypto Team > > Red Hat, Inc > > > > > > > >

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

Catching up on the email thread. For some reason I missed it originally somehow.

Do we have any more-up-to-date version of the cifs-utils patch other than the one attached to the email thread? I would like to merge the patch into the "next" branch so it makes the next release of cifs-utils.

Also there is a potential helper script mentioned above that is needed to set up gssproxy properly?

-- Best regards, Pavel Shilovsky

вт, 23 февр. 2021 г. в 09:43, Jacob Shivers jshivers@redhat.com:

I have tested the patches for cifs.upcall and can say that with some additional modifications to gssproxy the end setup brings a degree of feature parity to SMB clients that had been previously exclusive to NFS clients. Deployment does require some additional configuration, including the creation of a drop-in file for gssproxy under /etc/gssproxy and for the gssproxy service managed by systemd

### KDC configuration

*** delegation ***

Constrained Delegation (CD) for the SMB host to the Kerberized SMB server Resource Based Constrained Delegation (RBCD) on the Kerberized SMB server to determine which SMB clients can delegate

### SMB client configuration

*** sssd ***

Configuration file modification.

Disable using fully qualified domain names as impersonation does not correctly handle fully qualified names at time of ticket acquisition.

use_fully_qualified_names = False

*** gssproxy ***

Drop file creation

Add a drop file for gssproxy to create the necessary socket and corresponding settings.

# cat /etc/gssproxy/99-cifs-client.conf with contents [service/cifs] mechs = krb5 socket = /var/lib/gssproxy/cifs.sock cred_store = keytab:/etc/krb5.keytab cred_usage = initiate euid = 0 impersonate = yes allow_any_uid = yes

Service drop-in file.

Create a drop-in file to limit socket access for an unattended user, if desired.

# cat /etc/systemd/system/gssproxy.service.d/90-cifs.conf [Service] # Limit cifs.sock socket file accessiblility to just the unattended user. ExecStartPost=/bin/bash -c 'chmod 660 /var/lib/gssproxy/cifs.sock && setfacl -m u:chang:rw /var/lib/gssproxy/cifs.sock'

*** cifs.upcall ***

cifs.spnego.conf modification

Allow for gssprxy to be used and specify socket file

# cat /etc/request-key.d/cifs.spnego.conf create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall %k

include the '-t' flag to allow for accessing a Kerberized DFS namespace using a domain based mount, i.e //example.net/dfs/share

create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall -t %k

The above does allow for unattended users to access a Kerberized SMB share while limiting access to only a specific user:

# mount //win2k16-dfs1.example.net/greendale/ /mnt -o sec=krb5,username='TEST-BOX$@EXAMPLE.NET',multiuser

# su - jeff Last login: Fri Feb 5 12:14:42 EST 2021 on pts/0 [jeff@test-box ~]$ ll /mnt ls: cannot access '/mnt': Permission denied [jeff@test-box ~]$ logout

# su - chang Last login: Fri Feb 5 12:14:46 EST 2021 on pts/0 [chang@test-box ~]$ klist klist: No credentials cache found (filename: /tmp/krb5cc_602001123) [chang@test-box ~]$ ls -l /mnt total 143

drwxr-xr-x. 2 chang domain users 0 Oct 4 2018 DfsrPrivate -rwxr-xr-x. 1 chang domain users 0 Sep 22 10:07 test_file -rwxr-xr-x. 1 chang domain users 0 Dec 14 15:22 whoami drwxr-xr-x. 2 chang domain users 0 Dec 7 12:54 winhome

[chang@test-box ~]$ klist klist: No credentials cache found (filename: /tmp/krb5cc_602001123)

Feb 23 12:22:44.857956 test-box.example.net su[1672]: (to jeff) root on pts/1 Feb 23 12:22:44.866263 test-box.example.net su[1672]: pam_systemd(su-l:session): Cannot create session: Already running in a session or user slice Feb 23 12:22:44.867158 test-box.example.net su[1672]: pam_unix(su-l:session): session opened for user jeff by root(uid=0) Feb 23 12:22:46.253310 test-box.example.net cifs.upcall[1700]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cedc;creduid=0x23e1cedc;pid=0x6a3 Feb 23 12:22:46.253335 test-box.example.net cifs.upcall[1700]: ver=2 Feb 23 12:22:46.253338 test-box.example.net cifs.upcall[1700]: host=win2k16-dfs1.example.net Feb 23 12:22:46.253342 test-box.example.net cifs.upcall[1700]: ip=192.168.124.132 Feb 23 12:22:46.253344 test-box.example.net cifs.upcall[1700]: sec=1 Feb 23 12:22:46.253348 test-box.example.net cifs.upcall[1700]: uid=602001116 Feb 23 12:22:46.253352 test-box.example.net cifs.upcall[1700]: creduid=602001116 Feb 23 12:22:46.253365 test-box.example.net cifs.upcall[1700]: pid=1699 Feb 23 12:22:46.253978 test-box.example.net cifs.upcall[1700]: get_cachename_from_process_env: pathname=/proc/1699/environ Feb 23 12:22:46.254995 test-box.example.net cifs.upcall[1700]: get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001116 Feb 23 12:22:46.255015 test-box.example.net cifs.upcall[1700]: get_tgt_time: unable to get principal Feb 23 12:22:46.255021 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net Feb 23 12:22:46.255024 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: using GSS-API Feb 23 12:22:46.259295 test-box.example.net cifs.upcall[1700]: GSS-API error init_sec_context: Unspecified GSS failure. Minor code may provide more information Feb 23 12:22:46.259306 test-box.example.net cifs.upcall[1700]: GSS-API error init_sec_context: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_602001116) Feb 23 12:22:46.259311 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: failed to obtain service ticket via GSS (851968) Feb 23 12:22:46.259314 test-box.example.net cifs.upcall[1700]: Unable to obtain service ticket Feb 23 12:22:46.259323 test-box.example.net cifs.upcall[1700]: Exit status 851968 Feb 23 12:22:46.262827 test-box.example.net kernel: CIFS VFS: \win2k16-dfs1.example.net Send error in SessSetup = -126 Feb 23 12:22:47.398266 test-box.example.net su[1672]: pam_unix(su-l:session): session closed for user jeff Feb 23 12:22:49.159640 test-box.example.net su[1702]: (to chang) root on pts/1 Feb 23 12:22:49.173264 test-box.example.net su[1702]: pam_systemd(su-l:session): Cannot create session: Already running in a session or user slice Feb 23 12:22:49.173967 test-box.example.net su[1702]: pam_unix(su-l:session): session opened for user chang by root(uid=0) Feb 23 12:22:51.878743 test-box.example.net cifs.upcall[1729]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cee3;creduid=0x23e1cee3;pid=0x6c0 Feb 23 12:22:51.878765 test-box.example.net cifs.upcall[1729]: ver=2 Feb 23 12:22:51.878769 test-box.example.net cifs.upcall[1729]: host=win2k16-dfs1.example.net Feb 23 12:22:51.878773 test-box.example.net cifs.upcall[1729]: ip=192.168.124.132 Feb 23 12:22:51.878776 test-box.example.net cifs.upcall[1729]: sec=1 Feb 23 12:22:51.878780 test-box.example.net cifs.upcall[1729]: uid=602001123 Feb 23 12:22:51.878783 test-box.example.net cifs.upcall[1729]: creduid=602001123 Feb 23 12:22:51.878786 test-box.example.net cifs.upcall[1729]: pid=1728 Feb 23 12:22:51.879060 test-box.example.net cifs.upcall[1729]: get_cachename_from_process_env: pathname=/proc/1728/environ Feb 23 12:22:51.879799 test-box.example.net cifs.upcall[1729]: get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001123 Feb 23 12:22:51.879819 test-box.example.net cifs.upcall[1729]: get_tgt_time: unable to get principal Feb 23 12:22:51.879824 test-box.example.net cifs.upcall[1729]: handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net Feb 23 12:22:51.879827 test-box.example.net cifs.upcall[1729]: handle_krb5_mech: using GSS-API Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [2021/02/23 17:22:51]: Client [2021/02/23 17:22:51]: (/usr/sbin/cifs.upcall) [2021/02/23 17:22:51]: connected (fd = 14)[2021/02/23 17:22:51]: (pid = 1729) (uid = 602001123) (gid = 602000513)[2021/02/23 17:22:51]: (context = system_u:system_r:kernel_t:s0)[> Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:51]: Connection matched service cifs Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:51]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "cifs", euid: 602001123,socket: /var/lib/gssproxy/cifs.sock Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> time_req: 0 desired_mechs: { } cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 ) Feb 23 12:22:52.346639 test-box.example.net gssproxy[1000]: GSSX_RES_ACQUIRE_CRED( status: { 0 { 1 2 840 113554 1 2 2 } 0 "" "" [ ] } output_cred_handle: { "chang@EXAMPLE.NET" [ { "chang@EXAMPLE.NET" { 1 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 } ) Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: Connection matched service cifs Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 602001123,socket: /var/lib/gssproxy/cifs.sock Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: GSSX_ARG_INIT_SEC_CONTEXT( call_ctx: { "" [ ] } context_handle: <Null> cred_handle: { "chang@EXAMPLE.NET" [ { "chang@EXAMPLE.NET" { 1 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 } target_name: "cifs@win2k16-dfs1.example.net" mech> Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: Credentials allowed by configuration Feb 23 12:22:52.357103 test-box.example.net gssproxy[1000]: GSSX_RES_INIT_SEC_CONTEXT( status: { 0 { 1 2 840 113554 1 2 2 } 0 "" "" [ ] } context_handle: { [ ......H............ ] [ ] 0 { 1 2 840 113554 1 2 2 } "chang@EXAMPLE.NET" "cifs/win2k16-dfs1.example.net@EXAMPLE.NET" 36000 432 1 1 } output_token: [ .....> Feb 23 12:22:52.357419 test-box.example.net cifs.upcall[1729]: Exit status 0

Ultimately a helper-script packaged with cifs-utils or a separate package entirely could be responsible for adding the file under /etc/gssproxy and the drop-in file for systemd. The helper script could take a series of users/groups as arguments that would limit access to the socket file or there could be a separate config file that is read from to determine if access to the cifs.sock socket should be limited.

On Fri, Feb 19, 2021 at 12:38 PM Simo Sorce simo@redhat.com wrote:

...

On Fri, 2021-02-19 at 03:30 -0800, Shyam Prasad N wrote:

...

Hi Simo,

...

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

Could you please point me to the documentation for doing this?

I do not know if the kernel documents this, but the way gssproxy works is that when you start the daemon it pokes at the kernel to let it know the socket is available. So then the kernel opens the socket in the namespace the proxy is running into (detected from the poking operation, which is a write in a proc file).

HTH, Simo.

...

Regards, Shyam

On Thu, Dec 17, 2020 at 5:41 AM Simo Sorce simo@redhat.com wrote:

...

Hi Steve,

GSSAPI and krb5 as implemented in system krb5 libraries exists from longer than Samba has implemented those capabilities, I do not think it make sense to reason along those lines.

GSS-Proxy has been built with a protocol to talk from the kernel that resolved a number of issues for knfsd (eg big packet sizes when a MS- PAC is present).

And Samba uses internally exactly the same krb5 mechanism as it defers to the kerberos libraries as well.

Additionally GSS-Proxy can be very easily extended to also do NTLMSSP using the same interface as I have built the gssntlmssp long ago from the MS spec, and is probably the most correct NTLMSSP implementation you can find around.

Gssntlmssp also has a Winbind backend so you get automaticaly access to whatever cached credentials Winbindd has for users as a bonus (although the integration can be improved there), yet you *can* use it w/o Winbindd just fine providing a credential file (smbpasswd format compatible).

GSS-Proxy is already integrated in distributions because it is used by knfsd, and can be as easily used by cifsd, and you *should* really use it there, so we can have a single, consistent, maintained, mechanism for server side GSS authentication, and not have to repeat and reinvent kernel to userspace mechanisms.

And if you add it for cifsd you have yet another reason to do it for cifs.ko as well.

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

For the client we'll need to add some XDR parsing functions in kernel, they were omitted from my original patches because there was no client side kernel consumer back then, but it i an easy, mechanical change.

HTH, Simo.

On Wed, 2020-12-16 at 16:43 -0600, Steve French wrote:

...

generally I would feel more comfortable using something (library or utility) in Samba (if needed) for additional SPNEGO support if something is missing (in what the kernel drivers are doing to encapsulate Active Directory or Samba AD krb5 tickets in SPNEGO) as Samba is better maintained/tested etc. than most components. Is there something in Samba that could be used here instead of having a dependency on another project - Samba has been doing Kerberos/SPNEGO longer than most ...? There are probably others (jra, Metze etc.) that have would know more about gssproxy vs. Samba equivalents though and would defer to them ...

On Wed, Dec 16, 2020 at 8:33 AM Simo Sorce simo@redhat.com wrote:

...

Hi Michael, as you say the best course of action would be for cifs.ko to move to use the RPC interface we defined for knfsd (with any extensions that may be needed), and we had discussions in the past with cifs upstream developers about it. But nothing really materialized.

If something is needed in the short term, I thjink the quickest course of action is indeed to change the userspace helper to use gssapi function calls, so that they can be intercepted like we do for rpc.gssd (nfs client's userspace helper).

Unfortunately I do not have the cycles to work on that myself at this time :-(

HTH, Simo.

On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote: > Hello, > > I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1]. > > My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2] > > From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials. > > Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]). > > Assuming my understanding is correct so far: > > Is anyone doing any work on this and could use some help (testing, coding)? > What would be expected complexity and possible roadblocks when trying to make a start at implementing this? > Or is the idea moot due to some constraint or recent development I'm not aware of? > > I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though. > > As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on. > Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)? > > [1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-... > [2] https://pagure.io/gssproxy/issue/56 > [3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md > [4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server > [5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client > [6] https://www.spinics.net/lists/linux-cifs/msg20182.html > -- > Thanks, > Michael > _______________________________________________ > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org > To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or...

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

Hello Pavel,

Do we have any more-up-to-date version of the cifs-utils patch other than the one attached to the email thread? I would like to merge the patch into the "next" branch so it makes the next release of cifs-utils.

I'm also not aware of a newer version. As one of the initiators of the discussion, who's highly interested in seeing this merged, I'm standing by to help out with background context, testing or improving the code. (The patch was meant as a PoC which is why I skipped some reindenting and niceties to keep its approach and impact easy to gauge.)

Also there is a potential helper script mentioned above that is needed to set up gssproxy properly?

I'm not aware of a helper script. gssproxy just needs to be told about cifs-utils and how it should be treated using a single config drop file. Also in the meantime, Jacob and I have streamlined the configuration so a separate UNIX domain socket and tweaking its permissions using a systemd service drop-in file is no longer needed. Instead, gssproxy can distinguish multiple clients on the same socket using the calling binary derived from getsockopt/SO_PEERCRED.

Finally, environment variable GSS_USE_PROXY needs to be set for cifs.upcall to enable the gssproxy proxy mech. (Instead of using the env command, cifs.upcall could have a command line option similar to rpc.gssd[1] which ends up doing the same thing.)

Here's the config summary:

# cat /etc/request-key.d/cifs.spnego.conf create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes /usr/sbin/cifs.upcall %k

# cat /etc/gssproxy/99-cifs.conf [service/cifs] mechs = krb5 # not needed when program option is used # socket = /var/lib/gssproxy/cifs.sock program = /usr/sbin/cifs.upcall cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab cred_usage = initiate # allow process with any euid to use the service and receive impersonated # tickets for services allow_any_uid = yes # allow euid access to keytab trusted = yes # allow impersonation impersonate = yes # allow process with euid 0 to use the keytab euid = 0

The actual mount can be done using system credentials from the keytab. Small proof session showcasing that gssproxy is involved and working:

# systemctl stop gssproxy # mount -o sec=krb5,multiuser,user=FEDORA33$ //dc/share /mnt # su - adsuser -c "touch /mnt/test" touch: cannot touch '/mnt/test': Permission denied # systemctl start gssproxy # su - adsuser -c "touch /mnt/test" #

[1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/gssd/gssd.c;...

Thanks, Michael

________________________________________ From: Pavel Shilovsky piastryyy@gmail.com Sent: 24 September 2021 19:09:47 To: Jacob Shivers Cc: Simo Sorce; Shyam Prasad N; Steve French; The GSS-Proxy developers and users mailing list; linux-cifs@vger.kernel.org; samba-technical@lists.samba.org Subject: Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.

Catching up on the email thread. For some reason I missed it originally somehow.

Do we have any more-up-to-date version of the cifs-utils patch other than the one attached to the email thread? I would like to merge the patch into the "next" branch so it makes the next release of cifs-utils.

Also there is a potential helper script mentioned above that is needed to set up gssproxy properly?

-- Best regards, Pavel Shilovsky

вт, 23 февр. 2021 г. в 09:43, Jacob Shivers jshivers@redhat.com:

I have tested the patches for cifs.upcall and can say that with some additional modifications to gssproxy the end setup brings a degree of feature parity to SMB clients that had been previously exclusive to NFS clients. Deployment does require some additional configuration, including the creation of a drop-in file for gssproxy under /etc/gssproxy and for the gssproxy service managed by systemd

### KDC configuration

*** delegation ***

Constrained Delegation (CD) for the SMB host to the Kerberized SMB server Resource Based Constrained Delegation (RBCD) on the Kerberized SMB server to determine which SMB clients can delegate

### SMB client configuration

*** sssd ***

Configuration file modification.

Disable using fully qualified domain names as impersonation does not correctly handle fully qualified names at time of ticket acquisition.

use_fully_qualified_names = False

*** gssproxy ***

Drop file creation

Add a drop file for gssproxy to create the necessary socket and corresponding settings.

# cat /etc/gssproxy/99-cifs-client.conf with contents [service/cifs] mechs = krb5 socket = /var/lib/gssproxy/cifs.sock cred_store = keytab:/etc/krb5.keytab cred_usage = initiate euid = 0 impersonate = yes allow_any_uid = yes

Service drop-in file.

Create a drop-in file to limit socket access for an unattended user, if desired.

# cat /etc/systemd/system/gssproxy.service.d/90-cifs.conf [Service] # Limit cifs.sock socket file accessiblility to just the unattended user. ExecStartPost=/bin/bash -c 'chmod 660 /var/lib/gssproxy/cifs.sock && setfacl -m u:chang:rw /var/lib/gssproxy/cifs.sock'

*** cifs.upcall ***

cifs.spnego.conf modification

Allow for gssprxy to be used and specify socket file

# cat /etc/request-key.d/cifs.spnego.conf create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall %k

include the '-t' flag to allow for accessing a Kerberized DFS namespace using a domain based mount, i.e //example.net/dfs/share

create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall -t %k

The above does allow for unattended users to access a Kerberized SMB share while limiting access to only a specific user:

# mount //win2k16-dfs1.example.net/greendale/ /mnt -o sec=krb5,username='TEST-BOX$@EXAMPLE.NET',multiuser

# su - jeff Last login: Fri Feb 5 12:14:42 EST 2021 on pts/0 [jeff@test-box ~]$ ll /mnt ls: cannot access '/mnt': Permission denied [jeff@test-box ~]$ logout

# su - chang Last login: Fri Feb 5 12:14:46 EST 2021 on pts/0 [chang@test-box ~]$ klist klist: No credentials cache found (filename: /tmp/krb5cc_602001123) [chang@test-box ~]$ ls -l /mnt total 143

drwxr-xr-x. 2 chang domain users 0 Oct 4 2018 DfsrPrivate -rwxr-xr-x. 1 chang domain users 0 Sep 22 10:07 test_file -rwxr-xr-x. 1 chang domain users 0 Dec 14 15:22 whoami drwxr-xr-x. 2 chang domain users 0 Dec 7 12:54 winhome

[chang@test-box ~]$ klist klist: No credentials cache found (filename: /tmp/krb5cc_602001123)

Feb 23 12:22:44.857956 test-box.example.net su[1672]: (to jeff) root on pts/1 Feb 23 12:22:44.866263 test-box.example.net su[1672]: pam_systemd(su-l:session): Cannot create session: Already running in a session or user slice Feb 23 12:22:44.867158 test-box.example.net su[1672]: pam_unix(su-l:session): session opened for user jeff by root(uid=0) Feb 23 12:22:46.253310 test-box.example.net cifs.upcall[1700]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cedc;creduid=0x23e1cedc;pid=0x6a3 Feb 23 12:22:46.253335 test-box.example.net cifs.upcall[1700]: ver=2 Feb 23 12:22:46.253338 test-box.example.net cifs.upcall[1700]: host=win2k16-dfs1.example.net Feb 23 12:22:46.253342 test-box.example.net cifs.upcall[1700]: ip=192.168.124.132 Feb 23 12:22:46.253344 test-box.example.net cifs.upcall[1700]: sec=1 Feb 23 12:22:46.253348 test-box.example.net cifs.upcall[1700]: uid=602001116 Feb 23 12:22:46.253352 test-box.example.net cifs.upcall[1700]: creduid=602001116 Feb 23 12:22:46.253365 test-box.example.net cifs.upcall[1700]: pid=1699 Feb 23 12:22:46.253978 test-box.example.net cifs.upcall[1700]: get_cachename_from_process_env: pathname=/proc/1699/environ Feb 23 12:22:46.254995 test-box.example.net cifs.upcall[1700]: get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001116 Feb 23 12:22:46.255015 test-box.example.net cifs.upcall[1700]: get_tgt_time: unable to get principal Feb 23 12:22:46.255021 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net Feb 23 12:22:46.255024 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: using GSS-API Feb 23 12:22:46.259295 test-box.example.net cifs.upcall[1700]: GSS-API error init_sec_context: Unspecified GSS failure. Minor code may provide more information Feb 23 12:22:46.259306 test-box.example.net cifs.upcall[1700]: GSS-API error init_sec_context: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_602001116) Feb 23 12:22:46.259311 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: failed to obtain service ticket via GSS (851968) Feb 23 12:22:46.259314 test-box.example.net cifs.upcall[1700]: Unable to obtain service ticket Feb 23 12:22:46.259323 test-box.example.net cifs.upcall[1700]: Exit status 851968 Feb 23 12:22:46.262827 test-box.example.net kernel: CIFS VFS: \win2k16-dfs1.example.net Send error in SessSetup = -126 Feb 23 12:22:47.398266 test-box.example.net su[1672]: pam_unix(su-l:session): session closed for user jeff Feb 23 12:22:49.159640 test-box.example.net su[1702]: (to chang) root on pts/1 Feb 23 12:22:49.173264 test-box.example.net su[1702]: pam_systemd(su-l:session): Cannot create session: Already running in a session or user slice Feb 23 12:22:49.173967 test-box.example.net su[1702]: pam_unix(su-l:session): session opened for user chang by root(uid=0) Feb 23 12:22:51.878743 test-box.example.net cifs.upcall[1729]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cee3;creduid=0x23e1cee3;pid=0x6c0 Feb 23 12:22:51.878765 test-box.example.net cifs.upcall[1729]: ver=2 Feb 23 12:22:51.878769 test-box.example.net cifs.upcall[1729]: host=win2k16-dfs1.example.net Feb 23 12:22:51.878773 test-box.example.net cifs.upcall[1729]: ip=192.168.124.132 Feb 23 12:22:51.878776 test-box.example.net cifs.upcall[1729]: sec=1 Feb 23 12:22:51.878780 test-box.example.net cifs.upcall[1729]: uid=602001123 Feb 23 12:22:51.878783 test-box.example.net cifs.upcall[1729]: creduid=602001123 Feb 23 12:22:51.878786 test-box.example.net cifs.upcall[1729]: pid=1728 Feb 23 12:22:51.879060 test-box.example.net cifs.upcall[1729]: get_cachename_from_process_env: pathname=/proc/1728/environ Feb 23 12:22:51.879799 test-box.example.net cifs.upcall[1729]: get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001123 Feb 23 12:22:51.879819 test-box.example.net cifs.upcall[1729]: get_tgt_time: unable to get principal Feb 23 12:22:51.879824 test-box.example.net cifs.upcall[1729]: handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net Feb 23 12:22:51.879827 test-box.example.net cifs.upcall[1729]: handle_krb5_mech: using GSS-API Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [2021/02/23 17:22:51]: Client [2021/02/23 17:22:51]: (/usr/sbin/cifs.upcall) [2021/02/23 17:22:51]: connected (fd = 14)[2021/02/23 17:22:51]: (pid = 1729) (uid = 602001123) (gid = 602000513)[2021/02/23 17:22:51]: (context = system_u:system_r:kernel_t:s0)[> Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:51]: Connection matched service cifs Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:51]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "cifs", euid: 602001123,socket: /var/lib/gssproxy/cifs.sock Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> time_req: 0 desired_mechs: { } cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 ) Feb 23 12:22:52.346639 test-box.example.net gssproxy[1000]: GSSX_RES_ACQUIRE_CRED( status: { 0 { 1 2 840 113554 1 2 2 } 0 "" "" [ ] } output_cred_handle: { "chang@EXAMPLE.NET" [ { "chang@EXAMPLE.NET" { 1 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 } ) Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: Connection matched service cifs Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 602001123,socket: /var/lib/gssproxy/cifs.sock Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: GSSX_ARG_INIT_SEC_CONTEXT( call_ctx: { "" [ ] } context_handle: <Null> cred_handle: { "chang@EXAMPLE.NET" [ { "chang@EXAMPLE.NET" { 1 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 } target_name: "cifs@win2k16-dfs1.example.net" mech> Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: Credentials allowed by configuration Feb 23 12:22:52.357103 test-box.example.net gssproxy[1000]: GSSX_RES_INIT_SEC_CONTEXT( status: { 0 { 1 2 840 113554 1 2 2 } 0 "" "" [ ] } context_handle: { [ ......H............ ] [ ] 0 { 1 2 840 113554 1 2 2 } "chang@EXAMPLE.NET" "cifs/win2k16-dfs1.example.net@EXAMPLE.NET" 36000 432 1 1 } output_token: [ .....> Feb 23 12:22:52.357419 test-box.example.net cifs.upcall[1729]: Exit status 0

Ultimately a helper-script packaged with cifs-utils or a separate package entirely could be responsible for adding the file under /etc/gssproxy and the drop-in file for systemd. The helper script could take a series of users/groups as arguments that would limit access to the socket file or there could be a separate config file that is read from to determine if access to the cifs.sock socket should be limited.

On Fri, Feb 19, 2021 at 12:38 PM Simo Sorce simo@redhat.com wrote:

...

On Fri, 2021-02-19 at 03:30 -0800, Shyam Prasad N wrote:

...

Hi Simo,

...

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

Could you please point me to the documentation for doing this?

I do not know if the kernel documents this, but the way gssproxy works is that when you start the daemon it pokes at the kernel to let it know the socket is available. So then the kernel opens the socket in the namespace the proxy is running into (detected from the poking operation, which is a write in a proc file).

HTH, Simo.

...

Regards, Shyam

On Thu, Dec 17, 2020 at 5:41 AM Simo Sorce simo@redhat.com wrote:

...

Hi Steve,

GSSAPI and krb5 as implemented in system krb5 libraries exists from longer than Samba has implemented those capabilities, I do not think it make sense to reason along those lines.

GSS-Proxy has been built with a protocol to talk from the kernel that resolved a number of issues for knfsd (eg big packet sizes when a MS- PAC is present).

And Samba uses internally exactly the same krb5 mechanism as it defers to the kerberos libraries as well.

Additionally GSS-Proxy can be very easily extended to also do NTLMSSP using the same interface as I have built the gssntlmssp long ago from the MS spec, and is probably the most correct NTLMSSP implementation you can find around.

Gssntlmssp also has a Winbind backend so you get automaticaly access to whatever cached credentials Winbindd has for users as a bonus (although the integration can be improved there), yet you *can* use it w/o Winbindd just fine providing a credential file (smbpasswd format compatible).

GSS-Proxy is already integrated in distributions because it is used by knfsd, and can be as easily used by cifsd, and you *should* really use it there, so we can have a single, consistent, maintained, mechanism for server side GSS authentication, and not have to repeat and reinvent kernel to userspace mechanisms.

And if you add it for cifsd you have yet another reason to do it for cifs.ko as well.

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

For the client we'll need to add some XDR parsing functions in kernel, they were omitted from my original patches because there was no client side kernel consumer back then, but it i an easy, mechanical change.

HTH, Simo.

On Wed, 2020-12-16 at 16:43 -0600, Steve French wrote:

...

generally I would feel more comfortable using something (library or utility) in Samba (if needed) for additional SPNEGO support if something is missing (in what the kernel drivers are doing to encapsulate Active Directory or Samba AD krb5 tickets in SPNEGO) as Samba is better maintained/tested etc. than most components. Is there something in Samba that could be used here instead of having a dependency on another project - Samba has been doing Kerberos/SPNEGO longer than most ...? There are probably others (jra, Metze etc.) that have would know more about gssproxy vs. Samba equivalents though and would defer to them ...

On Wed, Dec 16, 2020 at 8:33 AM Simo Sorce simo@redhat.com wrote:

...

Hi Michael, as you say the best course of action would be for cifs.ko to move to use the RPC interface we defined for knfsd (with any extensions that may be needed), and we had discussions in the past with cifs upstream developers about it. But nothing really materialized.

If something is needed in the short term, I thjink the quickest course of action is indeed to change the userspace helper to use gssapi function calls, so that they can be intercepted like we do for rpc.gssd (nfs client's userspace helper).

Unfortunately I do not have the cycles to work on that myself at this time :-(

HTH, Simo.

On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote: > Hello, > > I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1]. > > My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2] > > From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials. > > Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]). > > Assuming my understanding is correct so far: > > Is anyone doing any work on this and could use some help (testing, coding)? > What would be expected complexity and possible roadblocks when trying to make a start at implementing this? > Or is the idea moot due to some constraint or recent development I'm not aware of? > > I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though. > > As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on. > Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)? > > [1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-... > [2] https://pagure.io/gssproxy/issue/56 > [3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md > [4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server > [5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client > [6] https://www.spinics.net/lists/linux-cifs/msg20182.html > -- > Thanks, > Michael > _______________________________________________ > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org > To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or...

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

Hello Michael, Jacob,

The cifs.upcall patch is applied with some minor adjustments (code style and a patch description) on top of the next branch on github:

https://github.com/piastry/cifs-utils/commit/3d681bb5c140376ccc19e48711231ae...

Please let me know if it looks good and/or if you have other suggestions.

The only concern that I have is the compile warning below. Would appreciate it if you provide a fix for that.

gcc -DHAVE_CONFIG_H -I. -Wall -Wextra -D_FORTIFY_SOURCE=2 -fpie -pie -Wl,-z,relro,-z,now -g -O2 -MT cifs.upcall.o -MD -MP -MF .deps/cifs.upcall.Tpo -c -o cifs.upcall.o cifs.upcall.c cifs.upcall.c: In function ‘cifs_gss_get_req’: cifs.upcall.c:808:4: warning: passing argument 5 of ‘gss_init_sec_context’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] gss_mech_krb5, /* force krb5 */ ^ In file included from /usr/include/gssapi/gssapi_generic.h:31:0, from cifs.upcall.c:40: /usr/include/gssapi/gssapi.h:437:1: note: expected ‘gss_OID {aka struct gss_OID_desc_struct *}’ but argument is of type ‘const gss_OID_desc * const {aka const struct gss_OID_desc_struct * const}’ gss_init_sec_context( ^ mv -f .deps/cifs.upcall.Tpo .deps/cifs.upcall.Po gcc -Wall -Wextra -D_FORTIFY_SOURCE=2 -fpie -pie -Wl,-z,relro,-z,now -g -O2 -o cifs.upcall cifs.upcall.o data_blob.o asn1.o spnego.o -ltalloc -lkeyutils -lgssapi_krb5 -lkrb5

-- Best regards, Pavel Shilovsky

чт, 30 сент. 2021 г. в 16:18, Jacob Shivers jshivers@redhat.com:

Hello Pavel/Michael,

The only other addition would be to modify /etc/gssproxy/99-nfs-client.conf to also use the 'program' directive, i.e. 'program = /usr/sbin/rpc.gssd' so that both rpc.gssd and cifs.upcall can make use of the default gssproxy socket '/var/lib/gssproxy/default.sock'

If the 'program' directive is not included in the respective drop files, then gssproxy can not differentiate which service is to be used and will fail to start.

In total, a gssproxy drop file for cifs.upcall, modifying the gssproxy drop file for rpc.gssd, and an inclusion of a parameter that sets an environmental variable for cifs.upcall to use gssproxy should be all that is needed. I had not submitted a pull request for gssproxy yet as the extended cifs.upcall functionality had not received any further feedback. I can submit something if you are ready to include the patch to cifs.upcall

Thanks,

Jacob Shivers

On Mon, Sep 27, 2021 at 3:20 AM Weiser, Michael michael.weiser@atos.net wrote:

...

Hello Pavel,

...

Do we have any more-up-to-date version of the cifs-utils patch other than the one attached to the email thread? I would like to merge the patch into the "next" branch so it makes the next release of cifs-utils.

I'm also not aware of a newer version. As one of the initiators of the discussion, who's highly interested in seeing this merged, I'm standing by to help out with background context, testing or improving the code. (The patch was meant as a PoC which is why I skipped some reindenting and niceties to keep its approach and impact easy to gauge.)

...

Also there is a potential helper script mentioned above that is needed to set up gssproxy properly?

I'm not aware of a helper script. gssproxy just needs to be told about cifs-utils and how it should be treated using a single config drop file. Also in the meantime, Jacob and I have streamlined the configuration so a separate UNIX domain socket and tweaking its permissions using a systemd service drop-in file is no longer needed. Instead, gssproxy can distinguish multiple clients on the same socket using the calling binary derived from getsockopt/SO_PEERCRED.

Finally, environment variable GSS_USE_PROXY needs to be set for cifs.upcall to enable the gssproxy proxy mech. (Instead of using the env command, cifs.upcall could have a command line option similar to rpc.gssd[1] which ends up doing the same thing.)

Here's the config summary:

# cat /etc/request-key.d/cifs.spnego.conf create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes /usr/sbin/cifs.upcall %k

# cat /etc/gssproxy/99-cifs.conf [service/cifs] mechs = krb5 # not needed when program option is used # socket = /var/lib/gssproxy/cifs.sock program = /usr/sbin/cifs.upcall cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab cred_usage = initiate # allow process with any euid to use the service and receive impersonated # tickets for services allow_any_uid = yes # allow euid access to keytab trusted = yes # allow impersonation impersonate = yes # allow process with euid 0 to use the keytab euid = 0

The actual mount can be done using system credentials from the keytab. Small proof session showcasing that gssproxy is involved and working:

# systemctl stop gssproxy # mount -o sec=krb5,multiuser,user=FEDORA33$ //dc/share /mnt # su - adsuser -c "touch /mnt/test" touch: cannot touch '/mnt/test': Permission denied # systemctl start gssproxy # su - adsuser -c "touch /mnt/test" #

[1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/gssd/gssd.c;...

Thanks, Michael

---

From: Pavel Shilovsky piastryyy@gmail.com Sent: 24 September 2021 19:09:47 To: Jacob Shivers Cc: Simo Sorce; Shyam Prasad N; Steve French; The GSS-Proxy developers and users mailing list; linux-cifs@vger.kernel.org; samba-technical@lists.samba.org Subject: Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.

Catching up on the email thread. For some reason I missed it originally somehow.

Do we have any more-up-to-date version of the cifs-utils patch other than the one attached to the email thread? I would like to merge the patch into the "next" branch so it makes the next release of cifs-utils.

Also there is a potential helper script mentioned above that is needed to set up gssproxy properly?

-- Best regards, Pavel Shilovsky

вт, 23 февр. 2021 г. в 09:43, Jacob Shivers jshivers@redhat.com:

...

I have tested the patches for cifs.upcall and can say that with some additional modifications to gssproxy the end setup brings a degree of feature parity to SMB clients that had been previously exclusive to NFS clients. Deployment does require some additional configuration, including the creation of a drop-in file for gssproxy under /etc/gssproxy and for the gssproxy service managed by systemd

### KDC configuration

*** delegation ***

Constrained Delegation (CD) for the SMB host to the Kerberized SMB server Resource Based Constrained Delegation (RBCD) on the Kerberized SMB server to determine which SMB clients can delegate

### SMB client configuration

*** sssd ***

Configuration file modification.

Disable using fully qualified domain names as impersonation does not correctly handle fully qualified names at time of ticket acquisition.

use_fully_qualified_names = False

*** gssproxy ***

Drop file creation

Add a drop file for gssproxy to create the necessary socket and corresponding settings.

# cat /etc/gssproxy/99-cifs-client.conf with contents [service/cifs] mechs = krb5 socket = /var/lib/gssproxy/cifs.sock cred_store = keytab:/etc/krb5.keytab cred_usage = initiate euid = 0 impersonate = yes allow_any_uid = yes

Service drop-in file.

Create a drop-in file to limit socket access for an unattended user, if desired.

# cat /etc/systemd/system/gssproxy.service.d/90-cifs.conf [Service] # Limit cifs.sock socket file accessiblility to just the unattended user. ExecStartPost=/bin/bash -c 'chmod 660 /var/lib/gssproxy/cifs.sock && setfacl -m u:chang:rw /var/lib/gssproxy/cifs.sock'

*** cifs.upcall ***

cifs.spnego.conf modification

Allow for gssprxy to be used and specify socket file

# cat /etc/request-key.d/cifs.spnego.conf create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall %k

include the '-t' flag to allow for accessing a Kerberized DFS namespace using a domain based mount, i.e //example.net/dfs/share

create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall -t %k

The above does allow for unattended users to access a Kerberized SMB share while limiting access to only a specific user:

# mount //win2k16-dfs1.example.net/greendale/ /mnt -o sec=krb5,username='TEST-BOX$@EXAMPLE.NET',multiuser

# su - jeff Last login: Fri Feb 5 12:14:42 EST 2021 on pts/0 [jeff@test-box ~]$ ll /mnt ls: cannot access '/mnt': Permission denied [jeff@test-box ~]$ logout

# su - chang Last login: Fri Feb 5 12:14:46 EST 2021 on pts/0 [chang@test-box ~]$ klist klist: No credentials cache found (filename: /tmp/krb5cc_602001123) [chang@test-box ~]$ ls -l /mnt total 143

drwxr-xr-x. 2 chang domain users 0 Oct 4 2018 DfsrPrivate -rwxr-xr-x. 1 chang domain users 0 Sep 22 10:07 test_file -rwxr-xr-x. 1 chang domain users 0 Dec 14 15:22 whoami drwxr-xr-x. 2 chang domain users 0 Dec 7 12:54 winhome

[chang@test-box ~]$ klist klist: No credentials cache found (filename: /tmp/krb5cc_602001123)

Feb 23 12:22:44.857956 test-box.example.net su[1672]: (to jeff) root on pts/1 Feb 23 12:22:44.866263 test-box.example.net su[1672]: pam_systemd(su-l:session): Cannot create session: Already running in a session or user slice Feb 23 12:22:44.867158 test-box.example.net su[1672]: pam_unix(su-l:session): session opened for user jeff by root(uid=0) Feb 23 12:22:46.253310 test-box.example.net cifs.upcall[1700]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cedc;creduid=0x23e1cedc;pid=0x6a3 Feb 23 12:22:46.253335 test-box.example.net cifs.upcall[1700]: ver=2 Feb 23 12:22:46.253338 test-box.example.net cifs.upcall[1700]: host=win2k16-dfs1.example.net Feb 23 12:22:46.253342 test-box.example.net cifs.upcall[1700]: ip=192.168.124.132 Feb 23 12:22:46.253344 test-box.example.net cifs.upcall[1700]: sec=1 Feb 23 12:22:46.253348 test-box.example.net cifs.upcall[1700]: uid=602001116 Feb 23 12:22:46.253352 test-box.example.net cifs.upcall[1700]: creduid=602001116 Feb 23 12:22:46.253365 test-box.example.net cifs.upcall[1700]: pid=1699 Feb 23 12:22:46.253978 test-box.example.net cifs.upcall[1700]: get_cachename_from_process_env: pathname=/proc/1699/environ Feb 23 12:22:46.254995 test-box.example.net cifs.upcall[1700]: get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001116 Feb 23 12:22:46.255015 test-box.example.net cifs.upcall[1700]: get_tgt_time: unable to get principal Feb 23 12:22:46.255021 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net Feb 23 12:22:46.255024 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: using GSS-API Feb 23 12:22:46.259295 test-box.example.net cifs.upcall[1700]: GSS-API error init_sec_context: Unspecified GSS failure. Minor code may provide more information Feb 23 12:22:46.259306 test-box.example.net cifs.upcall[1700]: GSS-API error init_sec_context: No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_602001116) Feb 23 12:22:46.259311 test-box.example.net cifs.upcall[1700]: handle_krb5_mech: failed to obtain service ticket via GSS (851968) Feb 23 12:22:46.259314 test-box.example.net cifs.upcall[1700]: Unable to obtain service ticket Feb 23 12:22:46.259323 test-box.example.net cifs.upcall[1700]: Exit status 851968 Feb 23 12:22:46.262827 test-box.example.net kernel: CIFS VFS: \win2k16-dfs1.example.net Send error in SessSetup = -126 Feb 23 12:22:47.398266 test-box.example.net su[1672]: pam_unix(su-l:session): session closed for user jeff Feb 23 12:22:49.159640 test-box.example.net su[1702]: (to chang) root on pts/1 Feb 23 12:22:49.173264 test-box.example.net su[1702]: pam_systemd(su-l:session): Cannot create session: Already running in a session or user slice Feb 23 12:22:49.173967 test-box.example.net su[1702]: pam_unix(su-l:session): session opened for user chang by root(uid=0) Feb 23 12:22:51.878743 test-box.example.net cifs.upcall[1729]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cee3;creduid=0x23e1cee3;pid=0x6c0 Feb 23 12:22:51.878765 test-box.example.net cifs.upcall[1729]: ver=2 Feb 23 12:22:51.878769 test-box.example.net cifs.upcall[1729]: host=win2k16-dfs1.example.net Feb 23 12:22:51.878773 test-box.example.net cifs.upcall[1729]: ip=192.168.124.132 Feb 23 12:22:51.878776 test-box.example.net cifs.upcall[1729]: sec=1 Feb 23 12:22:51.878780 test-box.example.net cifs.upcall[1729]: uid=602001123 Feb 23 12:22:51.878783 test-box.example.net cifs.upcall[1729]: creduid=602001123 Feb 23 12:22:51.878786 test-box.example.net cifs.upcall[1729]: pid=1728 Feb 23 12:22:51.879060 test-box.example.net cifs.upcall[1729]: get_cachename_from_process_env: pathname=/proc/1728/environ Feb 23 12:22:51.879799 test-box.example.net cifs.upcall[1729]: get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001123 Feb 23 12:22:51.879819 test-box.example.net cifs.upcall[1729]: get_tgt_time: unable to get principal Feb 23 12:22:51.879824 test-box.example.net cifs.upcall[1729]: handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net Feb 23 12:22:51.879827 test-box.example.net cifs.upcall[1729]: handle_krb5_mech: using GSS-API Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [2021/02/23 17:22:51]: Client [2021/02/23 17:22:51]: (/usr/sbin/cifs.upcall) [2021/02/23 17:22:51]: connected (fd = 14)[2021/02/23 17:22:51]: (pid = 1729) (uid = 602001123) (gid = 602000513)[2021/02/23 17:22:51]: (context = system_u:system_r:kernel_t:s0)[> Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:51]: Connection matched service cifs Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:51]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "cifs", euid: 602001123,socket: /var/lib/gssproxy/cifs.sock Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> time_req: 0 desired_mechs: { } cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 ) Feb 23 12:22:52.346639 test-box.example.net gssproxy[1000]: GSSX_RES_ACQUIRE_CRED( status: { 0 { 1 2 840 113554 1 2 2 } 0 "" "" [ ] } output_cred_handle: { "chang@EXAMPLE.NET" [ { "chang@EXAMPLE.NET" { 1 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 } ) Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: Connection matched service cifs Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 602001123,socket: /var/lib/gssproxy/cifs.sock Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: GSSX_ARG_INIT_SEC_CONTEXT( call_ctx: { "" [ ] } context_handle: <Null> cred_handle: { "chang@EXAMPLE.NET" [ { "chang@EXAMPLE.NET" { 1 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 } target_name: "cifs@win2k16-dfs1.example.net" mech> Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID 14][2021/02/23 17:22:52]: Credentials allowed by configuration Feb 23 12:22:52.357103 test-box.example.net gssproxy[1000]: GSSX_RES_INIT_SEC_CONTEXT( status: { 0 { 1 2 840 113554 1 2 2 } 0 "" "" [ ] } context_handle: { [ ......H............ ] [ ] 0 { 1 2 840 113554 1 2 2 } "chang@EXAMPLE.NET" "cifs/win2k16-dfs1.example.net@EXAMPLE.NET" 36000 432 1 1 } output_token: [ .....> Feb 23 12:22:52.357419 test-box.example.net cifs.upcall[1729]: Exit status 0

Ultimately a helper-script packaged with cifs-utils or a separate package entirely could be responsible for adding the file under /etc/gssproxy and the drop-in file for systemd. The helper script could take a series of users/groups as arguments that would limit access to the socket file or there could be a separate config file that is read from to determine if access to the cifs.sock socket should be limited.

On Fri, Feb 19, 2021 at 12:38 PM Simo Sorce simo@redhat.com wrote:

...

On Fri, 2021-02-19 at 03:30 -0800, Shyam Prasad N wrote:

...

Hi Simo,

...

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

Could you please point me to the documentation for doing this?

I do not know if the kernel documents this, but the way gssproxy works is that when you start the daemon it pokes at the kernel to let it know the socket is available. So then the kernel opens the socket in the namespace the proxy is running into (detected from the poking operation, which is a write in a proc file).

HTH, Simo.

...

Regards, Shyam

On Thu, Dec 17, 2020 at 5:41 AM Simo Sorce simo@redhat.com wrote:

...

Hi Steve,

GSSAPI and krb5 as implemented in system krb5 libraries exists from longer than Samba has implemented those capabilities, I do not think it make sense to reason along those lines.

GSS-Proxy has been built with a protocol to talk from the kernel that resolved a number of issues for knfsd (eg big packet sizes when a MS- PAC is present).

And Samba uses internally exactly the same krb5 mechanism as it defers to the kerberos libraries as well.

Additionally GSS-Proxy can be very easily extended to also do NTLMSSP using the same interface as I have built the gssntlmssp long ago from the MS spec, and is probably the most correct NTLMSSP implementation you can find around.

Gssntlmssp also has a Winbind backend so you get automaticaly access to whatever cached credentials Winbindd has for users as a bonus (although the integration can be improved there), yet you *can* use it w/o Winbindd just fine providing a credential file (smbpasswd format compatible).

GSS-Proxy is already integrated in distributions because it is used by knfsd, and can be as easily used by cifsd, and you *should* really use it there, so we can have a single, consistent, maintained, mechanism for server side GSS authentication, and not have to repeat and reinvent kernel to userspace mechanisms.

And if you add it for cifsd you have yet another reason to do it for cifs.ko as well.

Finally the GSS-Proxy mechanism is namespace compatible, so you also get the ability to define different auth daemons per different containers, no need to invent new mechanisms for that or change yet again protocols/userspace to obtain container capabilities.

For the client we'll need to add some XDR parsing functions in kernel, they were omitted from my original patches because there was no client side kernel consumer back then, but it i an easy, mechanical change.

HTH, Simo.

On Wed, 2020-12-16 at 16:43 -0600, Steve French wrote: > generally I would feel more comfortable using something (library or > utility) in Samba (if needed) for additional SPNEGO support if > something is missing (in what the kernel drivers are doing to > encapsulate Active Directory or Samba AD krb5 tickets in SPNEGO) as > Samba is better maintained/tested etc. than most components. Is there > something in Samba that could be used here instead of having a > dependency on another project - Samba has been doing Kerberos/SPNEGO > longer than most ...? There are probably others (jra, Metze etc.) > that have would know more about gssproxy vs. Samba equivalents though > and would defer to them ... > > On Wed, Dec 16, 2020 at 8:33 AM Simo Sorce simo@redhat.com wrote: > > Hi Michael, > > as you say the best course of action would be for cifs.ko to move to > > use the RPC interface we defined for knfsd (with any extensions that > > may be needed), and we had discussions in the past with cifs upstream > > developers about it. But nothing really materialized. > > > > If something is needed in the short term, I thjink the quickest course > > of action is indeed to change the userspace helper to use gssapi > > function calls, so that they can be intercepted like we do for rpc.gssd > > (nfs client's userspace helper). > > > > Unfortunately I do not have the cycles to work on that myself at this > > time :-( > > > > HTH, > > Simo. > > > > On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote: > > > Hello, > > > > > > I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1]. > > > > > > My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2] > > > > > > From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials. > > > > > > Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]). > > > > > > Assuming my understanding is correct so far: > > > > > > Is anyone doing any work on this and could use some help (testing, coding)? > > > What would be expected complexity and possible roadblocks when trying to make a start at implementing this? > > > Or is the idea moot due to some constraint or recent development I'm not aware of? > > > > > > I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though. > > > > > > As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on. > > > Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)? > > > > > > [1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-... > > > [2] https://pagure.io/gssproxy/issue/56 > > > [3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md > > > [4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server > > > [5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client > > > [6] https://www.spinics.net/lists/linux-cifs/msg20182.html > > > -- > > > Thanks, > > > Michael > > > _______________________________________________ > > > gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org > > > To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org > > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or... > > > > -- > > Simo Sorce > > RHEL Crypto Team > > Red Hat, Inc > > > > > > > >

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

Hi Michael,

What happens when credentials are not supplied in keytab files? Is there a way to supply the credentials from other sources in that case? The reason why I'm asking this is that this same code can be used by cifscreds (or a new executable) to perform the authentication, and collect the krb5 tickets.

Also, in the cifs.upcall changes, you could check for the GSS_USE_PROXY env variable. In the absence of which, fallback to the older code. If that is done, it gives the user an option to go for one option or the other. Other than that, the changes look fine to me.

Regards, Shyam

On Thu, Jan 7, 2021 at 3:08 AM Weiser, Michael michael.weiser@atos.net wrote:

Hello Simo, Hello Steve,

...

If something is needed in the short term, I thjink the quickest course of action is indeed to change the userspace helper to use gssapi function calls, so that they can be intercepted like we do for rpc.gssd (nfs client's userspace helper).

To get the ball rolling and give people (including myself and client) something to play with I went that route and extended cifs.upcall to fall back to GSS-API if no ticket cache nor keytab can be found for the user. An unpolished PoC patch is attached. (Sorry, for not putting it inline, have to rock the groupware at work. I will try to sort that once we've agreed this is the/a way to go.)

With that patch applied, I can do a multiuser cifs mount using the system keytab and machine identity as usual and then have users access the mount using impersonated credentials from gssproxy. Quick demo:

[root@fedora33 ~]# umount /mnt [root@fedora33 ~]# mount -o sec=krb5,multiuser,user=FEDORA33$ //dc/share /mnt [root@fedora33 ~]# ls -la /mnt total 0 drwxr-xr-x. 2 root root 0 Jan 7 10:20 . dr-xr-xr-x. 18 root root 238 Jan 6 13:59 .. -rwxr-xr-x. 1 root root 0 Jan 5 17:02 bar [root@fedora33 ~]# klist klist: Credentials cache keyring 'persistent:0:krb_ccache_WZh7W8n' not found [root@fedora33 ~]#

[adsuser@fedora33 ~]$ kdestroy [adsuser@fedora33 ~]$ echo test > /mnt/test [adsuser@fedora33 ~]$ cat /mnt/test test [adsuser@fedora33 ~]$ klist klist: Credentials cache keyring 'persistent:1618201110:krb_ccache_SrGqT3F' not found [adsuser@fedora33 ~]$

Server-side permissions are enforced:

[m@fedora33 ~]$ cat /mnt/test test [m@fedora33 ~]$ echo mytest > /mnt/test -bash: /mnt/test: Permission denied [m@fedora33 ~]$ klist klist: Credentials cache keyring 'persistent:1000:1000' not found [m@fedora33 ~]$

The gssproxy config for this configures a cifs-specific socket and enables impersonation for any user id:

[root@fedora33 ~]# cat /etc/gssproxy/99-cifs.conf [service/cifs] mechs = krb5 socket = /var/lib/gssproxy/cifs.sock cred_store = keytab:/etc/krb5.keytab cred_usage = initiate euid = 0 impersonate = yes allow_any_uid = yes

And request-key config for cifs.spnego enables use of gssproxy and the service-specific socket through environment variables:

[root@fedora33 ~]# cat /etc/request-key.d/cifs.spnego.conf create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall %k

(I see that nfs-utils' gssd does the same by setting the variables itself based on command line options. That could easily be done here as well.)

User FEDORA33$ (the computer object) needs to be enabled for delegation to service cifs. I've tested with a Fedora 33 client and Windows 2016 Active Directory server.

The patch is against current cifs-utils HEAD. It is lacking all the autoconf trimmings and intentionally forgoes reindents of existing code for clarity of what's being touched.

What do you think?

...

Unfortunately I do not have the cycles to work on that myself at this time :-(

I have a client in very tangible need of this functionality who is a RedHat customer. Would it be helpful if they were to open a case with Redhat on this?

As an extension the above (but not to distract from the focus of getting something to work at all first):

I rather accidentally also played around with delegating retrieval of the mount credentials into gssproxy as well (due to not realising that username=FEDORA33$ would just activate the keytab codepath in cifs.upcall).

This can be done by leaving out the username from the mount command, marking euid 0 as trusted for access to the keytab in gssproxy and adding a fallback principal to the gssproxy config (because cifs.upcall in this case does not submit a desired name for the credential):

[root@fedora33 ~]# mount -o sec=krb5,multiuser //dc/share /mnt [root@fedora33 ~]# cat /etc/gssproxy/99-cifs.conf [service/cifs] mechs = krb5 socket = /var/lib/gssproxy/cifs.sock cred_store = keytab:/etc/krb5.keytab cred_usage = initiate euid = 0 trusted = yes impersonate = yes krb5_principal = cifs-mount allow_any_uid = yes

While this works, it requires a separate user who would then carefully need to be kept out of any sensitive file access groups.

When trying to use the machine identity FEDORA33$ instead, I ran into a peculiar error from the AD KDC:

[root@fedora33 ~]# cat /etc/gssproxy/99-cifs.conf [service/cifs] mechs = krb5 socket = /var/lib/gssproxy/cifs.sock cred_store = keytab:/etc/krb5.keytab cred_usage = initiate euid = 0 trusted = yes impersonate = yes krb5_principal = FEDORA33$ allow_any_uid = yes [root@fedora33 ~]# gssproxy -i -d & [2] 3814 [root@fedora33 ~]# [2021/01/07 10:01:10]: Debug Enabled (level: 1) [2021/01/07 10:01:10]: Service: nfs-server, Keytab: /etc/krb5.keytab, Enctype: 17 [2021/01/07 10:01:10]: Service: cifs, Keytab: /etc/krb5.keytab, Enctype: 17 [2021/01/07 10:01:10]: Service: nfs-client, Keytab: /etc/krb5.keytab, Enctype: 17 [2021/01/07 10:01:10]: Client [2021/01/07 10:01:10]: (/usr/sbin/gssproxy) [2021/01/07 10:01:10]: connected (fd = 11)[2021/01/07 10:01:10]: (pid = 3814) (uid = 0) (gid = 0)[2021/01/07 10:01:10]: (context = system_u:system_r:kernel_t:s0)[2021/01/07 10:01:10]:

[root@fedora33 ~]# mount -o sec=krb5,multiuser //dc/share /mnt [2021/01/07 10:01:13]: Client [2021/01/07 10:01:13]: (/usr/sbin/cifs.upcall) [2021/01/07 10:01:13]: connected (fd = 12)[2021/01/07 10:01:13]: (pid = 3824) (uid = 0) (gid = 0)[2021/01/07 10:01:13]: (context = system_u:system_r:kernel_t:s0)[2021/01/07 10:01:13]: [CID 12][2021/01/07 10:01:13]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "cifs", euid: 0,socket: /var/lib/gssproxy/cifs.sock gssproxy[3814]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, KDC has no support for padata type [CID 12][2021/01/07 10:01:13]: gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 0,socket: /var/lib/gssproxy/cifs.sock gssproxy[3814]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, KDC has no support for padata type [CID 12][2021/01/07 10:01:13]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "cifs", euid: 0,socket: /var/lib/gssproxy/cifs.sock gssproxy[3814]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, KDC has no support for padata type [CID 12][2021/01/07 10:01:13]: gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 0,socket: /var/lib/gssproxy/cifs.sock gssproxy[3814]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, KDC has no support for padata type mount error(126): Required key not available Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

With more debugging it appears that gssproxy tries to impersonate user FEDORA33$ with a credential which is also for FEDORA33$. After further testing it seems this is generally not allowed or just not working due to never being tested because it is unnecessary: If we can acquire a impersonation credential for that identity we should also be able to get the actual access credential as well.

From looking at the nfs-utils gssd code it appears the only reason it hasn't run into this case yet is because it handles the machine credentials itself using krb5 functions.

The second attached patch against current gssproxy HEAD adds that distinction and makes this case work as an optional extension with fallback into the default codepath on error.

Does that make sense? Is it sane, security wise, do you think? -- Thanks, Michael ________________________________________ From: Simo Sorce simo@redhat.com Sent: 16 December 2020 15:31:40 To: The GSS-Proxy developers and users mailing list; linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Subject: [gssproxy] Re: cifs-utils, Linux cifs kernel client and gssproxy

Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.

Hi Michael, as you say the best course of action would be for cifs.ko to move to use the RPC interface we defined for knfsd (with any extensions that may be needed), and we had discussions in the past with cifs upstream developers about it. But nothing really materialized.

If something is needed in the short term, I thjink the quickest course of action is indeed to change the userspace helper to use gssapi function calls, so that they can be intercepted like we do for rpc.gssd (nfs client's userspace helper).

Unfortunately I do not have the cycles to work on that myself at this time :-(

HTH, Simo.

On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote:

...

Hello,

I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1].

My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2]

From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials.

Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]).

Assuming my understanding is correct so far:

Is anyone doing any work on this and could use some help (testing, coding)? What would be expected complexity and possible roadblocks when trying to make a start at implementing this? Or is the idea moot due to some constraint or recent development I'm not aware of?

I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though.

As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on. Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)?

[1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-... [2] https://pagure.io/gssproxy/issue/56 [3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md [4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server [5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client [6] https://www.spinics.net/lists/linux-cifs/msg20182.html -- Thanks, Michael _______________________________________________ gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or...

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

---

gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or...

On Fri, 2021-02-19 at 03:26 -0800, Shyam Prasad N wrote:

Hi Michael,

What happens when credentials are not supplied in keytab files? Is there a way to supply the credentials from other sources in that case? The reason why I'm asking this is that this same code can be used by cifscreds (or a new executable) to perform the authentication, and collect the krb5 tickets.

Either a keytab or a ccache can be used. If a user is interactively no the system and have created a ccache that can be used directly.

Also, in the cifs.upcall changes, you could check for the GSS_USE_PROXY env variable. In the absence of which, fallback to the older code. If that is done, it gives the user an option to go for one option or the other. Other than that, the changes look fine to me.

Regards, Shyam

On Thu, Jan 7, 2021 at 3:08 AM Weiser, Michael michael.weiser@atos.net wrote:

...

Hello Simo, Hello Steve,

...

If something is needed in the short term, I thjink the quickest course of action is indeed to change the userspace helper to use gssapi function calls, so that they can be intercepted like we do for rpc.gssd (nfs client's userspace helper).

To get the ball rolling and give people (including myself and client) something to play with I went that route and extended cifs.upcall to fall back to GSS-API if no ticket cache nor keytab can be found for the user. An unpolished PoC patch is attached. (Sorry, for not putting it inline, have to rock the groupware at work. I will try to sort that once we've agreed this is the/a way to go.)

With that patch applied, I can do a multiuser cifs mount using the system keytab and machine identity as usual and then have users access the mount using impersonated credentials from gssproxy. Quick demo:

[root@fedora33 ~]# umount /mnt [root@fedora33 ~]# mount -o sec=krb5,multiuser,user=FEDORA33$ //dc/share /mnt [root@fedora33 ~]# ls -la /mnt total 0 drwxr-xr-x. 2 root root 0 Jan 7 10:20 . dr-xr-xr-x. 18 root root 238 Jan 6 13:59 .. -rwxr-xr-x. 1 root root 0 Jan 5 17:02 bar [root@fedora33 ~]# klist klist: Credentials cache keyring 'persistent:0:krb_ccache_WZh7W8n' not found [root@fedora33 ~]#

[adsuser@fedora33 ~]$ kdestroy [adsuser@fedora33 ~]$ echo test > /mnt/test [adsuser@fedora33 ~]$ cat /mnt/test test [adsuser@fedora33 ~]$ klist klist: Credentials cache keyring 'persistent:1618201110:krb_ccache_SrGqT3F' not found [adsuser@fedora33 ~]$

Server-side permissions are enforced:

[m@fedora33 ~]$ cat /mnt/test test [m@fedora33 ~]$ echo mytest > /mnt/test -bash: /mnt/test: Permission denied [m@fedora33 ~]$ klist klist: Credentials cache keyring 'persistent:1000:1000' not found [m@fedora33 ~]$

The gssproxy config for this configures a cifs-specific socket and enables impersonation for any user id:

[root@fedora33 ~]# cat /etc/gssproxy/99-cifs.conf [service/cifs] mechs = krb5 socket = /var/lib/gssproxy/cifs.sock cred_store = keytab:/etc/krb5.keytab cred_usage = initiate euid = 0 impersonate = yes allow_any_uid = yes

And request-key config for cifs.spnego enables use of gssproxy and the service-specific socket through environment variables:

[root@fedora33 ~]# cat /etc/request-key.d/cifs.spnego.conf create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall %k

(I see that nfs-utils' gssd does the same by setting the variables itself based on command line options. That could easily be done here as well.)

User FEDORA33$ (the computer object) needs to be enabled for delegation to service cifs. I've tested with a Fedora 33 client and Windows 2016 Active Directory server.

The patch is against current cifs-utils HEAD. It is lacking all the autoconf trimmings and intentionally forgoes reindents of existing code for clarity of what's being touched.

What do you think?

...

Unfortunately I do not have the cycles to work on that myself at this time :-(

I have a client in very tangible need of this functionality who is a RedHat customer. Would it be helpful if they were to open a case with Redhat on this?

As an extension the above (but not to distract from the focus of getting something to work at all first):

I rather accidentally also played around with delegating retrieval of the mount credentials into gssproxy as well (due to not realising that username=FEDORA33$ would just activate the keytab codepath in cifs.upcall).

This can be done by leaving out the username from the mount command, marking euid 0 as trusted for access to the keytab in gssproxy and adding a fallback principal to the gssproxy config (because cifs.upcall in this case does not submit a desired name for the credential):

[root@fedora33 ~]# mount -o sec=krb5,multiuser //dc/share /mnt [root@fedora33 ~]# cat /etc/gssproxy/99-cifs.conf [service/cifs] mechs = krb5 socket = /var/lib/gssproxy/cifs.sock cred_store = keytab:/etc/krb5.keytab cred_usage = initiate euid = 0 trusted = yes impersonate = yes krb5_principal = cifs-mount allow_any_uid = yes

While this works, it requires a separate user who would then carefully need to be kept out of any sensitive file access groups.

When trying to use the machine identity FEDORA33$ instead, I ran into a peculiar error from the AD KDC:

[root@fedora33 ~]# cat /etc/gssproxy/99-cifs.conf [service/cifs] mechs = krb5 socket = /var/lib/gssproxy/cifs.sock cred_store = keytab:/etc/krb5.keytab cred_usage = initiate euid = 0 trusted = yes impersonate = yes krb5_principal = FEDORA33$ allow_any_uid = yes [root@fedora33 ~]# gssproxy -i -d & [2] 3814 [root@fedora33 ~]# [2021/01/07 10:01:10]: Debug Enabled (level: 1) [2021/01/07 10:01:10]: Service: nfs-server, Keytab: /etc/krb5.keytab, Enctype: 17 [2021/01/07 10:01:10]: Service: cifs, Keytab: /etc/krb5.keytab, Enctype: 17 [2021/01/07 10:01:10]: Service: nfs-client, Keytab: /etc/krb5.keytab, Enctype: 17 [2021/01/07 10:01:10]: Client [2021/01/07 10:01:10]: (/usr/sbin/gssproxy) [2021/01/07 10:01:10]: connected (fd = 11)[2021/01/07 10:01:10]: (pid = 3814) (uid = 0) (gid = 0)[2021/01/07 10:01:10]: (context = system_u:system_r:kernel_t:s0)[2021/01/07 10:01:10]:

[root@fedora33 ~]# mount -o sec=krb5,multiuser //dc/share /mnt [2021/01/07 10:01:13]: Client [2021/01/07 10:01:13]: (/usr/sbin/cifs.upcall) [2021/01/07 10:01:13]: connected (fd = 12)[2021/01/07 10:01:13]: (pid = 3824) (uid = 0) (gid = 0)[2021/01/07 10:01:13]: (context = system_u:system_r:kernel_t:s0)[2021/01/07 10:01:13]: [CID 12][2021/01/07 10:01:13]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "cifs", euid: 0,socket: /var/lib/gssproxy/cifs.sock gssproxy[3814]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, KDC has no support for padata type [CID 12][2021/01/07 10:01:13]: gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 0,socket: /var/lib/gssproxy/cifs.sock gssproxy[3814]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, KDC has no support for padata type [CID 12][2021/01/07 10:01:13]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "cifs", euid: 0,socket: /var/lib/gssproxy/cifs.sock gssproxy[3814]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, KDC has no support for padata type [CID 12][2021/01/07 10:01:13]: gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 0,socket: /var/lib/gssproxy/cifs.sock gssproxy[3814]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, KDC has no support for padata type mount error(126): Required key not available Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

With more debugging it appears that gssproxy tries to impersonate user FEDORA33$ with a credential which is also for FEDORA33$. After further testing it seems this is generally not allowed or just not working due to never being tested because it is unnecessary: If we can acquire a impersonation credential for that identity we should also be able to get the actual access credential as well.

From looking at the nfs-utils gssd code it appears the only reason it hasn't run into this case yet is because it handles the machine credentials itself using krb5 functions.

The second attached patch against current gssproxy HEAD adds that distinction and makes this case work as an optional extension with fallback into the default codepath on error.

Does that make sense? Is it sane, security wise, do you think? -- Thanks, Michael ________________________________________ From: Simo Sorce simo@redhat.com Sent: 16 December 2020 15:31:40 To: The GSS-Proxy developers and users mailing list; linux-cifs@vger.kernel.org Cc: samba-technical@lists.samba.org Subject: [gssproxy] Re: cifs-utils, Linux cifs kernel client and gssproxy

Caution! External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.

Hi Michael, as you say the best course of action would be for cifs.ko to move to use the RPC interface we defined for knfsd (with any extensions that may be needed), and we had discussions in the past with cifs upstream developers about it. But nothing really materialized.

If something is needed in the short term, I thjink the quickest course of action is indeed to change the userspace helper to use gssapi function calls, so that they can be intercepted like we do for rpc.gssd (nfs client's userspace helper).

Unfortunately I do not have the cycles to work on that myself at this time :-(

HTH, Simo.

On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote:

...

Hello,

I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1].

My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2]

From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials.

Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]).

Assuming my understanding is correct so far:

Is anyone doing any work on this and could use some help (testing, coding)? What would be expected complexity and possible roadblocks when trying to make a start at implementing this? Or is the idea moot due to some constraint or recent development I'm not aware of?

I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though.

As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on. Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)?

[1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-... [2] https://pagure.io/gssproxy/issue/56 [3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md [4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server [5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client [6] https://www.spinics.net/lists/linux-cifs/msg20182.html -- Thanks, Michael _______________________________________________ gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or...

-- Simo Sorce RHEL Crypto Team Red Hat, Inc

---

gss-proxy mailing list -- gss-proxy@lists.fedorahosted.org To unsubscribe send an email to gss-proxy-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@lists.fedorahosted.or...