* cifs-utils, Linux cifs kernel client and gssproxy @ 2020-12-16 10:01 Weiser, Michael 2020-12-16 14:31 ` [gssproxy] " Simo Sorce 0 siblings, 1 reply; 28+ messages in thread From: Weiser, Michael @ 2020-12-16 10:01 UTC (permalink / raw) To: linux-cifs; +Cc: samba-technical, gss-proxy 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-via-constrained-delegation [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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2020-12-16 10:01 cifs-utils, Linux cifs kernel client and gssproxy Weiser, Michael @ 2020-12-16 14:31 ` Simo Sorce 2020-12-16 22:43 ` Steve French 2021-01-07 11:04 ` [gssproxy] " Weiser, Michael 0 siblings, 2 replies; 28+ messages in thread From: Simo Sorce @ 2020-12-16 14:31 UTC (permalink / raw) To: The GSS-Proxy developers and users mailing list, linux-cifs Cc: samba-technical 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-via-constrained-delegation > [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.org -- Simo Sorce RHEL Crypto Team Red Hat, Inc ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2020-12-16 14:31 ` [gssproxy] " Simo Sorce @ 2020-12-16 22:43 ` Steve French 2020-12-17 13:39 ` Simo Sorce 2021-01-07 11:04 ` [gssproxy] " Weiser, Michael 1 sibling, 1 reply; 28+ messages in thread From: Steve French @ 2020-12-16 22:43 UTC (permalink / raw) To: Simo Sorce Cc: The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical 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-via-constrained-delegation > > [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.org > > -- > Simo Sorce > RHEL Crypto Team > Red Hat, Inc > > > > -- Thanks, Steve ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2020-12-16 22:43 ` Steve French @ 2020-12-17 13:39 ` Simo Sorce 2020-12-17 21:22 ` Steve French 2021-02-19 11:30 ` Shyam Prasad N 0 siblings, 2 replies; 28+ messages in thread From: Simo Sorce @ 2020-12-17 13:39 UTC (permalink / raw) To: Steve French Cc: The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical 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-via-constrained-delegation > > > [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.org > > > > -- > > Simo Sorce > > RHEL Crypto Team > > Red Hat, Inc > > > > > > > > > > -- Simo Sorce RHEL Crypto Team Red Hat, Inc ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2020-12-17 13:39 ` Simo Sorce @ 2020-12-17 21:22 ` Steve French 2020-12-17 21:25 ` Steve French 2020-12-17 21:49 ` Simo Sorce 2021-02-19 11:30 ` Shyam Prasad N 1 sibling, 2 replies; 28+ messages in thread From: Steve French @ 2020-12-17 21:22 UTC (permalink / raw) To: Simo Sorce Cc: The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical 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-via-constrained-delegation > > > > [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.org > > > > > > -- > > > Simo Sorce > > > RHEL Crypto Team > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > -- > Simo Sorce > RHEL Crypto Team > Red Hat, Inc > > > > -- Thanks, Steve ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2020-12-17 21:22 ` Steve French @ 2020-12-17 21:25 ` Steve French 2020-12-17 21:53 ` Simo Sorce 2020-12-17 21:49 ` Simo Sorce 1 sibling, 1 reply; 28+ messages in thread From: Steve French @ 2020-12-17 21:25 UTC (permalink / raw) To: Simo Sorce Cc: The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical 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-via-constrained-delegation > > > > > [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.org > > > > > > > > -- > > > > Simo Sorce > > > > RHEL Crypto Team > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Simo Sorce > > RHEL Crypto Team > > Red Hat, Inc > > > > > > > > > > > -- > Thanks, > > Steve -- Thanks, Steve ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2020-12-17 21:25 ` Steve French @ 2020-12-17 21:53 ` Simo Sorce 0 siblings, 0 replies; 28+ messages in thread From: Simo Sorce @ 2020-12-17 21:53 UTC (permalink / raw) To: Steve French Cc: The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical On Thu, 2020-12-17 at 15:25 -0600, Steve French wrote: > 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? No, and it is unpredictable. We discussed the same with knfsd and realized that in the end, all you need to handle is a timeout and failure to authenticate. These libraries are not involved once the session is established, as the encryption key is transferred back to the kernel. This is similar to kTLS, the negotiation phase which is more complicated and require interaction with more userland components as well as potentially use more complicated asymmetric cryptography (as well as ASN.1 and all those good CVE-prone protocols) is deferred to userspace. Once a session is established a session key is returned to the kernel which uses relatively simple symmetric encryption primitives. > 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-via-constrained-delegation > > > > > > [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.org > > > > > > > > > > -- > > > > > Simo Sorce > > > > > RHEL Crypto Team > > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Simo Sorce > > > RHEL Crypto Team > > > Red Hat, Inc > > > > > > > > > > > > > > > > -- > > Thanks, > > > > Steve > > -- Simo Sorce RHEL Crypto Team Red Hat, Inc ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2020-12-17 21:22 ` Steve French 2020-12-17 21:25 ` Steve French @ 2020-12-17 21:49 ` Simo Sorce 1 sibling, 0 replies; 28+ messages in thread From: Simo Sorce @ 2020-12-17 21:49 UTC (permalink / raw) To: Steve French Cc: The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical 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-via-constrained-delegation > > > > > [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.org > > > > > > > > -- > > > > Simo Sorce > > > > RHEL Crypto Team > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > -- > > Simo Sorce > > RHEL Crypto Team > > Red Hat, Inc > > > > > > > > > > -- Simo Sorce RHEL Crypto Team Red Hat, Inc ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2020-12-17 13:39 ` Simo Sorce 2020-12-17 21:22 ` Steve French @ 2021-02-19 11:30 ` Shyam Prasad N 2021-02-19 17:35 ` Simo Sorce 1 sibling, 1 reply; 28+ messages in thread From: Shyam Prasad N @ 2021-02-19 11:30 UTC (permalink / raw) To: Simo Sorce Cc: Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical 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? 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-via-constrained-delegation > > > > [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.org > > > > > > -- > > > Simo Sorce > > > RHEL Crypto Team > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > -- > Simo Sorce > RHEL Crypto Team > Red Hat, Inc > > > > -- Regards, Shyam ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2021-02-19 11:30 ` Shyam Prasad N @ 2021-02-19 17:35 ` Simo Sorce 2021-02-23 17:42 ` Jacob Shivers 0 siblings, 1 reply; 28+ messages in thread From: Simo Sorce @ 2021-02-19 17:35 UTC (permalink / raw) To: Shyam Prasad N Cc: Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical 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-via-constrained-delegation > > > > > [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.org > > > > > > > > -- > > > > Simo Sorce > > > > RHEL Crypto Team > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > -- > > Simo Sorce > > RHEL Crypto Team > > Red Hat, Inc > > > > > > > > > > -- Simo Sorce RHEL Crypto Team Red Hat, Inc ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2021-02-19 17:35 ` Simo Sorce @ 2021-02-23 17:42 ` Jacob Shivers 2021-02-23 19:54 ` Simo Sorce 2021-09-24 17:09 ` Pavel Shilovsky 0 siblings, 2 replies; 28+ messages in thread From: Jacob Shivers @ 2021-02-23 17:42 UTC (permalink / raw) To: Simo Sorce Cc: Shyam Prasad N, Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical, piastryyy 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-via-constrained-delegation > > > > > > [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.org > > > > > > > > > > -- > > > > > Simo Sorce > > > > > RHEL Crypto Team > > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Simo Sorce > > > RHEL Crypto Team > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > -- > Simo Sorce > RHEL Crypto Team > Red Hat, Inc > > > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2021-02-23 17:42 ` Jacob Shivers @ 2021-02-23 19:54 ` Simo Sorce 2021-03-05 21:29 ` Jacob Shivers 2021-09-24 17:09 ` Pavel Shilovsky 1 sibling, 1 reply; 28+ messages in thread From: Simo Sorce @ 2021-02-23 19:54 UTC (permalink / raw) To: Jacob Shivers Cc: Shyam Prasad N, Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical, piastryyy 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-via-constrained-delegation > > > > > > > [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.org > > > > > > > > > > > > -- > > > > > > 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2021-02-23 19:54 ` Simo Sorce @ 2021-03-05 21:29 ` Jacob Shivers 2021-03-05 22:19 ` Simo Sorce 0 siblings, 1 reply; 28+ messages in thread From: Jacob Shivers @ 2021-03-05 21:29 UTC (permalink / raw) To: Simo Sorce Cc: Shyam Prasad N, Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical, piastryyy 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!". 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. 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-via-constrained-delegation > > > > > > > > [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.org > > > > > > > > > > > > > > -- > > > > > > > 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 > > > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2021-03-05 21:29 ` Jacob Shivers @ 2021-03-05 22:19 ` Simo Sorce 2021-04-13 23:53 ` ronnie sahlberg 0 siblings, 1 reply; 28+ messages in thread From: Simo Sorce @ 2021-03-05 22:19 UTC (permalink / raw) To: Jacob Shivers Cc: Shyam Prasad N, Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical, piastryyy 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-via-constrained-delegation > > > > > > > > > [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.org > > > > > > > > > > > > > > > > -- > > > > > > > > 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 > > > > > > > > -- Simo Sorce RHEL Crypto Team Red Hat, Inc ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2021-03-05 22:19 ` Simo Sorce @ 2021-04-13 23:53 ` ronnie sahlberg 0 siblings, 0 replies; 28+ messages in thread From: ronnie sahlberg @ 2021-04-13 23:53 UTC (permalink / raw) To: Simo Sorce Cc: Jacob Shivers, Shyam Prasad N, Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical, Pavel Shilovsky Pavel, What is the status of this patch and getting it into cifs-utils? The are reported to work in tests by some folks and they do provide desired new functionality. regards ronnie sahlberg On Sat, Mar 6, 2021 at 8:20 AM Simo Sorce <simo@redhat.com> wrote: > > 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-via-constrained-delegation > > > > > > > > > > [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.org > > > > > > > > > > > > > > > > > > -- > > > > > > > > > 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 > > > > > > > > > > > > > > -- > Simo Sorce > RHEL Crypto Team > Red Hat, Inc > > > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2021-02-23 17:42 ` Jacob Shivers 2021-02-23 19:54 ` Simo Sorce @ 2021-09-24 17:09 ` Pavel Shilovsky 2021-09-25 7:28 ` ronnie sahlberg 2021-09-27 7:18 ` Weiser, Michael 1 sibling, 2 replies; 28+ messages in thread From: Pavel Shilovsky @ 2021-09-24 17:09 UTC (permalink / raw) To: Jacob Shivers Cc: Simo Sorce, Shyam Prasad N, Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical 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-via-constrained-delegation > > > > > > > [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.org > > > > > > > > > > > > -- > > > > > > Simo Sorce > > > > > > RHEL Crypto Team > > > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Simo Sorce > > > > RHEL Crypto Team > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Simo Sorce > > RHEL Crypto Team > > Red Hat, Inc > > > > > > > > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2021-09-24 17:09 ` Pavel Shilovsky @ 2021-09-25 7:28 ` ronnie sahlberg 2021-09-27 7:18 ` Weiser, Michael 1 sibling, 0 replies; 28+ messages in thread From: ronnie sahlberg @ 2021-09-25 7:28 UTC (permalink / raw) To: Pavel Shilovsky Cc: Jacob Shivers, Shyam Prasad N, linux-cifs, The GSS-Proxy developers and users mailing list, samba-technical, Steve French, Simo Sorce AFAIK this is the most recent one. On Sat, Sep 25, 2021 at 3:11 AM Pavel Shilovsky via samba-technical <samba-technical@lists.samba.org> wrote: > > 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-via-constrained-delegation > > > > > > > > [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.org > > > > > > > > > > > > > > -- > > > > > > > Simo Sorce > > > > > > > RHEL Crypto Team > > > > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Simo Sorce > > > > > RHEL Crypto Team > > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Simo Sorce > > > RHEL Crypto Team > > > Red Hat, Inc > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2021-09-24 17:09 ` Pavel Shilovsky 2021-09-25 7:28 ` ronnie sahlberg @ 2021-09-27 7:18 ` Weiser, Michael 2021-09-30 23:17 ` Jacob Shivers 1 sibling, 1 reply; 28+ messages in thread From: Weiser, Michael @ 2021-09-27 7:18 UTC (permalink / raw) To: Pavel Shilovsky, Jacob Shivers Cc: Simo Sorce, Shyam Prasad N, Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical 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;h=833d8e0110a9737df8ef6ddeb439ba1a37ee9931;hb=HEAD#l1128 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-via-constrained-delegation > > > > > > > [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.org > > > > > > > > > > > > -- > > > > > > Simo Sorce > > > > > > RHEL Crypto Team > > > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Simo Sorce > > > > RHEL Crypto Team > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Simo Sorce > > RHEL Crypto Team > > Red Hat, Inc > > > > > > > > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2021-09-27 7:18 ` Weiser, Michael @ 2021-09-30 23:17 ` Jacob Shivers 2021-10-21 23:23 ` Pavel Shilovsky 0 siblings, 1 reply; 28+ messages in thread From: Jacob Shivers @ 2021-09-30 23:17 UTC (permalink / raw) To: Weiser, Michael Cc: Pavel Shilovsky, Simo Sorce, Shyam Prasad N, Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical 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;h=833d8e0110a9737df8ef6ddeb439ba1a37ee9931;hb=HEAD#l1128 > > 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-via-constrained-delegation > > > > > > > > [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.org > > > > > > > > > > > > > > -- > > > > > > > Simo Sorce > > > > > > > RHEL Crypto Team > > > > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Simo Sorce > > > > > RHEL Crypto Team > > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Simo Sorce > > > RHEL Crypto Team > > > Red Hat, Inc > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2021-09-30 23:17 ` Jacob Shivers @ 2021-10-21 23:23 ` Pavel Shilovsky [not found] ` <CAGvGhF5rVU1WzLk=aE36n47P357UBOPbsjXE=B8J+feO3bVSSQ@mail.gmail.com> 0 siblings, 1 reply; 28+ messages in thread From: Pavel Shilovsky @ 2021-10-21 23:23 UTC (permalink / raw) To: Jacob Shivers Cc: Weiser, Michael, Simo Sorce, Shyam Prasad N, Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical 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/3d681bb5c140376ccc19e48711231aeef1e87aa9 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;h=833d8e0110a9737df8ef6ddeb439ba1a37ee9931;hb=HEAD#l1128 > > > > 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-via-constrained-delegation > > > > > > > > > [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.org > > > > > > > > > > > > > > > > -- > > > > > > > > Simo Sorce > > > > > > > > RHEL Crypto Team > > > > > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Simo Sorce > > > > > > RHEL Crypto Team > > > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Simo Sorce > > > > RHEL Crypto Team > > > > Red Hat, Inc > > > > > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <CAGvGhF5rVU1WzLk=aE36n47P357UBOPbsjXE=B8J+feO3bVSSQ@mail.gmail.com>]
[parent not found: <CALe0_77Bv_+v9cdNd_AL5DgA2+EaXMtF_0+rUw6y46fhHq0M4A@mail.gmail.com>]
[parent not found: <CAKywueQU8P-XQsiy4x6B=0YjuwUmTzPVg--SY0sWzGuq6Oy_-w@mail.gmail.com>]
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy [not found] ` <CAKywueQU8P-XQsiy4x6B=0YjuwUmTzPVg--SY0sWzGuq6Oy_-w@mail.gmail.com> @ 2021-10-26 10:08 ` Weiser, Michael 2021-10-26 15:05 ` Jacob Shivers 1 sibling, 0 replies; 28+ messages in thread From: Weiser, Michael @ 2021-10-26 10:08 UTC (permalink / raw) To: Pavel Shilovsky, Jacob Shivers Cc: Leif Sahlberg, Simo Sorce, Shyam Prasad N, Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical Hello Pavel, I've now also had a chance to look at this in more detail. I've done a quick test and everything still seems to work with the next branch. > The only concern that I have is the compile warning below. Would > appreciate it if you provide a fix for that. FWIW: I do not get that warning either on Fedora 33 with gcc 10.3 and krb5-1.18.2-29.fc33 nor on Debian testing as of today with gcc 10.3 and krb5-1.18.3-7 nor on Gentoo with gcc-11.2.0 and mit-krb5-1.19.2. But I do see that gssproxy has run into this as well and solved it the same way. Looking at gssapi docs and source I do not see that we're doing anything wrong here. There's one minor additional change I found in my local branch switching from (gss_OID)gss_nt_service_name to the more modern GSS_C_NT_HOSTBASED_SERVICE in gss_import_name(). I've opened a PR on github. (Below as well but the groupware will likely corrupt it.) The old style bled over from an MIT krb5 example I based my initial trials on. The removed cast might require another discard_const() now. Since I can't reproduce it, I'd leave that up to you. Author: Michael Weiser <michael.weiser@atos.net> Date: Tue Oct 26 11:11:48 2021 +0200 cifs.upcall: switch to RFC principal type naming Switch from old-style MIT krb5 gss_nt_service_name principal type constant name to the now preferred GSS_C_NT_HOSTBASED_SERVICE. Signed-off-by: Michael Weiser <michael.weiser@atos.net> diff --git a/cifs.upcall.c b/cifs.upcall.c index e9c7f5f..f11bfa6 100644 --- a/cifs.upcall.c +++ b/cifs.upcall.c @@ -794,7 +794,7 @@ cifs_gss_get_req(const char *host, DATA_BLOB *mechtoken, DATA_BLOB *sess_key) target_name_buf.length = service_name_len; maj_stat = gss_import_name(&min_stat, &target_name_buf, - (gss_OID)gss_nt_service_name, &target_name); + GSS_C_NT_HOSTBASED_SERVICE, &target_name); free(service_name); if (GSS_ERROR(maj_stat)) { cifs_gss_display_status("gss_import_name", maj_stat, min_stat); -- Thanks Michael ^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy [not found] ` <CAKywueQU8P-XQsiy4x6B=0YjuwUmTzPVg--SY0sWzGuq6Oy_-w@mail.gmail.com> 2021-10-26 10:08 ` Weiser, Michael @ 2021-10-26 15:05 ` Jacob Shivers 2021-11-05 0:31 ` Pavel Shilovsky 1 sibling, 1 reply; 28+ messages in thread From: Jacob Shivers @ 2021-10-26 15:05 UTC (permalink / raw) To: Pavel Shilovsky Cc: Leif Sahlberg, Weiser, Michael, Simo Sorce, Shyam Prasad N, Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical Hello Pavel, Brief addition to man 8 cifs.upcall Author: Jacob Shivers <jshivers@redhat.com> Date: Tue Oct 26 10:57:41 2021 -0400 man-pages: Update cifs.upcall to mention GSS_USE_PROXY Add ENVIRONMENT VARIABLES section with the usage of gssproxy as a credential retrieval method. Signed-off-by: Jacob Shivers <jshivers@redhat.com> diff --git a/cifs.upcall.rst.in b/cifs.upcall.rst.in index 08ce324..09d0503 100644 --- a/cifs.upcall.rst.in +++ b/cifs.upcall.rst.in @@ -91,6 +91,15 @@ OPTIONS --version|-v Print version number and exit. +********************* +ENVIRONMENT VARIABLES +********************* + +GSS_USE_PROXY="yes" + Enable usage of gssproxy for credential retrieval. This includes keytab + based client initiation as well as (Resource Based) Constrained Delegation. + See gssproxy-mech(8). + ************************ CONFIGURATION FOR KEYCTL ************************ On Mon, Oct 25, 2021 at 5:32 PM Pavel Shilovsky <piastryyy@gmail.com> wrote: > > Ronnie, > Thanks for the patch to silent compile warning. Let me try it. > > Jacob, > Sounds good. I haven't updated the cifs.upcall man page yet. Feel free > to provide the patch. > -- > Best regards, > Pavel Shilovsky > > пт, 22 окт. 2021 г. в 19:16, Jacob Shivers <jshivers@redhat.com>: > > > > Everything looks good. > > > > I sent a PR for gssproxy adding a drop file for cifs-client. I think > > the only thing outstanding will be an update to man 8 cifs.upcall that > > mentions the requirement to add GSS_USE_PROXY in > > /etc/request-key.d/cifs.spnego. I don't have a particular stance on a > > short-hand flag for GSS_USE_PROXY=yes as there is not already an > > existing configuration file for client side cifs.ko. Should one ever > > be created then it would be pertinent to include it there. > > > > If you don't have anything written for man 8 cifs.upcall, I can take > > care of that. > > > > Thanks again. > > > > On Thu, Oct 21, 2021 at 7:46 PM Leif Sahlberg <lsahlber@redhat.com> wrote: > > > > > > > > > > > > > > > On Fri, Oct 22, 2021 at 9:23 AM Pavel Shilovsky <piastryyy@gmail.com> wrote: > > >> > > >> 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/3d681bb5c140376ccc19e48711231aeef1e87aa9 > > >> > > >> 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( > > >> ^ > > > > > > > > > I do not get that warning on my system, but this patch should fix it? > > > > > > Author: Ronnie Sahlberg <lsahlber@redhat.com> > > > Date: Fri Oct 22 09:41:24 2021 +1000 > > > > > > cifs.upcall.c: fix compiler warning > > > > > > Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com> > > > > > > diff --git a/cifs.upcall.c b/cifs.upcall.c > > > index e9c7f5f..5e7c0a1 100644 > > > --- a/cifs.upcall.c > > > +++ b/cifs.upcall.c > > > @@ -69,6 +69,10 @@ > > > #include <cap-ng.h> > > > #endif > > > > > > +#ifndef discard_const > > > +#define discard_const(ptr) ((void *)((intptr_t)(ptr))) > > > +#endif > > > + > > > static krb5_context context; > > > static const char *prog = "cifs.upcall"; > > > > > > @@ -805,7 +809,7 @@ cifs_gss_get_req(const char *host, DATA_BLOB *mechtoken, DATA_BLOB *sess_key) > > > GSS_C_NO_CREDENTIAL, /* claimant_cred_handle */ > > > &ctx, > > > target_name, > > > - gss_mech_krb5, /* force krb5 */ > > > + discard_const(gss_mech_krb5), /* force krb5 */ > > > 0, /* flags */ > > > 0, /* time_req */ > > > GSS_C_NO_CHANNEL_BINDINGS, /* input_chan_bindings */ > > > > > > > > > > > >> > > >> 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;h=833d8e0110a9737df8ef6ddeb439ba1a37ee9931;hb=HEAD#l1128 > > >> > > > > >> > > 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-via-constrained-delegation > > >> > > > > > > > > > [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.org > > >> > > > > > > > > > > >> > > > > > > > > -- > > >> > > > > > > > > Simo Sorce > > >> > > > > > > > > RHEL Crypto Team > > >> > > > > > > > > Red Hat, Inc > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > > > -- > > >> > > > > > > Simo Sorce > > >> > > > > > > RHEL Crypto Team > > >> > > > > > > Red Hat, Inc > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > -- > > >> > > > > Simo Sorce > > >> > > > > RHEL Crypto Team > > >> > > > > Red Hat, Inc > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > ^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy 2021-10-26 15:05 ` Jacob Shivers @ 2021-11-05 0:31 ` Pavel Shilovsky 0 siblings, 0 replies; 28+ messages in thread From: Pavel Shilovsky @ 2021-11-05 0:31 UTC (permalink / raw) To: Jacob Shivers Cc: Leif Sahlberg, Weiser, Michael, Simo Sorce, Shyam Prasad N, Steve French, The GSS-Proxy developers and users mailing list, linux-cifs, samba-technical Thanks everyone for the patches! All 3 have been merged to the next branch: https://github.com/piastry/cifs-utils/commits/next. There are no compiler warnings on my system but let me know if you spot anything. -- Best regards, Pavel Shilovsky вт, 26 окт. 2021 г. в 08:05, Jacob Shivers <jshivers@redhat.com>: > > Hello Pavel, > > Brief addition to man 8 cifs.upcall > > Author: Jacob Shivers <jshivers@redhat.com> > Date: Tue Oct 26 10:57:41 2021 -0400 > > man-pages: Update cifs.upcall to mention GSS_USE_PROXY > > Add ENVIRONMENT VARIABLES section with the usage of gssproxy as a credential > retrieval method. > > Signed-off-by: Jacob Shivers <jshivers@redhat.com> > > diff --git a/cifs.upcall.rst.in b/cifs.upcall.rst.in > index 08ce324..09d0503 100644 > --- a/cifs.upcall.rst.in > +++ b/cifs.upcall.rst.in > @@ -91,6 +91,15 @@ OPTIONS > --version|-v > Print version number and exit. > > +********************* > +ENVIRONMENT VARIABLES > +********************* > + > +GSS_USE_PROXY="yes" > + Enable usage of gssproxy for credential retrieval. This includes keytab > + based client initiation as well as (Resource Based) Constrained Delegation. > + See gssproxy-mech(8). > + > ************************ > CONFIGURATION FOR KEYCTL > ************************ > > On Mon, Oct 25, 2021 at 5:32 PM Pavel Shilovsky <piastryyy@gmail.com> wrote: > > > > Ronnie, > > Thanks for the patch to silent compile warning. Let me try it. > > > > Jacob, > > Sounds good. I haven't updated the cifs.upcall man page yet. Feel free > > to provide the patch. > > -- > > Best regards, > > Pavel Shilovsky > > > > пт, 22 окт. 2021 г. в 19:16, Jacob Shivers <jshivers@redhat.com>: > > > > > > Everything looks good. > > > > > > I sent a PR for gssproxy adding a drop file for cifs-client. I think > > > the only thing outstanding will be an update to man 8 cifs.upcall that > > > mentions the requirement to add GSS_USE_PROXY in > > > /etc/request-key.d/cifs.spnego. I don't have a particular stance on a > > > short-hand flag for GSS_USE_PROXY=yes as there is not already an > > > existing configuration file for client side cifs.ko. Should one ever > > > be created then it would be pertinent to include it there. > > > > > > If you don't have anything written for man 8 cifs.upcall, I can take > > > care of that. > > > > > > Thanks again. > > > > > > On Thu, Oct 21, 2021 at 7:46 PM Leif Sahlberg <lsahlber@redhat.com> wrote: > > > > > > > > > > > > > > > > > > > > On Fri, Oct 22, 2021 at 9:23 AM Pavel Shilovsky <piastryyy@gmail.com> wrote: > > > >> > > > >> 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/3d681bb5c140376ccc19e48711231aeef1e87aa9 > > > >> > > > >> 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( > > > >> ^ > > > > > > > > > > > > I do not get that warning on my system, but this patch should fix it? > > > > > > > > Author: Ronnie Sahlberg <lsahlber@redhat.com> > > > > Date: Fri Oct 22 09:41:24 2021 +1000 > > > > > > > > cifs.upcall.c: fix compiler warning > > > > > > > > Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com> > > > > > > > > diff --git a/cifs.upcall.c b/cifs.upcall.c > > > > index e9c7f5f..5e7c0a1 100644 > > > > --- a/cifs.upcall.c > > > > +++ b/cifs.upcall.c > > > > @@ -69,6 +69,10 @@ > > > > #include <cap-ng.h> > > > > #endif > > > > > > > > +#ifndef discard_const > > > > +#define discard_const(ptr) ((void *)((intptr_t)(ptr))) > > > > +#endif > > > > + > > > > static krb5_context context; > > > > static const char *prog = "cifs.upcall"; > > > > > > > > @@ -805,7 +809,7 @@ cifs_gss_get_req(const char *host, DATA_BLOB *mechtoken, DATA_BLOB *sess_key) > > > > GSS_C_NO_CREDENTIAL, /* claimant_cred_handle */ > > > > &ctx, > > > > target_name, > > > > - gss_mech_krb5, /* force krb5 */ > > > > + discard_const(gss_mech_krb5), /* force krb5 */ > > > > 0, /* flags */ > > > > 0, /* time_req */ > > > > GSS_C_NO_CHANNEL_BINDINGS, /* input_chan_bindings */ > > > > > > > > > > > > > > > >> > > > >> 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;h=833d8e0110a9737df8ef6ddeb439ba1a37ee9931;hb=HEAD#l1128 > > > >> > > > > > >> > > Thanks, > > > >> > > Michael > > > >> > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] Re: cifs-utils, Linux cifs kernel client and gssproxy 2020-12-16 14:31 ` [gssproxy] " Simo Sorce 2020-12-16 22:43 ` Steve French @ 2021-01-07 11:04 ` Weiser, Michael [not found] ` <2d5a7cf3b6e8e31db010f6a3d159109ca48ca998.camel@samba.org> 2021-02-19 11:26 ` Shyam Prasad N 1 sibling, 2 replies; 28+ messages in thread From: Weiser, Michael @ 2021-01-07 11:04 UTC (permalink / raw) To: Steve French, Simo Sorce Cc: samba-technical, linux-cifs, The GSS-Proxy developers and users mailing list [-- Attachment #1: Type: text/plain, Size: 12347 bytes --] 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-via-constrained-delegation > [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.org -- 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.org [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-GSS-API-PoC.patch --] [-- Type: text/x-patch; name="0001-GSS-API-PoC.patch", Size: 7469 bytes --] From 61e9ed9b811573ad02f4085979925a3d2b164762 Mon Sep 17 00:00:00 2001 From: Michael Weiser <michael.weiser@atos.net> Date: Tue, 5 Jan 2021 17:08:30 +0100 Subject: [PATCH] GSS-API PoC PoC to test out gssproxy usage through GSS-API. If no useable ticket cache or keytab can be found, fall on through into credential handling anyway but then divert into GSS routines. If no gssproxy is available this will still error out silently because no ticket cache is available. With gssproxy enabled, credentials can be retrieved from there and allow unattended access to shares e.g. from batch jobs. Signed-off-by: Michael Weiser <michael.weiser@atos.net> --- Makefile.am | 2 +- cifs.upcall.c | 149 +++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 141 insertions(+), 10 deletions(-) diff --git a/Makefile.am b/Makefile.am index 84dd119..38babb3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -31,7 +31,7 @@ sbin_PROGRAMS = if CONFIG_CIFSUPCALL sbin_PROGRAMS += cifs.upcall cifs_upcall_SOURCES = cifs.upcall.c data_blob.c asn1.c spnego.c -cifs_upcall_LDADD = -ltalloc -lkeyutils $(KRB5_LDADD) $(CAPNG_LDADD) +cifs_upcall_LDADD = -ltalloc -lkeyutils -lgssapi_krb5 $(KRB5_LDADD) $(CAPNG_LDADD) rst_man_pages += cifs.upcall.8 # # Fix the pathnames in manpages. To prevent @label@ being replaced by m4, we diff --git a/cifs.upcall.c b/cifs.upcall.c index 400b42d..1a4b1a6 100644 --- a/cifs.upcall.c +++ b/cifs.upcall.c @@ -36,6 +36,11 @@ #elif defined(HAVE_KRB5_H) #include <krb5.h> #endif + +#include <gssapi/gssapi_generic.h> +#include <gssapi/gssapi_krb5.h> +#include <sys/utsname.h> + #include <syslog.h> #include <dirent.h> #include <sys/types.h> @@ -457,6 +462,8 @@ icfk_cleanup: goto out; } +#define CIFS_SERVICE_NAME "cifs" + static int cifs_krb5_get_req(const char *host, krb5_ccache ccache, DATA_BLOB * mechtoken, DATA_BLOB * sess_key) @@ -478,8 +485,8 @@ cifs_krb5_get_req(const char *host, krb5_ccache ccache, return ret; } - ret = krb5_sname_to_principal(context, host, "cifs", KRB5_NT_UNKNOWN, - &in_creds.server); + ret = krb5_sname_to_principal(context, host, CIFS_SERVICE_NAME, + KRB5_NT_UNKNOWN, &in_creds.server); if (ret) { syslog(LOG_DEBUG, "%s: unable to convert sname to princ (%s).", __func__, host); @@ -578,6 +585,120 @@ out_free_principal: return ret; } +static void cifs_gss_display_status_1(char *m, OM_uint32 code, int type) { + OM_uint32 min_stat; + gss_buffer_desc msg; + OM_uint32 msg_ctx; + + msg_ctx = 0; + while (1) { + (void) gss_display_status(&min_stat, code, type, + GSS_C_NULL_OID, &msg_ctx, &msg); + syslog(LOG_DEBUG, "GSS-API error %s: %s\n", m, (char *) msg.value); + (void) gss_release_buffer(&min_stat, &msg); + + if (!msg_ctx) + break; + } +} + +void cifs_gss_display_status(char *msg, OM_uint32 maj_stat, OM_uint32 min_stat) { + cifs_gss_display_status_1(msg, maj_stat, GSS_C_GSS_CODE); + cifs_gss_display_status_1(msg, min_stat, GSS_C_MECH_CODE); +} + +static int +cifs_gss_get_req(const char *host, DATA_BLOB * mechtoken, DATA_BLOB * sess_key) +{ + OM_uint32 maj_stat, min_stat; + gss_name_t target_name; + gss_ctx_id_t ctx = GSS_C_NO_CONTEXT; + gss_buffer_desc output_token; + gss_krb5_lucid_context_v1_t *lucid_ctx = NULL; + gss_krb5_lucid_key_t *key = NULL; + + size_t service_name_len = sizeof(CIFS_SERVICE_NAME) + 1 /* @ */ + + strlen(host) + 1; + char *service_name = malloc(service_name_len); + if (!service_name) { + syslog(LOG_DEBUG, "out of memory allocating service name"); + goto out; + } + + snprintf(service_name, service_name_len, + "%s@%s", CIFS_SERVICE_NAME, host); + gss_buffer_desc target_name_buf; + target_name_buf.value = service_name; + target_name_buf.length = service_name_len; + + maj_stat = gss_import_name(&min_stat, &target_name_buf, + (gss_OID)gss_nt_service_name, &target_name); + free(service_name); + if (GSS_ERROR(maj_stat)) { + cifs_gss_display_status("gss_import_name", maj_stat, min_stat); + goto out; + } + + maj_stat = gss_init_sec_context(&min_stat, + GSS_C_NO_CREDENTIAL, /* claimant_cred_handle */ + &ctx, + target_name, + gss_mech_krb5, /* force krb5 */ + 0, /* flags */ + 0, /* time_req */ + GSS_C_NO_CHANNEL_BINDINGS, /* input_chan_bindings */ + GSS_C_NO_BUFFER, + NULL, /* actual mech type */ + &output_token, + NULL, /* ret_flags */ + NULL); /* time_rec */ + if (maj_stat != GSS_S_COMPLETE && + maj_stat != GSS_S_CONTINUE_NEEDED) { + cifs_gss_display_status("init_sec_context", maj_stat, min_stat); + goto out_release_target_name; + } + + /* as luck would have it, GSS-API hands us the finished article */ + *mechtoken = data_blob(output_token.value, output_token.length); + + maj_stat = gss_krb5_export_lucid_sec_context(&min_stat, &ctx, 1, + (void **)&lucid_ctx); + if (GSS_ERROR(maj_stat)) { + cifs_gss_display_status("gss_krb5_export_lucid_sec_context", + maj_stat, min_stat); + goto out_free_sec_ctx; + } + + switch (lucid_ctx->protocol) { + case 0: + key = &lucid_ctx->rfc1964_kd.ctx_key; + break; + + case 1: + if (lucid_ctx->cfx_kd.have_acceptor_subkey) { + key = &lucid_ctx->cfx_kd.acceptor_subkey; + } else { + key = &lucid_ctx->cfx_kd.ctx_key; + } + break; + default: + syslog(LOG_DEBUG, "wrong lucid context protocol %d", lucid_ctx->protocol); + goto out_free_lucid_ctx; + } + + *sess_key = data_blob(key->data, key->length); + +out_free_lucid_ctx: + (void) gss_krb5_free_lucid_sec_context(&min_stat, lucid_ctx); +out_free_sec_ctx: + (void) gss_delete_sec_context(&min_stat, &ctx, GSS_C_NO_BUFFER); + (void) gss_release_buffer(&min_stat, &output_token); +out_release_target_name: + (void) gss_release_name(&min_stat, &target_name); +out: + return GSS_ERROR(maj_stat); +} + /* * Prepares AP-REQ data for mechToken and gets session key * Uses credentials from cache. It will not ask for password @@ -603,10 +724,24 @@ handle_krb5_mech(const char *oid, const char *host, DATA_BLOB * secblob, DATA_BLOB * sess_key, krb5_ccache ccache) { int retval; - DATA_BLOB tkt, tkt_wrapped; + DATA_BLOB tkt_wrapped; syslog(LOG_DEBUG, "%s: getting service ticket for %s", __func__, host); + /* fall back to gssapi if there's no credential cache or no TGT + * so that gssproxy can maybe help out */ + if (!ccache) { + syslog(LOG_DEBUG, "%s: using GSS-API", __func__); + retval = cifs_gss_get_req(host, &tkt_wrapped, sess_key); + if (retval) { + syslog(LOG_DEBUG, "%s: failed to obtain service ticket via GSS (%d)", + __func__, retval); + return retval; + } + } else { + DATA_BLOB tkt; + syslog(LOG_DEBUG, "%s: using native krb5", __func__); + /* get a kerberos ticket for the service and extract the session key */ retval = cifs_krb5_get_req(host, ccache, &tkt, sess_key); if (retval) { @@ -619,12 +754,13 @@ handle_krb5_mech(const char *oid, const char *host, DATA_BLOB * secblob, /* wrap that up in a nice GSS-API wrapping */ tkt_wrapped = spnego_gen_krb5_wrap(tkt, TOK_ID_KRB_AP_REQ); + data_blob_free(&tkt); + } /* and wrap that in a shiny SPNEGO wrapper */ *secblob = gen_negTokenInit(oid, tkt_wrapped); data_blob_free(&tkt_wrapped); - data_blob_free(&tkt); return retval; } @@ -1132,11 +1268,6 @@ int main(const int argc, char *const argv[]) if (ccache == NULL && arg.username != NULL) ccache = init_cc_from_keytab(keytab_name, arg.username); - if (ccache == NULL) { - rc = 1; - goto out; - } - host = arg.hostname; // do mech specific authorization -- 2.29.2 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: 0001-Handle-impersonation-of-oneself.patch --] [-- Type: text/x-patch; name="0001-Handle-impersonation-of-oneself.patch", Size: 3044 bytes --] From 2db433a9998dceca7f2dfac8b0b1c8f097aed488 Mon Sep 17 00:00:00 2001 From: Michael Weiser <michael.weiser@atos.net> Date: Thu, 7 Jan 2021 10:34:15 +0100 Subject: [PATCH] Handle impersonation of oneself When trying to impersonate the user which has been selected as impersonation credential, an AD KDC returns error: GSSX_RES_ACQUIRE_CRED( status: { 851968 { 1 2 840 113554 1 2 2 } 2529638928 "Unspecified GSS failure. Minor code may provide more information" "KDC has no support for padata type" [ ] } output_cred_handle: <Null> ) Apparently, to impersonate oneself is not allowed. Also, it is likely not even necessary: If we can get impersonation credentials from credstores, we can at least try to short circuit and get actual user credentials the same way. With this patch it becomes possible to delegate the acquisition of e.g. cifs mount credentials from cifs.upcall into gssproxy and use the host identity (e.g. HOSTNAME$@REALM of AD) while it is also being selected as impersonation credential due to the order of keys in the keytab. Signed-off-by: Michael Weiser <michael.weiser@atos.net> --- src/gp_creds.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/src/gp_creds.c b/src/gp_creds.c index 424cf35..14ab364 100644 --- a/src/gp_creds.c +++ b/src/gp_creds.c @@ -667,6 +667,41 @@ uint32_t gp_add_krb5_creds(uint32_t *min, if (ret_maj) { goto done; } + + if (req_name != GSS_C_NO_NAME) { + int equal = 0; + + ret_maj = gss_inquire_cred(&ret_min, impersonator_cred, + &target_name, NULL, NULL, NULL); + if (ret_maj) { + goto done; + } + + ret_maj = gss_compare_name(&ret_min, target_name, + req_name, &equal); + if (ret_maj) { + goto done; + } + + /* if impersonator credential retrieval yielded the requested client + * name, we do not need to impersonate. Also, in AD an attempt to + * impersonate oneself yields an error "KDC has no support for padata + * type" */ + if (equal) { + ret_maj = gss_acquire_cred_from(&ret_min, req_name, GSS_C_INDEFINITE, + &desired_mechs, cred_usage, + &cred_store, &user_cred, + actual_mechs, NULL); + if (!ret_maj) { + *output_cred_handle = user_cred; + user_cred = GSS_C_NO_CREDENTIAL; + goto done; + } + + /* fall on through, if failed */ + } + } + input_cred = impersonator_cred; break; case ACQ_IMPNAME: -- 2.29.2 ^ permalink raw reply related [flat|nested] 28+ messages in thread
[parent not found: <2d5a7cf3b6e8e31db010f6a3d159109ca48ca998.camel@samba.org>]
* Re: [gssproxy] Re: cifs-utils, Linux cifs kernel client and gssproxy [not found] ` <2d5a7cf3b6e8e31db010f6a3d159109ca48ca998.camel@samba.org> @ 2021-01-07 13:45 ` Simo 0 siblings, 0 replies; 28+ messages in thread From: Simo @ 2021-01-07 13:45 UTC (permalink / raw) To: samba-technical Cc: Weiser, Michael, linux-cifs, Steve French, The GSS-Proxy developers and users mailing list Adding back missing people in CC, as I incorrectly pressed reply-to- list and lost them. On Thu, 2021-01-07 at 08:37 -0500, Simo via samba-technical wrote: > On Thu, 2021-01-07 at 11:04 +0000, Weiser, Michael via samba- > technical > 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? > > Sounds great! > > > > 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? > > Yes! > CC me if you need to. > > > 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. > > Sounds like a bug in gss-proxy, can you file a github issue/PR ? > We should certainly shortcut the impersonation if we already have a > valid credential. > > > 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? > > Yes the patch looks good! > > > Is it sane, security wise, do you think? > > Sane, you are just avoiding a useless call in a special case. > > Simo. > > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] Re: cifs-utils, Linux cifs kernel client and gssproxy 2021-01-07 11:04 ` [gssproxy] " Weiser, Michael [not found] ` <2d5a7cf3b6e8e31db010f6a3d159109ca48ca998.camel@samba.org> @ 2021-02-19 11:26 ` Shyam Prasad N 2021-02-19 14:10 ` Weiser, Michael 2021-02-19 17:34 ` Simo Sorce 1 sibling, 2 replies; 28+ messages in thread From: Shyam Prasad N @ 2021-02-19 11:26 UTC (permalink / raw) To: Weiser, Michael Cc: Steve French, Simo Sorce, samba-technical, linux-cifs, The GSS-Proxy developers and users mailing list 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-via-constrained-delegation > > [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.org > > -- > 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.org -- Regards, Shyam ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] Re: cifs-utils, Linux cifs kernel client and gssproxy 2021-02-19 11:26 ` Shyam Prasad N @ 2021-02-19 14:10 ` Weiser, Michael 2021-02-19 17:34 ` Simo Sorce 1 sibling, 0 replies; 28+ messages in thread From: Weiser, Michael @ 2021-02-19 14:10 UTC (permalink / raw) To: Shyam Prasad N Cc: Steve French, The GSS-Proxy developers and users mailing list, Simo Sorce, linux-cifs Hi Shyam, > What happens when credentials are not supplied in keytab files? Is > there a way to supply the credentials from other sources in that case? In my scenario, gssproxy has a single keytab with its own machine/service identity (actually just /etc/krb5.keytab and machine$@REALM) that is allowed to impersonate users, i.e. retrieve service tickets made out to user identities without obtaining a TGT for the respective user identity first. When dealing with end-users, the option of having user-specific keytabs is IMO quite impractical because the keytabs would need updating on every password change. For machine-to-machine communication accounts with static passwords could have keytabs and those could be under gssproxy's supervision and with additional hardening (SELinux?) cifs.upcall could even be prevented from having direct access to them and only ever get the cifs service ticket it actually needs to function. > 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. I understand cifscreds "pushes" credentials, i.e. the user's password, into the kernel so it can log on to services as that user at any given point in time. This works because the password is valid for days or weeks at a time and works with multiple servers. Kerberos tickets usually expire after some hours and need to be made out to specific target services/servers. So cifscreds (or the new executable) would also need an option to specify the service for which the user wants to push a credential into the kernel for and it'd need to be called repeatedly to refresh that ticket. This would somewhat limits its usefulness, IMO. The benefit would be that users could explicitly specify the identity they wanted to use - so long as the user is actually doing the retrieving of the credential and needs to authenticate for that. In the case of impersonation by gssproxy this becomes tricky because gssproxy needs to make sure that users can't just claim any identity. So the user would need to authenticate to gssproxy somehow which (due to the ephemeral nature of Kerberos tickets) would likely require it to become more stateful or configurable, i.e. somehow know that uid 10012 is allowed to use identities alice@REALM and bob@REALM. > 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. I was thinking about that as well and am still somewhat unsure how to best do it. rpc.gssd is going at it the other way around[2]: A config file option lets the user explicitly enable usage of gssproxy and rpc.gssd sets the variable to enable the functionality. cifs.upcall could have a command line option for that (and another to optionally specify a non-default socket). The advantage would be that there's no cryptic variable-setting syntax to be added to request-key's cifs.spnego.conf but just additional straightforward command-line option(s). The downside is that it cements the GSS_USE_PROXY variable into yet another executable. I wonder, how the gssproxy team had intended this to be done. Simo? [2] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/gssd/gssd.c;h=85bc4b07bebde05eabdce9b85a1da8bbd82bcede;hb=HEAD#l1030 > Other than that, the changes look fine to me. Thanks for your feedback! -- Thanks, Michael ________________________________________ From: samba-technical <samba-technical-bounces@lists.samba.org> on behalf of Shyam Prasad N via samba-technical <samba-technical@lists.samba.org> Sent: 19 February 2021 12:26:53 To: Weiser, Michael Cc: Steve French; The GSS-Proxy developers and users mailing list; samba-technical@lists.samba.org; Simo Sorce; linux-cifs@vger.kernel.org Subject: Re: [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, 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-via-constrained-delegation > > [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.org > > -- > 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.org -- Regards, Shyam ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [gssproxy] Re: cifs-utils, Linux cifs kernel client and gssproxy 2021-02-19 11:26 ` Shyam Prasad N 2021-02-19 14:10 ` Weiser, Michael @ 2021-02-19 17:34 ` Simo Sorce 1 sibling, 0 replies; 28+ messages in thread From: Simo Sorce @ 2021-02-19 17:34 UTC (permalink / raw) To: Shyam Prasad N, Weiser, Michael Cc: Steve French, samba-technical, linux-cifs, The GSS-Proxy developers and users mailing list 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-via-constrained-delegation > > > [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.org > > > > -- > > 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.org > > -- Simo Sorce RHEL Crypto Team Red Hat, Inc ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2021-11-05 0:31 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-16 10:01 cifs-utils, Linux cifs kernel client and gssproxy Weiser, Michael 2020-12-16 14:31 ` [gssproxy] " Simo Sorce 2020-12-16 22:43 ` Steve French 2020-12-17 13:39 ` Simo Sorce 2020-12-17 21:22 ` Steve French 2020-12-17 21:25 ` Steve French 2020-12-17 21:53 ` Simo Sorce 2020-12-17 21:49 ` Simo Sorce 2021-02-19 11:30 ` Shyam Prasad N 2021-02-19 17:35 ` Simo Sorce 2021-02-23 17:42 ` Jacob Shivers 2021-02-23 19:54 ` Simo Sorce 2021-03-05 21:29 ` Jacob Shivers 2021-03-05 22:19 ` Simo Sorce 2021-04-13 23:53 ` ronnie sahlberg 2021-09-24 17:09 ` Pavel Shilovsky 2021-09-25 7:28 ` ronnie sahlberg 2021-09-27 7:18 ` Weiser, Michael 2021-09-30 23:17 ` Jacob Shivers 2021-10-21 23:23 ` Pavel Shilovsky [not found] ` <CAGvGhF5rVU1WzLk=aE36n47P357UBOPbsjXE=B8J+feO3bVSSQ@mail.gmail.com> [not found] ` <CALe0_77Bv_+v9cdNd_AL5DgA2+EaXMtF_0+rUw6y46fhHq0M4A@mail.gmail.com> [not found] ` <CAKywueQU8P-XQsiy4x6B=0YjuwUmTzPVg--SY0sWzGuq6Oy_-w@mail.gmail.com> 2021-10-26 10:08 ` Weiser, Michael 2021-10-26 15:05 ` Jacob Shivers 2021-11-05 0:31 ` Pavel Shilovsky 2021-01-07 11:04 ` [gssproxy] " Weiser, Michael [not found] ` <2d5a7cf3b6e8e31db010f6a3d159109ca48ca998.camel@samba.org> 2021-01-07 13:45 ` Simo 2021-02-19 11:26 ` Shyam Prasad N 2021-02-19 14:10 ` Weiser, Michael 2021-02-19 17:34 ` Simo Sorce
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).