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

[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-impersonati...
>  [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(a)lists.fedorahosted.org
>  To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]... 
-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[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(a)redhat.com&gt; 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-impersonati...
>  > [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(a)lists.fedorahosted.org
>  > To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]...
>
>  --
>  Simo Sorce
>  RHEL Crypto Team
>  Red Hat, Inc
>
>
>
>  

-- 
Thanks,

Steve

[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(a)redhat.com&gt; 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-impersonati...
>  > > [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(a)lists.fedorahosted.org
>  > > To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]...
>  > 
>  > --
>  > Simo Sorce
>  > RHEL Crypto Team
>  > Red Hat, Inc
>  > 
>  > 
>  > 
>  > 
>  
>   
-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
>  > > > [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(a)lists.fedorahosted.org
>  > > > To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]...
>  > >
>  > > --
>  > > Simo Sorce
>  > > RHEL Crypto Team
>  > > Red Hat, Inc
>  > >
>  > >
>  > >
>  > >
>  >
>  >
>
>  --
>  Simo Sorce
>  RHEL Crypto Team
>  Red Hat, Inc
>
>
>
>  

-- 
Thanks,

Steve

[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(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
>  > > > > [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(a)lists.fedorahosted.org
>  > > > > To unsubscribe send an email to
> gss-proxy-leave(a)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/[e-mail]...
>  > > >
>  > > > --
>  > > > Simo Sorce
>  > > > RHEL Crypto Team
>  > > > Red Hat, Inc
>  > > >
>  > > >
>  > > >
>  > > >
>  > >
>  > >
>  >
>  > --
>  > Simo Sorce
>  > RHEL Crypto Team
>  > Red Hat, Inc
>  >
>  >
>  >
>  >
>
>
>  --
>  Thanks,
>
>  Steve 


-- 
Thanks,

Steve

[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(a)redhat.com&gt;
> 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(a)redhat.com&gt; 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-impersonati...
>  > > > > [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(a)lists.fedorahosted.org
>  > > > > To unsubscribe send an email to
> gss-proxy-leave(a)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/[e-mail]...
>  > > > 
>  > > > --
>  > > > 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]

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(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
>  > > > > > [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(a)lists.fedorahosted.org
>  > > > > > To unsubscribe send an email to
> gss-proxy-leave(a)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/[e-mail]...
>  > > > > 
>  > > > > --
>  > > > > 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

[Weiser, Michael]

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(a)redhat.com&gt;
Sent: 16 December 2020 15:31:40
To: The GSS-Proxy developers and users mailing list; linux-cifs(a)vger.kernel.org
Cc: samba-technical(a)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-impersonati...
>  [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(a)lists.fedorahosted.org
>  To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]... 
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



_______________________________________________
gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]...

[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(a)atos.net&gt; 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(a)redhat.com&gt;
>  Sent: 16 December 2020 15:31:40
>  To: The GSS-Proxy developers and users mailing list; linux-cifs(a)vger.kernel.org
>  Cc: samba-technical(a)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-impersonati...
>  > [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(a)lists.fedorahosted.org
>  > To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]...
>
>  --
>  Simo Sorce
>  RHEL Crypto Team
>  Red Hat, Inc
>
>
>
>  _______________________________________________
>  gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
>  To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]... 


-- 
Regards,
Shyam

[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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
> > > > [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(a)lists.fedorahosted.org
> > > > To unsubscribe send an email to
gss-proxy-leave(a)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/[e-mail]...
> > >
> > > --
> > > Simo Sorce
> > > RHEL Crypto Team
> > > Red Hat, Inc
> > >
> > >
> > >
> > >
> >
> >
>
> --
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
>
>
>
>


-- 
Regards,
Shyam

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

>  Other than that, the changes look fine to me. 
Thanks for your feedback!
--
Thanks,
Michael
________________________________________
From: samba-technical <samba-technical-bounces(a)lists.samba.org&gt; on behalf of Shyam
Prasad N via samba-technical <samba-technical(a)lists.samba.org&gt;
Sent: 19 February 2021 12:26:53
To: Weiser, Michael
Cc: Steve French; The GSS-Proxy developers and users mailing list;
samba-technical(a)lists.samba.org; Simo Sorce; linux-cifs(a)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(a)atos.net&gt; 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(a)redhat.com&gt;
>  Sent: 16 December 2020 15:31:40
>  To: The GSS-Proxy developers and users mailing list; linux-cifs(a)vger.kernel.org
>  Cc: samba-technical(a)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-impersonati...
>  > [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(a)lists.fedorahosted.org
>  > To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]...
>
>  --
>  Simo Sorce
>  RHEL Crypto Team
>  Red Hat, Inc
>
>
>
>  _______________________________________________
>  gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
>  To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]... 


--
Regards,
Shyam

[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(a)atos.net&gt; 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(a)redhat.com&gt;
>  > Sent: 16 December 2020 15:31:40
>  > To: The GSS-Proxy developers and users mailing list; linux-cifs(a)vger.kernel.org
>  > Cc: samba-technical(a)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-impersonati...
>  > > [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(a)lists.fedorahosted.org
>  > > To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]...
>  > 
>  > --
>  > Simo Sorce
>  > RHEL Crypto Team
>  > Red Hat, Inc
>  > 
>  > 
>  > 
>  > _______________________________________________
>  > gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
>  > To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]...
>  
>   
-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
>  > > > > [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(a)lists.fedorahosted.org
>  > > > > To unsubscribe send an email to
> gss-proxy-leave(a)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/[e-mail]...
>  > > > 
>  > > > --
>  > > > Simo Sorce
>  > > > RHEL Crypto Team
>  > > > Red Hat, Inc
>  > > > 
>  > > > 
>  > > > 
>  > > > 
>  > 
>  > --
>  > Simo Sorce
>  > RHEL Crypto Team
>  > Red Hat, Inc
>  > 
>  > 
>  > 
>  > 
>  
>   
-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[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$(a)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: { &quot;chang(a)EXAMPLE.NET&quot; [ { &quot;chang(a)EXAMPLE.NET&quot;
{ 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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot; { 1
2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot; 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 } &quot;chang(a)EXAMPLE.NET&quot;
&quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
>  > > > > > [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(a)lists.fedorahosted.org
>  > > > > > To unsubscribe send an email to
> gss-proxy-leave(a)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/[e-mail]...
>  > > > >
>  > > > > --
>  > > > > 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]

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$(a)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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)EXAMPLE.NET&quot;
>  { 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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)EXAMPLE.NET&quot; { 1
>  2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
>  target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot; 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 } &quot;chang(a)EXAMPLE.NET&quot;
>  &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt;
> 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-impersonati...
>  > > > > > > [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(a)lists.fedorahosted.org
>  > > > > > > To unsubscribe send an email to
> gss-proxy-leave(a)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/[e-mail]...
>  > > > > > 
>  > > > > > --
>  > > > > > 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

gssproxy repeating errors from gdm

[Jason Keltz]

Hi.

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

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

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

Thanks,

Jason.

gssproxy repeating errors from gdm

[Simo Sorce]

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

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

gssproxy repeating errors from gdm

[Jason Keltz]

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

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

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

Where would I look?

Jason.

gssproxy repeating errors from gdm

[Simo Sorce]

On Tue, 2021-03-02 at 16:57 -0500, Jason Keltz wrote:
>  On 3/2/2021 4:48 PM, Simo Sorce wrote:
>  > On Tue, 2021-03-02 at 15:46 -0500, Jason Keltz wrote:
>  > > Hi.
>  > > 
>  > > I'm running gssproxy on many hosts with CentOS 7.9.  gssproxy is
>  > > constantly generating this error in syslog for every host, repeatedly:
>  > > 
>  > > Mar 02 15:41:53 sel01 gssproxy[977]: (OID: { 1 2 840 113554 1 2 2 })
>  > > Unspecified GSS failure.  Minor code may provide more information, No
>  > > creden...che found
>  > > Mar 02 15:41:53 sel01 gssproxy[881]: gssproxy[977]: (OID: { 1 2 840
>  > > 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more
>  > > informa...che found
>  > > M
>  > > 
>  > > Looking in more detail,  it's constantly trying to open
>  > > /var/lib/gssproxy/clients/krb5cc_42.  UID 42 is gdm.  It's a local user
>  > > not in Kerberos.  When I strace the gdm process, I don't see it
>  > > constantly trying to access any particular share that would required
>  > > Kerberos.  I want gssproxy to completely ignore gdm altogether.  How
>  > > would I go about doing this?
>  > So normally the GSS-Proxy mechglue is not invoked at all, as it is
>  > dependent on having an envronment variable set up.
>  > Did you set the env var to enable gssproxy system wide ?
>  > It is normally preferred to prepend it only for applications that you
>  > want to intercept by modifying unit files individually.
>  
>  Hi Simo,
>  
>  All the clients are running gssproxy by default.  As far as I know, I 
>  haven't changed anything at all except adding to 99-nfs-client.conf 
>  krb5_principal.
>  
>  I assumed this was the default behaviour. /etc/gssproxy/gssproxy.conf 
>  contains nothing but "[gssproxy]".
>  
>  Where would I look? 
Ah NFS, well what is seem to be happening is that GDM is trying to
access some NFS mounts, and causing the NFS client to try to
authenticate on behalf of the gdm user.

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

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

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

HTH,
Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

gssproxy repeating errors from gdm

[Jason Keltz]

On 3/3/2021 10:38 AM, Simo Sorce wrote:
>  On Tue, 2021-03-02 at 16:57 -0500, Jason Keltz wrote:
> > On 3/2/2021 4:48 PM, Simo Sorce wrote:
> >> On Tue, 2021-03-02 at 15:46 -0500, Jason Keltz wrote:
> >>> Hi.
> >>>
> >>> I'm running gssproxy on many hosts with CentOS 7.9.  gssproxy is
> >>> constantly generating this error in syslog for every host, repeatedly:
> >>>
> >>> Mar 02 15:41:53 sel01 gssproxy[977]: (OID: { 1 2 840 113554 1 2 2 })
> >>> Unspecified GSS failure.  Minor code may provide more information, No
> >>> creden...che found
> >>> Mar 02 15:41:53 sel01 gssproxy[881]: gssproxy[977]: (OID: { 1 2 840
> >>> 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more
> >>> informa...che found
> >>> M
> >>>
> >>> Looking in more detail,  it's constantly trying to open
> >>> /var/lib/gssproxy/clients/krb5cc_42.  UID 42 is gdm.  It's a local user
> >>> not in Kerberos.  When I strace the gdm process, I don't see it
> >>> constantly trying to access any particular share that would required
> >>> Kerberos.  I want gssproxy to completely ignore gdm altogether.  How
> >>> would I go about doing this?
> >> So normally the GSS-Proxy mechglue is not invoked at all, as it is
> >> dependent on having an envronment variable set up.
> >> Did you set the env var to enable gssproxy system wide ?
> >> It is normally preferred to prepend it only for applications that you
> >> want to intercept by modifying unit files individually.
> > Hi Simo,
> >
> > All the clients are running gssproxy by default.  As far as I know, I
> > haven't changed anything at all except adding to 99-nfs-client.conf
> > krb5_principal.
> >
> > I assumed this was the default behaviour. /etc/gssproxy/gssproxy.conf
> > contains nothing but "[gssproxy]".
> >
> > Where would I look?
>  Ah NFS, well what is seem to be happening is that GDM is trying to
>  access some NFS mounts, and causing the NFS client to try to
>  authenticate on behalf of the gdm user.
>
>  I assume gdm is trying to check some user home directory you mount over
>  NFS?
>
>  If that's the case (and you want to grant gdm the ability to perform
>  those accesses) you could define an additional configuration section
>  for NFS in gssproxy.conf with euid=42
>
>  As that is a more specific configuration it should match first, you can
>  then configure it to let gdm use the host keytab for authentication
>  (using the machine krb5 principal), this will generally end up granting
>  "nobody" user access on the NFS server, or similar (depending on your
>  id mapping configuration there. 
Hi Simo,

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

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

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

Jason.

gssproxy repeating errors from gdm

[Simo Sorce]

On Wed, 2021-03-03 at 11:26 -0500, Jason Keltz wrote:
>  On 3/3/2021 10:38 AM, Simo Sorce wrote:
>  > On Tue, 2021-03-02 at 16:57 -0500, Jason Keltz wrote:
>  > > On 3/2/2021 4:48 PM, Simo Sorce wrote:
>  > > > On Tue, 2021-03-02 at 15:46 -0500, Jason Keltz wrote:
>  > > > > Hi.
>  > > > > 
>  > > > > I'm running gssproxy on many hosts with CentOS 7.9.  gssproxy is
>  > > > > constantly generating this error in syslog for every host,
> repeatedly:
>  > > > > 
>  > > > > Mar 02 15:41:53 sel01 gssproxy[977]: (OID: { 1 2 840 113554 1 2 2 })
>  > > > > Unspecified GSS failure.  Minor code may provide more information,
> No
>  > > > > creden...che found
>  > > > > Mar 02 15:41:53 sel01 gssproxy[881]: gssproxy[977]: (OID: { 1 2 840
>  > > > > 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide
> more
>  > > > > informa...che found
>  > > > > M
>  > > > > 
>  > > > > Looking in more detail,  it's constantly trying to open
>  > > > > /var/lib/gssproxy/clients/krb5cc_42.  UID 42 is gdm.  It's a
> local user
>  > > > > not in Kerberos.  When I strace the gdm process, I don't see it
>  > > > > constantly trying to access any particular share that would required
>  > > > > Kerberos.  I want gssproxy to completely ignore gdm altogether.  How
>  > > > > would I go about doing this?
>  > > > So normally the GSS-Proxy mechglue is not invoked at all, as it is
>  > > > dependent on having an envronment variable set up.
>  > > > Did you set the env var to enable gssproxy system wide ?
>  > > > It is normally preferred to prepend it only for applications that you
>  > > > want to intercept by modifying unit files individually.
>  > > Hi Simo,
>  > > 
>  > > All the clients are running gssproxy by default.  As far as I know, I
>  > > haven't changed anything at all except adding to 99-nfs-client.conf
>  > > krb5_principal.
>  > > 
>  > > I assumed this was the default behaviour. /etc/gssproxy/gssproxy.conf
>  > > contains nothing but "[gssproxy]".
>  > > 
>  > > Where would I look?
>  > Ah NFS, well what is seem to be happening is that GDM is trying to
>  > access some NFS mounts, and causing the NFS client to try to
>  > authenticate on behalf of the gdm user.
>  > 
>  > I assume gdm is trying to check some user home directory you mount over
>  > NFS?
>  > 
>  > If that's the case (and you want to grant gdm the ability to perform
>  > those accesses) you could define an additional configuration section
>  > for NFS in gssproxy.conf with euid=42
>  > 
>  > As that is a more specific configuration it should match first, you can
>  > then configure it to let gdm use the host keytab for authentication
>  > (using the machine krb5 principal), this will generally end up granting
>  > "nobody" user access on the NFS server, or similar (depending on your
>  > id mapping configuration there.
>  
>  Hi Simo,
>  
>  I assume, as you said, that gdm is trying to access the NFS home 
>  directories, but why would it be doing that?  GDM home directory is not 
>  on an NFS share.  Before a user logs in, it's not clear what it would be 
>  doing over and over again.   Any idea how I could track it (and stop it)?
>  
>  Before login, GDM, I assume should only read the Init startup. Init does 
>  indeed refer to some NFS mounts.  However, Init runs as root, and root 
>  is mapped to the machine account.  I've verified that those accesses are 
>  by root, and they work exactly as expected getting the proper access.
>  
>  Rather than giving gdm user access to the share, can I tell gssproxy to 
>  ignore requests from this user instead?  I'd like to know what it's 
>  doing and why.  I'm just not sure how to find it. 
We do not have a way in gssproxy to drop requests on the floor at this
time, unfortunately.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

gssproxy repeating errors from gdm

[Jason Keltz]

On 3/3/2021 12:20 PM, Simo Sorce wrote:
>  On Wed, 2021-03-03 at 11:26 -0500, Jason Keltz wrote:
> > On 3/3/2021 10:38 AM, Simo Sorce wrote:
> >> On Tue, 2021-03-02 at 16:57 -0500, Jason Keltz wrote:
> >>> On 3/2/2021 4:48 PM, Simo Sorce wrote:
> >>>> On Tue, 2021-03-02 at 15:46 -0500, Jason Keltz wrote:
> >>>>> Hi.
> >>>>>
> >>>>> I'm running gssproxy on many hosts with CentOS 7.9.  gssproxy is
> >>>>> constantly generating this error in syslog for every host,
> repeatedly:
> >>>>>
> >>>>> Mar 02 15:41:53 sel01 gssproxy[977]: (OID: { 1 2 840 113554 1 2 2 })
> >>>>> Unspecified GSS failure.  Minor code may provide more information,
> No
> >>>>> creden...che found
> >>>>> Mar 02 15:41:53 sel01 gssproxy[881]: gssproxy[977]: (OID: { 1 2 840
> >>>>> 113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide
> more
> >>>>> informa...che found
> >>>>> M
> >>>>>
> >>>>> Looking in more detail,  it's constantly trying to open
> >>>>> /var/lib/gssproxy/clients/krb5cc_42.  UID 42 is gdm.  It's a
> local user
> >>>>> not in Kerberos.  When I strace the gdm process, I don't see it
> >>>>> constantly trying to access any particular share that would required
> >>>>> Kerberos.  I want gssproxy to completely ignore gdm altogether.  How
> >>>>> would I go about doing this?
> >>>> So normally the GSS-Proxy mechglue is not invoked at all, as it is
> >>>> dependent on having an envronment variable set up.
> >>>> Did you set the env var to enable gssproxy system wide ?
> >>>> It is normally preferred to prepend it only for applications that you
> >>>> want to intercept by modifying unit files individually.
> >>> Hi Simo,
> >>>
> >>> All the clients are running gssproxy by default.  As far as I know, I
> >>> haven't changed anything at all except adding to 99-nfs-client.conf
> >>> krb5_principal.
> >>>
> >>> I assumed this was the default behaviour. /etc/gssproxy/gssproxy.conf
> >>> contains nothing but "[gssproxy]".
> >>>
> >>> Where would I look?
> >> Ah NFS, well what is seem to be happening is that GDM is trying to
> >> access some NFS mounts, and causing the NFS client to try to
> >> authenticate on behalf of the gdm user.
> >>
> >> I assume gdm is trying to check some user home directory you mount over
> >> NFS?
> >>
> >> If that's the case (and you want to grant gdm the ability to perform
> >> those accesses) you could define an additional configuration section
> >> for NFS in gssproxy.conf with euid=42
> >>
> >> As that is a more specific configuration it should match first, you can
> >> then configure it to let gdm use the host keytab for authentication
> >> (using the machine krb5 principal), this will generally end up granting
> >> "nobody" user access on the NFS server, or similar (depending on your
> >> id mapping configuration there.
> > Hi Simo,
> >
> > I assume, as you said, that gdm is trying to access the NFS home
> > directories, but why would it be doing that?  GDM home directory is not
> > on an NFS share.  Before a user logs in, it's not clear what it would be
> > doing over and over again.   Any idea how I could track it (and stop it)?
> >
> > Before login, GDM, I assume should only read the Init startup. Init does
> > indeed refer to some NFS mounts.  However, Init runs as root, and root
> > is mapped to the machine account.  I've verified that those accesses are
> > by root, and they work exactly as expected getting the proper access.
> >
> > Rather than giving gdm user access to the share, can I tell gssproxy to
> > ignore requests from this user instead?  I'd like to know what it's
> > doing and why.  I'm just not sure how to find it.
>  We do not have a way in gssproxy to drop requests on the floor at this
>  time, unfortunately. 
I figured out that /etc/fonts/local.conf included a font from the NFS 
share which was causing gdm to constantly try the share, and gssproxy to 
constantly bang on syslog.  I resolved that, and the constant errors 
generated from gdm went away.  When I reboot the machine, I see no  
gssproxy errors.  However,  when any user logs in, I see a few 
"Unspecified GSS failure" errors, but my home directory is mounted, and 
everything is fine.  Why would I get these errors?

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

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

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

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

Jason.

gssproxy repeating errors from gdm

[Simo Sorce]

On Wed, 2021-03-03 at 16:28 -0500, Jason Keltz wrote:
>  On 3/3/2021 12:20 PM, Simo Sorce wrote:
>  > On Wed, 2021-03-03 at 11:26 -0500, Jason Keltz wrote:
>  > > On 3/3/2021 10:38 AM, Simo Sorce wrote:
>  > > > On Tue, 2021-03-02 at 16:57 -0500, Jason Keltz wrote:
>  > > > > On 3/2/2021 4:48 PM, Simo Sorce wrote:
>  > > > > > On Tue, 2021-03-02 at 15:46 -0500, Jason Keltz wrote:
>  > > > > > > Hi.
>  > > > > > > 
>  > > > > > > I'm running gssproxy on many hosts with CentOS 7.9. 
> gssproxy is
>  > > > > > > constantly generating this error in syslog for every host,
> repeatedly:
>  > > > > > > 
>  > > > > > > Mar 02 15:41:53 sel01 gssproxy[977]: (OID: { 1 2 840 113554
> 1 2 2 })
>  > > > > > > Unspecified GSS failure.  Minor code may provide more
> information, No
>  > > > > > > creden...che found
>  > > > > > > Mar 02 15:41:53 sel01 gssproxy[881]: gssproxy[977]: (OID: {
> 1 2 840
>  > > > > > > 113554 1 2 2 }) Unspecified GSS failure.  Minor code may
> provide more
>  > > > > > > informa...che found
>  > > > > > > M
>  > > > > > > 
>  > > > > > > Looking in more detail,  it's constantly trying to
> open
>  > > > > > > /var/lib/gssproxy/clients/krb5cc_42.  UID 42 is gdm. 
> It's a local user
>  > > > > > > not in Kerberos.  When I strace the gdm process, I
> don't see it
>  > > > > > > constantly trying to access any particular share that would
> required
>  > > > > > > Kerberos.  I want gssproxy to completely ignore gdm
> altogether.  How
>  > > > > > > would I go about doing this?
>  > > > > > So normally the GSS-Proxy mechglue is not invoked at all, as it
> is
>  > > > > > dependent on having an envronment variable set up.
>  > > > > > Did you set the env var to enable gssproxy system wide ?
>  > > > > > It is normally preferred to prepend it only for applications
> that you
>  > > > > > want to intercept by modifying unit files individually.
>  > > > > Hi Simo,
>  > > > > 
>  > > > > All the clients are running gssproxy by default.  As far as I know,
> I
>  > > > > haven't changed anything at all except adding to
> 99-nfs-client.conf
>  > > > > krb5_principal.
>  > > > > 
>  > > > > I assumed this was the default behaviour.
> /etc/gssproxy/gssproxy.conf
>  > > > > contains nothing but "[gssproxy]".
>  > > > > 
>  > > > > Where would I look?
>  > > > Ah NFS, well what is seem to be happening is that GDM is trying to
>  > > > access some NFS mounts, and causing the NFS client to try to
>  > > > authenticate on behalf of the gdm user.
>  > > > 
>  > > > I assume gdm is trying to check some user home directory you mount over
>  > > > NFS?
>  > > > 
>  > > > If that's the case (and you want to grant gdm the ability to perform
>  > > > those accesses) you could define an additional configuration section
>  > > > for NFS in gssproxy.conf with euid=42
>  > > > 
>  > > > As that is a more specific configuration it should match first, you can
>  > > > then configure it to let gdm use the host keytab for authentication
>  > > > (using the machine krb5 principal), this will generally end up granting
>  > > > "nobody" user access on the NFS server, or similar (depending on
> your
>  > > > id mapping configuration there.
>  > > Hi Simo,
>  > > 
>  > > I assume, as you said, that gdm is trying to access the NFS home
>  > > directories, but why would it be doing that?  GDM home directory is not
>  > > on an NFS share.  Before a user logs in, it's not clear what it would be
>  > > doing over and over again.   Any idea how I could track it (and stop it)?
>  > > 
>  > > Before login, GDM, I assume should only read the Init startup. Init does
>  > > indeed refer to some NFS mounts.  However, Init runs as root, and root
>  > > is mapped to the machine account.  I've verified that those accesses are
>  > > by root, and they work exactly as expected getting the proper access.
>  > > 
>  > > Rather than giving gdm user access to the share, can I tell gssproxy to
>  > > ignore requests from this user instead?  I'd like to know what it's
>  > > doing and why.  I'm just not sure how to find it.
>  > We do not have a way in gssproxy to drop requests on the floor at this
>  > time, unfortunately.
>  
>  I figured out that /etc/fonts/local.conf included a font from the NFS 
>  share which was causing gdm to constantly try the share, and gssproxy to 
>  constantly bang on syslog.  I resolved that, and the constant errors 
>  generated from gdm went away.  When I reboot the machine, I see no  
>  gssproxy errors. 
Great.

>    However,  when any user logs in, I see a few 
>  "Unspecified GSS failure" errors, but my home directory is mounted, and 
>  everything is fine.  Why would I get these errors?
>  
>  Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]: 
>  [status] Handling query input: 0x56413aeb64f0 (116)
>  Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]: 
>  [status] Processing request [0x56413aeb64f0 (116)]
>  Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]: 
>  [status] Executing request 6 (GSSX_ACQUIRE_CRED) from [0x56413aeb64f0 (116)]
>  Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]: 
>  gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service 
>  "nfs-client", euid: 1004,socket: (null)
>  Mar 03 15:29:35 sel01 gssproxy[853]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { 
>  "" [  ] } input_cred_handle: <Null> add_cred: 0 desired_name:
> <Null> 
>  time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } 
>  cred_usage: INITIATE initiator_time_r\
>  eq: 0 acceptor_time_req: 0 ) 
Is euid 1004 your user's uid ?
I wonder if there is a race between creation of the cache and NFS
access attempt.

>  Mar 03 15:29:35 sel01 gssproxy[896]: (OID: { 1 2 840 113554 1 2 2 })
>
>  Unspecified GSS failure.  Minor code may provide more information, No 
>  credentials cache found
>  Mar 03 15:29:35 sel01 gssproxy[853]: gssproxy[896]: (OID: { 1 2 840 
>  113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more 
>  information, No credentials cache found
>  Mar 03 15:29:35 sel01 gssproxy[853]: GSSX_RES_ACQUIRE_CRED( status: { 
>  851968 { 1 2 840 113554 1 2 2 } 2529639107 "Unspecified GSS failure.  
>  Minor code may provide more information" "No credentials cache found" [  
>  ] } output_cred_handle: <Null>\
>    )
>  Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]: 
>  [status] Returned buffer 6 (GSSX_ACQUIRE_CRED) from [0x56413aeb64f0 
>  (116)]: [0x7fe17c003370 (176)]
>  
>  I can give you a much more detailed log if it would help.
>  
>  Is anything in a level 3 log file (context_handle strings) confidential? 
It may contain tokens, should be just encrypted data, but better not
post from production systems.
You can send it directly to me if you like.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[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(a)redhat.com&gt; 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=&#39;TEST-BOX$(a)EXAMPLE.NET&#39;,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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)EXAMPLE.NET&quot;
>  > { 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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)EXAMPLE.NET&quot; { 1
>  > 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
>  > target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot; 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 } &quot;chang(a)EXAMPLE.NET&quot;
>  > &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
>  > > > > > > > [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(a)lists.fedorahosted.org
>  > > > > > > > To unsubscribe send an email to
> gss-proxy-leave(a)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/[e-mail]...
>  > > > > > >
>  > > > > > > --
>  > > > > > > 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]

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(a)redhat.com&gt;
> 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=&#39;TEST-BOX$(a)EXAMPLE.NET&#39;,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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)EXAMPLE.NET&quot;
>  > > { 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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)EXAMPLE.NET&quot; { 1
>  > > 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
>  > > target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot; 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 } &quot;chang(a)EXAMPLE.NET&quot;
>  > > &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt; 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(a)redhat.com&gt;
> 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(a)redhat.com&gt; 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-impersonati...
>  > > > > > > > > [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(a)lists.fedorahosted.org
>  > > > > > > > > To unsubscribe send an email to
> gss-proxy-leave(a)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/[e-mail]...
>  > > > > > > > 
>  > > > > > > > --
>  > > > > > > > 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

[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(a)redhat.com&gt; 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(a)redhat.com&gt; 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=&#39;TEST-BOX$(a)EXAMPLE.NET&#39;,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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot;
> > > > { 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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot; { 1
> > > > 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
> > > > target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot; 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 } &quot;chang(a)EXAMPLE.NET&quot;
> > > > &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt;
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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
> > > > > > > > > > [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(a)lists.fedorahosted.org
> > > > > > > > > > To unsubscribe send an email to
gss-proxy-leave(a)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/[e-mail]...
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > 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
>
>
>
>

[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(a)redhat.com&gt;:
>
> 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=&#39;TEST-BOX$(a)EXAMPLE.NET&#39;,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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot;
> { 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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot; { 1
> 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
> target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot; 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 } &quot;chang(a)EXAMPLE.NET&quot;
> &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
> > > > > > > [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(a)lists.fedorahosted.org
> > > > > > > To unsubscribe send an email to
gss-proxy-leave(a)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/[e-mail]...
> > > > > >
> > > > > > --
> > > > > > Simo Sorce
> > > > > > RHEL Crypto Team
> > > > > > Red Hat, Inc
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > Simo Sorce
> > > > RHEL Crypto Team
> > > > Red Hat, Inc
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> > --
> > Simo Sorce
> > RHEL Crypto Team
> > Red Hat, Inc
> >
> >
> >
> >
>

[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(a)lists.samba.org&gt; 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(a)redhat.com&gt;:
> >
> > 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=&#39;TEST-BOX$(a)EXAMPLE.NET&#39;,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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot;
> > { 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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot; { 1
> > 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
> > target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot; 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 } &quot;chang(a)EXAMPLE.NET&quot;
> > &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt; 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(a)redhat.com&gt;
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(a)redhat.com&gt; 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-impersonati...
> > > > > > > > [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(a)lists.fedorahosted.org
> > > > > > > > To unsubscribe send an email to
gss-proxy-leave(a)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/[e-mail]...
> > > > > > >
> > > > > > > --
> > > > > > > Simo Sorce
> > > > > > > RHEL Crypto Team
> > > > > > > Red Hat, Inc
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > Simo Sorce
> > > > > RHEL Crypto Team
> > > > > Red Hat, Inc
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Simo Sorce
> > > RHEL Crypto Team
> > > Red Hat, Inc
> > >
> > >
> > >
> > >
> >
>

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

Thanks,
Michael

________________________________________
From: Pavel Shilovsky <piastryyy(a)gmail.com&gt;
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(a)vger.kernel.org; samba-technical(a)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(a)redhat.com&gt;:
>
> 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=&#39;TEST-BOX$(a)EXAMPLE.NET&#39;,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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot;
> { 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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot; { 1
> 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
> target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot; 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 } &quot;chang(a)EXAMPLE.NET&quot;
> &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
> > > > > > > [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(a)lists.fedorahosted.org
> > > > > > > To unsubscribe send an email to
gss-proxy-leave(a)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/[e-mail]...
> > > > > >
> > > > > > --
> > > > > > Simo Sorce
> > > > > > RHEL Crypto Team
> > > > > > Red Hat, Inc
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > Simo Sorce
> > > > RHEL Crypto Team
> > > > Red Hat, Inc
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> > --
> > Simo Sorce
> > RHEL Crypto Team
> > Red Hat, Inc
> >
> >
> >
> >
>

[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(a)atos.net&gt; 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...
>
>  Thanks,
>  Michael
>
>  ________________________________________
>  From: Pavel Shilovsky <piastryyy(a)gmail.com&gt;
>  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(a)vger.kernel.org; samba-technical(a)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(a)redhat.com&gt;:
>  >
>  > 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=&#39;TEST-BOX$(a)EXAMPLE.NET&#39;,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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)EXAMPLE.NET&quot;
>  > { 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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)EXAMPLE.NET&quot; { 1
>  > 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
>  > target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot; 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 } &quot;chang(a)EXAMPLE.NET&quot;
>  > &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
>  > > > > > > > [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(a)lists.fedorahosted.org
>  > > > > > > > To unsubscribe send an email to
> gss-proxy-leave(a)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/[e-mail]...
>  > > > > > >
>  > > > > > > --
>  > > > > > > Simo Sorce
>  > > > > > > RHEL Crypto Team
>  > > > > > > Red Hat, Inc
>  > > > > > >
>  > > > > > >
>  > > > > > >
>  > > > > > >
>  > > > >
>  > > > > --
>  > > > > Simo Sorce
>  > > > > RHEL Crypto Team
>  > > > > Red Hat, Inc
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > >
>  > > >
>  > >
>  > > --
>  > > Simo Sorce
>  > > RHEL Crypto Team
>  > > Red Hat, Inc
>  > >
>  > >
>  > >
>  > >
>  >
>

[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/3d681bb5c140376ccc19e4871123...

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(a)redhat.com&gt;:

>
> 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(a)atos.net&gt;
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...
> >
> > Thanks,
> > Michael
> >
> > ________________________________________
> > From: Pavel Shilovsky <piastryyy(a)gmail.com&gt;
> > 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(a)vger.kernel.org; samba-technical(a)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(a)redhat.com&gt;:
> > >
> > > 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=&#39;TEST-BOX$(a)EXAMPLE.NET&#39;,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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot;
> > > { 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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot; { 1
> > > 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
> > > target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot; 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 } &quot;chang(a)EXAMPLE.NET&quot;
> > > &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
> > > > > > > > > [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(a)lists.fedorahosted.org
> > > > > > > > > To unsubscribe send an email to
gss-proxy-leave(a)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/[e-mail]...
> > > > > > > >
> > > > > > > > --
> > > > > > > > Simo Sorce
> > > > > > > > RHEL Crypto Team
> > > > > > > > Red Hat, Inc
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > Simo Sorce
> > > > > > RHEL Crypto Team
> > > > > > Red Hat, Inc
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Simo Sorce
> > > > RHEL Crypto Team
> > > > Red Hat, Inc
> > > >
> > > >
> > > >
> > > >
> > >
> >
>

[Leif Sahlberg]

On Fri, Oct 22, 2021 at 9:23 AM Pavel Shilovsky <piastryyy(a)gmail.com&gt; 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/3d681bb5c140376ccc19e4871123...
>
>  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(a)redhat.com&gt;
Date:   Fri Oct 22 09:41:24 2021 +1000

    cifs.upcall.c: fix compiler warning

    Signed-off-by: Ronnie Sahlberg <lsahlber(a)redhat.com&gt;

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(a)redhat.com&gt;:
>
>  >
>  > 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(a)atos.net&gt;
>  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...
>  > >
>  > > Thanks,
>  > > Michael
>  > >
>  > > ________________________________________
>  > > From: Pavel Shilovsky <piastryyy(a)gmail.com&gt;
>  > > 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(a)vger.kernel.org;
>  samba-technical(a)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(a)redhat.com&gt;:
>  > > >
>  > > > 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=&#39;TEST-BOX$(a)EXAMPLE.NET&#39;,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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)EXAMPLE.NET&quot; {
>  1
>  > > > 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
>  > > > target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot; 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 } &quot;chang(a)EXAMPLE.NET&quot;
>  > > > &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt;
> 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(a)redhat.com&gt;
>  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(a)redhat.com&gt;
>  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-impersonati...
>  > > > > > > > > > [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(a)lists.fedorahosted.org
>  > > > > > > > > > To unsubscribe send an email to
>  gss-proxy-leave(a)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/[e-mail]...
>  > > > > > > > >
>  > > > > > > > > --
>  > > > > > > > > Simo Sorce
>  > > > > > > > > RHEL Crypto Team
>  > > > > > > > > Red Hat, Inc
>  > > > > > > > >
>  > > > > > > > >
>  > > > > > > > >
>  > > > > > > > >
>  > > > > > >
>  > > > > > > --
>  > > > > > > Simo Sorce
>  > > > > > > RHEL Crypto Team
>  > > > > > > Red Hat, Inc
>  > > > > > >
>  > > > > > >
>  > > > > > >
>  > > > > > >
>  > > > > >
>  > > > > >
>  > > > >
>  > > > > --
>  > > > > Simo Sorce
>  > > > > RHEL Crypto Team
>  > > > > Red Hat, Inc
>  > > > >
>  > > > >
>  > > > >
>  > > > >
>  > > >
>  > >
>  >
>
>

[Jacob Shivers]

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(a)redhat.com&gt; wrote:
>  On Fri, Oct 22, 2021 at 9:23 AM Pavel Shilovsky <piastryyy(a)gmail.com&gt; 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/3d681bb5c140376ccc19e4871123...
> >
> > 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(a)redhat.com&gt;
>  Date:   Fri Oct 22 09:41:24 2021 +1000
>
>      cifs.upcall.c: fix compiler warning
>
>      Signed-off-by: Ronnie Sahlberg <lsahlber(a)redhat.com&gt;
>
>  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(a)redhat.com&gt;:
> >
> > >
> > > 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(a)atos.net&gt;
> 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...
> > > >
> > > > Thanks,
> > > > Michael
> > > >
> > > > ________________________________________
> > > > From: Pavel Shilovsky <piastryyy(a)gmail.com&gt;
> > > > 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(a)vger.kernel.org; samba-technical(a)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(a)redhat.com&gt;:
> > > > >
> > > > > 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=&#39;TEST-BOX$(a)EXAMPLE.NET&#39;,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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)EXAMPLE.NET&quot;
> > > > > { 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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)EXAMPLE.NET&quot; { 1
> > > > > 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
> > > > > target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot; 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 } &quot;chang(a)EXAMPLE.NET&quot;
> > > > > &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt;
> 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
> > > > > > > > > > > [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(a)lists.fedorahosted.org
> > > > > > > > > > > To unsubscribe send an email to
> gss-proxy-leave(a)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/[e-mail]...
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Simo Sorce
> > > > > > > > > > RHEL Crypto Team
> > > > > > > > > > Red Hat, Inc
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Simo Sorce
> > > > > > > > RHEL Crypto Team
> > > > > > > > Red Hat, Inc
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Simo Sorce
> > > > > > RHEL Crypto Team
> > > > > > Red Hat, Inc
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >

[Pavel Shilovsky]

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(a)redhat.com&gt;:
>
> 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(a)redhat.com&gt; wrote:
> >
> >
> >
> >
> > On Fri, Oct 22, 2021 at 9:23 AM Pavel Shilovsky <piastryyy(a)gmail.com&gt;
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/3d681bb5c140376ccc19e4871123...
> >>
> >> 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(a)redhat.com&gt;
> > Date:   Fri Oct 22 09:41:24 2021 +1000
> >
> >     cifs.upcall.c: fix compiler warning
> >
> >     Signed-off-by: Ronnie Sahlberg <lsahlber(a)redhat.com&gt;
> >
> > 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(a)redhat.com&gt;:
> >>
> >> >
> >> > 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(a)atos.net&gt; 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...
> >> > >
> >> > > Thanks,
> >> > > Michael
> >> > >
> >> > > ________________________________________
> >> > > From: Pavel Shilovsky <piastryyy(a)gmail.com&gt;
> >> > > 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(a)vger.kernel.org;
samba-technical(a)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(a)redhat.com&gt;:
> >> > > >
> >> > > > 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=&#39;TEST-BOX$(a)EXAMPLE.NET&#39;,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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot;
> >> > > > { 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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
&quot;chang(a)EXAMPLE.NET&quot; { 1
> >> > > > 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [
K.....T.....pJv.... ] 0 }
> >> > > > target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot;
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 } &quot;chang(a)EXAMPLE.NET&quot;
> >> > > > &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
> >> > > > > > > > > > [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(a)lists.fedorahosted.org
> >> > > > > > > > > > To unsubscribe send an email to
gss-proxy-leave(a)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/[e-mail]...
> >> > > > > > > > >
> >> > > > > > > > > --
> >> > > > > > > > > Simo Sorce
> >> > > > > > > > > RHEL Crypto Team
> >> > > > > > > > > Red Hat, Inc
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > >
> >> > > > > > > --
> >> > > > > > > Simo Sorce
> >> > > > > > > RHEL Crypto Team
> >> > > > > > > Red Hat, Inc
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > > > --
> >> > > > > Simo Sorce
> >> > > > > RHEL Crypto Team
> >> > > > > Red Hat, Inc
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

[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(a)atos.net&gt;
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(a)atos.net&gt;

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

[Jacob Shivers]

Hello Pavel,

Brief addition to man 8 cifs.upcall

Author: Jacob Shivers <jshivers(a)redhat.com&gt;
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(a)redhat.com&gt;

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(a)gmail.com&gt; 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(a)redhat.com&gt;:
>  >
>  > 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(a)redhat.com&gt; wrote:
>  > >
>  > >
>  > >
>  > >
>  > > On Fri, Oct 22, 2021 at 9:23 AM Pavel Shilovsky <piastryyy(a)gmail.com&gt;
> 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/3d681bb5c140376ccc19e4871123...
>  > >>
>  > >> 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(a)redhat.com&gt;
>  > > Date:   Fri Oct 22 09:41:24 2021 +1000
>  > >
>  > >     cifs.upcall.c: fix compiler warning
>  > >
>  > >     Signed-off-by: Ronnie Sahlberg <lsahlber(a)redhat.com&gt;
>  > >
>  > > 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(a)redhat.com&gt;:
>  > >>
>  > >> >
>  > >> > 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(a)atos.net&gt; 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...
>  > >> > >
>  > >> > > Thanks,
>  > >> > > Michael
>  > >> > >
>  > >> > > ________________________________________
>  > >> > > From: Pavel Shilovsky <piastryyy(a)gmail.com&gt;
>  > >> > > 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(a)vger.kernel.org;
> samba-technical(a)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(a)redhat.com&gt;:
>  > >> > > >
>  > >> > > > 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=&#39;TEST-BOX$(a)EXAMPLE.NET&#39;,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: { &quot;chang(a)EXAMPLE.NET&quot; [ {
> &quot;chang(a)EXAMPLE.NET&quot;
>  > >> > > > { 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: { &quot;chang(a)EXAMPLE.NET&quot; [
> { &quot;chang(a)EXAMPLE.NET&quot; { 1
>  > >> > > > 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [
> K.....T.....pJv.... ] 0 }
>  > >> > > > target_name: &quot;cifs(a)win2k16-dfs1.example.net&quot;
> 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 } &quot;chang(a)EXAMPLE.NET&quot;
>  > >> > > > &quot;cifs/win2k16-dfs1.example.net(a)EXAMPLE.NET&quot; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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-impersonati...
>  > >> > > > > > > > > > [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(a)lists.fedorahosted.org
>  > >> > > > > > > > > > To unsubscribe send an email
> to gss-proxy-leave(a)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/[e-mail]...
>  > >> > > > > > > > >
>  > >> > > > > > > > > --
>  > >> > > > > > > > > Simo Sorce
>  > >> > > > > > > > > RHEL Crypto Team
>  > >> > > > > > > > > Red Hat, Inc
>  > >> > > > > > > > >
>  > >> > > > > > > > >
>  > >> > > > > > > > >
>  > >> > > > > > > > >
>  > >> > > > > > >
>  > >> > > > > > > --
>  > >> > > > > > > Simo Sorce
>  > >> > > > > > > RHEL Crypto Team
>  > >> > > > > > > Red Hat, Inc
>  > >> > > > > > >
>  > >> > > > > > >
>  > >> > > > > > >
>  > >> > > > > > >
>  > >> > > > > >
>  > >> > > > > >
>  > >> > > > >
>  > >> > > > > --
>  > >> > > > > Simo Sorce
>  > >> > > > > RHEL Crypto Team
>  > >> > > > > Red Hat, Inc
>  > >> > > > >
>  > >> > > > >
>  > >> > > > >
>  > >> > > > >
>  > >> > > >
>  > >> > >
>  > >> >
>  > >>
>  >
>

[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(a)redhat.com&gt;:
>
> Hello Pavel,
>
> Brief addition to man 8 cifs.upcall
>
> Author: Jacob Shivers <jshivers(a)redhat.com&gt;
> 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(a)redhat.com&gt;
>
> 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(a)gmail.com&gt; 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(a)redhat.com&gt;:
> > >
> > > 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(a)redhat.com&gt;
wrote:
> > > >
> > > >
> > > >
> > > >
> > > > On Fri, Oct 22, 2021 at 9:23 AM Pavel Shilovsky
<piastryyy(a)gmail.com&gt; 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/3d681bb5c140376ccc19e4871123...
> > > >>
> > > >> 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(a)redhat.com&gt;
> > > > Date:   Fri Oct 22 09:41:24 2021 +1000
> > > >
> > > >     cifs.upcall.c: fix compiler warning
> > > >
> > > >     Signed-off-by: Ronnie Sahlberg <lsahlber(a)redhat.com&gt;
> > > >
> > > > 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(a)redhat.com&gt;:
> > > >>
> > > >> >
> > > >> > 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(a)atos.net&gt; 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...
> > > >> > >
> > > >> > > Thanks,
> > > >> > > Michael
> > > >> > >