cifs-utils, Linux cifs kernel client and gssproxy

cifs-utils, Linux cifs kernel client and gssproxy

[Weiser, Michael]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Simo Sorce]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Steve French]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Simo Sorce]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Steve French]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Steve French]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Simo Sorce]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Simo Sorce]

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

Re: [gssproxy] Re: cifs-utils, Linux cifs kernel client and gssproxy

[Weiser, Michael]

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

Re: [gssproxy] Re: cifs-utils, Linux cifs kernel client and gssproxy

[Simo]

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

Re: [gssproxy] Re: cifs-utils, Linux cifs kernel client and gssproxy

[Shyam Prasad N]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Shyam Prasad N]

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

Re: [gssproxy] Re: cifs-utils, Linux cifs kernel client and gssproxy

[Weiser, Michael]

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

Re: [gssproxy] Re: cifs-utils, Linux cifs kernel client and gssproxy

[Simo Sorce]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Simo Sorce]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Jacob Shivers]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Simo Sorce]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Jacob Shivers]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Simo Sorce]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[ronnie sahlberg]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Pavel Shilovsky]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[ronnie sahlberg]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Weiser, Michael]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Jacob Shivers]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Pavel Shilovsky]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Weiser, Michael]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Jacob Shivers]

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

Re: [gssproxy] cifs-utils, Linux cifs kernel client and gssproxy

[Pavel Shilovsky]

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