Hello Pavel,
Brief addition to man 8 cifs.upcall
Author: Jacob Shivers <jshivers@xxxxxxxxxx>
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@xxxxxxxxxx>
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@xxxxxxxxx> 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@xxxxxxxxxx>:
> >
> > 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@xxxxxxxxxx> wrote:
> > >
> > >
> > >
> > >
> > > On Fri, Oct 22, 2021 at 9:23 AM Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote:
> > >>
> > >> Hello Michael, Jacob,
> > >>
> > >> The cifs.upcall patch is applied with some minor adjustments (code
> > >> style and a patch description) on top of the next branch on github:
> > >>
> > >> https://github.com/piastry/cifs-utils/commit/3d681bb5c140376ccc19e48711231aeef1e87aa9
> > >>
> > >> Please let me know if it looks good and/or if you have other suggestions.
> > >>
> > >> The only concern that I have is the compile warning below. Would
> > >> appreciate it if you provide a fix for that.
> > >>
> > >> gcc -DHAVE_CONFIG_H -I. -Wall -Wextra -D_FORTIFY_SOURCE=2 -fpie
> > >> -pie -Wl,-z,relro,-z,now -g -O2 -MT cifs.upcall.o -MD -MP -MF
> > >> .deps/cifs.upcall.Tpo -c -o cifs.upcall.o cifs.upcall.c
> > >> cifs.upcall.c: In function ‘cifs_gss_get_req’:
> > >> cifs.upcall.c:808:4: warning: passing argument 5 of
> > >> ‘gss_init_sec_context’ discards ‘const’ qualifier from pointer target
> > >> type [-Wdiscarded-qualifiers]
> > >> gss_mech_krb5, /* force krb5 */
> > >> ^
> > >> In file included from /usr/include/gssapi/gssapi_generic.h:31:0,
> > >> from cifs.upcall.c:40:
> > >> /usr/include/gssapi/gssapi.h:437:1: note: expected ‘gss_OID {aka
> > >> struct gss_OID_desc_struct *}’ but argument is of type ‘const
> > >> gss_OID_desc * const {aka const struct gss_OID_desc_struct * const}’
> > >> gss_init_sec_context(
> > >> ^
> > >
> > >
> > > I do not get that warning on my system, but this patch should fix it?
> > >
> > > Author: Ronnie Sahlberg <lsahlber@xxxxxxxxxx>
> > > Date: Fri Oct 22 09:41:24 2021 +1000
> > >
> > > cifs.upcall.c: fix compiler warning
> > >
> > > Signed-off-by: Ronnie Sahlberg <lsahlber@xxxxxxxxxx>
> > >
> > > 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@xxxxxxxxxx>:
> > >>
> > >> >
> > >> > 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@xxxxxxxx> wrote:
> > >> > >
> > >> > > Hello Pavel,
> > >> > >
> > >> > > > Do we have any more-up-to-date version of the cifs-utils patch other
> > >> > > > than the one attached to the email thread? I would like to merge the
> > >> > > > patch into the "next" branch so it makes the next release of
> > >> > > > cifs-utils.
> > >> > >
> > >> > > I'm also not aware of a newer version. As one of the initiators of the discussion, who's highly interested in seeing this merged, I'm standing by to help out with background context, testing or improving the code. (The patch was meant as a PoC which is why I skipped some reindenting and niceties to keep its approach and impact easy to gauge.)
> > >> > >
> > >> > > > Also there is a potential helper script mentioned above that is needed
> > >> > > > to set up gssproxy properly?
> > >> > >
> > >> > > I'm not aware of a helper script. gssproxy just needs to be told about cifs-utils and how it should be treated using a single config drop file. Also in the meantime, Jacob and I have streamlined the configuration so a separate UNIX domain socket and tweaking its permissions using a systemd service drop-in file is no longer needed. Instead, gssproxy can distinguish multiple clients on the same socket using the calling binary derived from getsockopt/SO_PEERCRED.
> > >> > >
> > >> > > Finally, environment variable GSS_USE_PROXY needs to be set for cifs.upcall to enable the gssproxy proxy mech. (Instead of using the env command, cifs.upcall could have a command line option similar to rpc.gssd[1] which ends up doing the same thing.)
> > >> > >
> > >> > > Here's the config summary:
> > >> > >
> > >> > > # cat /etc/request-key.d/cifs.spnego.conf
> > >> > > create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes /usr/sbin/cifs.upcall %k
> > >> > >
> > >> > > # cat /etc/gssproxy/99-cifs.conf
> > >> > > [service/cifs]
> > >> > > mechs = krb5
> > >> > > # not needed when program option is used
> > >> > > # socket = /var/lib/gssproxy/cifs.sock
> > >> > > program = /usr/sbin/cifs.upcall
> > >> > > cred_store = keytab:/etc/krb5.keytab
> > >> > > cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
> > >> > > cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
> > >> > > cred_usage = initiate
> > >> > > # allow process with any euid to use the service and receive impersonated
> > >> > > # tickets for services
> > >> > > allow_any_uid = yes
> > >> > > # allow euid access to keytab
> > >> > > trusted = yes
> > >> > > # allow impersonation
> > >> > > impersonate = yes
> > >> > > # allow process with euid 0 to use the keytab
> > >> > > euid = 0
> > >> > >
> > >> > > The actual mount can be done using system credentials from the keytab. Small proof session showcasing that gssproxy is involved and working:
> > >> > >
> > >> > > # systemctl stop gssproxy
> > >> > > # mount -o sec=krb5,multiuser,user=FEDORA33\$ //dc/share /mnt
> > >> > > # su - adsuser -c "touch /mnt/test"
> > >> > > touch: cannot touch '/mnt/test': Permission denied
> > >> > > # systemctl start gssproxy
> > >> > > # su - adsuser -c "touch /mnt/test"
> > >> > > #
> > >> > >
> > >> > > [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/gssd/gssd.c;h=833d8e0110a9737df8ef6ddeb439ba1a37ee9931;hb=HEAD#l1128
> > >> > >
> > >> > > Thanks,
> > >> > > Michael
> > >> > >
> > >> > > ________________________________________
> > >> > > From: Pavel Shilovsky <piastryyy@xxxxxxxxx>
> > >> > > 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@xxxxxxxxxxxxxxx; samba-technical@xxxxxxxxxxxxxxx
> > >> > > 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@xxxxxxxxxx>:
> > >> > > >
> > >> > > > I have tested the patches for cifs.upcall and can say that with some
> > >> > > > additional modifications to gssproxy the end setup brings a degree of
> > >> > > > feature parity to SMB clients that had been previously exclusive to
> > >> > > > NFS clients.
> > >> > > > Deployment does require some additional configuration, including the
> > >> > > > creation of a drop-in file for gssproxy under /etc/gssproxy and for
> > >> > > > the gssproxy service managed by systemd
> > >> > > >
> > >> > > >
> > >> > > > ### KDC configuration
> > >> > > >
> > >> > > > *** delegation ***
> > >> > > >
> > >> > > > Constrained Delegation (CD) for the SMB host to the Kerberized SMB server
> > >> > > > Resource Based Constrained Delegation (RBCD) on the Kerberized SMB
> > >> > > > server to determine which SMB clients can delegate
> > >> > > >
> > >> > > >
> > >> > > > ### SMB client configuration
> > >> > > >
> > >> > > > *** sssd ***
> > >> > > >
> > >> > > > Configuration file modification.
> > >> > > >
> > >> > > > Disable using fully qualified domain names as impersonation does not
> > >> > > > correctly handle fully qualified names at time of ticket acquisition.
> > >> > > >
> > >> > > > use_fully_qualified_names = False
> > >> > > >
> > >> > > > *** gssproxy ***
> > >> > > >
> > >> > > > Drop file creation
> > >> > > >
> > >> > > > Add a drop file for gssproxy to create the necessary socket and
> > >> > > > corresponding settings.
> > >> > > >
> > >> > > > # cat /etc/gssproxy/99-cifs-client.conf with contents
> > >> > > > [service/cifs]
> > >> > > > mechs = krb5
> > >> > > > socket = /var/lib/gssproxy/cifs.sock
> > >> > > > cred_store = keytab:/etc/krb5.keytab
> > >> > > > cred_usage = initiate
> > >> > > > euid = 0
> > >> > > > impersonate = yes
> > >> > > > allow_any_uid = yes
> > >> > > >
> > >> > > > Service drop-in file.
> > >> > > >
> > >> > > > Create a drop-in file to limit socket access for an unattended user, if desired.
> > >> > > >
> > >> > > > # cat /etc/systemd/system/gssproxy.service.d/90-cifs.conf
> > >> > > > [Service]
> > >> > > > # Limit cifs.sock socket file accessiblility to just the unattended user.
> > >> > > > ExecStartPost=/bin/bash -c 'chmod 660 /var/lib/gssproxy/cifs.sock &&
> > >> > > > setfacl -m u:chang:rw /var/lib/gssproxy/cifs.sock'
> > >> > > >
> > >> > > >
> > >> > > > *** cifs.upcall ***
> > >> > > >
> > >> > > > cifs.spnego.conf modification
> > >> > > >
> > >> > > > Allow for gssprxy to be used and specify socket file
> > >> > > >
> > >> > > > # cat /etc/request-key.d/cifs.spnego.conf
> > >> > > > create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes
> > >> > > > GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall %k
> > >> > > >
> > >> > > > include the '-t' flag to allow for accessing a Kerberized DFS
> > >> > > > namespace using a domain based mount, i.e //example.net/dfs/share
> > >> > > >
> > >> > > > create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes
> > >> > > > GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall -t
> > >> > > > %k
> > >> > > >
> > >> > > >
> > >> > > > The above does allow for unattended users to access a Kerberized SMB
> > >> > > > share while limiting access to only a specific user:
> > >> > > >
> > >> > > > # mount //win2k16-dfs1.example.net/greendale/ /mnt -o
> > >> > > > sec=krb5,username='TEST-BOX$@EXAMPLE.NET',multiuser
> > >> > > >
> > >> > > > # su - jeff
> > >> > > > Last login: Fri Feb 5 12:14:42 EST 2021 on pts/0
> > >> > > > [jeff@test-box ~]$ ll /mnt
> > >> > > > ls: cannot access '/mnt': Permission denied
> > >> > > > [jeff@test-box ~]$ logout
> > >> > > >
> > >> > > > # su - chang
> > >> > > > Last login: Fri Feb 5 12:14:46 EST 2021 on pts/0
> > >> > > > [chang@test-box ~]$ klist
> > >> > > > klist: No credentials cache found (filename: /tmp/krb5cc_602001123)
> > >> > > > [chang@test-box ~]$ ls -l /mnt
> > >> > > > total 143
> > >> > > >
> > >> > > > drwxr-xr-x. 2 chang domain users 0 Oct 4 2018 DfsrPrivate
> > >> > > > -rwxr-xr-x. 1 chang domain users 0 Sep 22 10:07 test_file
> > >> > > > -rwxr-xr-x. 1 chang domain users 0 Dec 14 15:22 whoami
> > >> > > > drwxr-xr-x. 2 chang domain users 0 Dec 7 12:54 winhome
> > >> > > >
> > >> > > > [chang@test-box ~]$ klist
> > >> > > > klist: No credentials cache found (filename: /tmp/krb5cc_602001123)
> > >> > > >
> > >> > > >
> > >> > > > Feb 23 12:22:44.857956 test-box.example.net su[1672]: (to jeff) root on pts/1
> > >> > > > Feb 23 12:22:44.866263 test-box.example.net su[1672]:
> > >> > > > pam_systemd(su-l:session): Cannot create session: Already running in a
> > >> > > > session or user slice
> > >> > > > Feb 23 12:22:44.867158 test-box.example.net su[1672]:
> > >> > > > pam_unix(su-l:session): session opened for user jeff by root(uid=0)
> > >> > > > Feb 23 12:22:46.253310 test-box.example.net cifs.upcall[1700]: key
> > >> > > > description: cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cedc;creduid=0x23e1cedc;pid=0x6a3
> > >> > > > Feb 23 12:22:46.253335 test-box.example.net cifs.upcall[1700]: ver=2
> > >> > > > Feb 23 12:22:46.253338 test-box.example.net cifs.upcall[1700]:
> > >> > > > host=win2k16-dfs1.example.net
> > >> > > > Feb 23 12:22:46.253342 test-box.example.net cifs.upcall[1700]:
> > >> > > > ip=192.168.124.132
> > >> > > > Feb 23 12:22:46.253344 test-box.example.net cifs.upcall[1700]: sec=1
> > >> > > > Feb 23 12:22:46.253348 test-box.example.net cifs.upcall[1700]: uid=602001116
> > >> > > > Feb 23 12:22:46.253352 test-box.example.net cifs.upcall[1700]: creduid=602001116
> > >> > > > Feb 23 12:22:46.253365 test-box.example.net cifs.upcall[1700]: pid=1699
> > >> > > > Feb 23 12:22:46.253978 test-box.example.net cifs.upcall[1700]:
> > >> > > > get_cachename_from_process_env: pathname=/proc/1699/environ
> > >> > > > Feb 23 12:22:46.254995 test-box.example.net cifs.upcall[1700]:
> > >> > > > get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001116
> > >> > > > Feb 23 12:22:46.255015 test-box.example.net cifs.upcall[1700]:
> > >> > > > get_tgt_time: unable to get principal
> > >> > > > Feb 23 12:22:46.255021 test-box.example.net cifs.upcall[1700]:
> > >> > > > handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net
> > >> > > > Feb 23 12:22:46.255024 test-box.example.net cifs.upcall[1700]:
> > >> > > > handle_krb5_mech: using GSS-API
> > >> > > > Feb 23 12:22:46.259295 test-box.example.net cifs.upcall[1700]: GSS-API
> > >> > > > error init_sec_context: Unspecified GSS failure. Minor code may
> > >> > > > provide more information
> > >> > > > Feb 23 12:22:46.259306 test-box.example.net cifs.upcall[1700]: GSS-API
> > >> > > > error init_sec_context: No Kerberos credentials available (default
> > >> > > > cache: FILE:/tmp/krb5cc_602001116)
> > >> > > > Feb 23 12:22:46.259311 test-box.example.net cifs.upcall[1700]:
> > >> > > > handle_krb5_mech: failed to obtain service ticket via GSS (851968)
> > >> > > > Feb 23 12:22:46.259314 test-box.example.net cifs.upcall[1700]: Unable
> > >> > > > to obtain service ticket
> > >> > > > Feb 23 12:22:46.259323 test-box.example.net cifs.upcall[1700]: Exit
> > >> > > > status 851968
> > >> > > > Feb 23 12:22:46.262827 test-box.example.net kernel: CIFS VFS:
> > >> > > > \\win2k16-dfs1.example.net Send error in SessSetup = -126
> > >> > > > Feb 23 12:22:47.398266 test-box.example.net su[1672]:
> > >> > > > pam_unix(su-l:session): session closed for user jeff
> > >> > > > Feb 23 12:22:49.159640 test-box.example.net su[1702]: (to chang) root on pts/1
> > >> > > > Feb 23 12:22:49.173264 test-box.example.net su[1702]:
> > >> > > > pam_systemd(su-l:session): Cannot create session: Already running in a
> > >> > > > session or user slice
> > >> > > > Feb 23 12:22:49.173967 test-box.example.net su[1702]:
> > >> > > > pam_unix(su-l:session): session opened for user chang by root(uid=0)
> > >> > > > Feb 23 12:22:51.878743 test-box.example.net cifs.upcall[1729]: key
> > >> > > > description: cifs.spnego;0;0;39010000;ver=0x2;host=win2k16-dfs1.example.net;ip4=192.168.124.132;sec=krb5;uid=0x23e1cee3;creduid=0x23e1cee3;pid=0x6c0
> > >> > > > Feb 23 12:22:51.878765 test-box.example.net cifs.upcall[1729]: ver=2
> > >> > > > Feb 23 12:22:51.878769 test-box.example.net cifs.upcall[1729]:
> > >> > > > host=win2k16-dfs1.example.net
> > >> > > > Feb 23 12:22:51.878773 test-box.example.net cifs.upcall[1729]:
> > >> > > > ip=192.168.124.132
> > >> > > > Feb 23 12:22:51.878776 test-box.example.net cifs.upcall[1729]: sec=1
> > >> > > > Feb 23 12:22:51.878780 test-box.example.net cifs.upcall[1729]: uid=602001123
> > >> > > > Feb 23 12:22:51.878783 test-box.example.net cifs.upcall[1729]: creduid=602001123
> > >> > > > Feb 23 12:22:51.878786 test-box.example.net cifs.upcall[1729]: pid=1728
> > >> > > > Feb 23 12:22:51.879060 test-box.example.net cifs.upcall[1729]:
> > >> > > > get_cachename_from_process_env: pathname=/proc/1728/environ
> > >> > > > Feb 23 12:22:51.879799 test-box.example.net cifs.upcall[1729]:
> > >> > > > get_existing_cc: default ccache is FILE:/tmp/krb5cc_602001123
> > >> > > > Feb 23 12:22:51.879819 test-box.example.net cifs.upcall[1729]:
> > >> > > > get_tgt_time: unable to get principal
> > >> > > > Feb 23 12:22:51.879824 test-box.example.net cifs.upcall[1729]:
> > >> > > > handle_krb5_mech: getting service ticket for win2k16-dfs1.example.net
> > >> > > > Feb 23 12:22:51.879827 test-box.example.net cifs.upcall[1729]:
> > >> > > > handle_krb5_mech: using GSS-API
> > >> > > > Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]:
> > >> > > > [2021/02/23 17:22:51]: Client [2021/02/23 17:22:51]:
> > >> > > > (/usr/sbin/cifs.upcall) [2021/02/23 17:22:51]: connected (fd =
> > >> > > > 14)[2021/02/23 17:22:51]: (pid = 1729) (uid = 602001123) (gid =
> > >> > > > 602000513)[2021/02/23 17:22:51]: (context =
> > >> > > > system_u:system_r:kernel_t:s0)[>
> > >> > > > Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID
> > >> > > > 14][2021/02/23 17:22:51]: Connection matched service cifs
> > >> > > > Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]: [CID
> > >> > > > 14][2021/02/23 17:22:51]: gp_rpc_execute: executing 6
> > >> > > > (GSSX_ACQUIRE_CRED) for service "cifs", euid: 602001123,socket:
> > >> > > > /var/lib/gssproxy/cifs.sock
> > >> > > > Feb 23 12:22:51.886573 test-box.example.net gssproxy[1000]:
> > >> > > > GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [ ] } input_cred_handle: <Null>
> > >> > > > add_cred: 0 desired_name: <Null> time_req: 0 desired_mechs: { }
> > >> > > > cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 )
> > >> > > > Feb 23 12:22:52.346639 test-box.example.net gssproxy[1000]:
> > >> > > > GSSX_RES_ACQUIRE_CRED( status: { 0 { 1 2 840 113554 1 2 2 } 0 "" "" [
> > >> > > > ] } output_cred_handle: { "chang@xxxxxxxxxxx" [ { "chang@xxxxxxxxxxx"
> > >> > > > { 1 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ]
> > >> > > > 0 } )
> > >> > > > Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID
> > >> > > > 14][2021/02/23 17:22:52]: Connection matched service cifs
> > >> > > > Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID
> > >> > > > 14][2021/02/23 17:22:52]: gp_rpc_execute: executing 8
> > >> > > > (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 602001123,socket:
> > >> > > > /var/lib/gssproxy/cifs.sock
> > >> > > > Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]:
> > >> > > > GSSX_ARG_INIT_SEC_CONTEXT( call_ctx: { "" [ ] } context_handle:
> > >> > > > <Null> cred_handle: { "chang@xxxxxxxxxxx" [ { "chang@xxxxxxxxxxx" { 1
> > >> > > > 2 840 113554 1 2 2 } INITIATE 36000 0 } ] [ K.....T.....pJv.... ] 0 }
> > >> > > > target_name: "cifs@xxxxxxxxxxxxxxxxxxxxxxxx" mech>
> > >> > > > Feb 23 12:22:52.348086 test-box.example.net gssproxy[1000]: [CID
> > >> > > > 14][2021/02/23 17:22:52]: Credentials allowed by configuration
> > >> > > > Feb 23 12:22:52.357103 test-box.example.net gssproxy[1000]:
> > >> > > > GSSX_RES_INIT_SEC_CONTEXT( status: { 0 { 1 2 840 113554 1 2 2 } 0 ""
> > >> > > > "" [ ] } context_handle: { [ ......H............ ] [ ] 0 { 1 2 840
> > >> > > > 113554 1 2 2 } "chang@xxxxxxxxxxx"
> > >> > > > "cifs/win2k16-dfs1.example.net@xxxxxxxxxxx" 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> wrote:
> > >> > > > > > > > > Hi Michael,
> > >> > > > > > > > > as you say the best course of action would be for cifs.ko to move to
> > >> > > > > > > > > use the RPC interface we defined for knfsd (with any extensions that
> > >> > > > > > > > > may be needed), and we had discussions in the past with cifs upstream
> > >> > > > > > > > > developers about it. But nothing really materialized.
> > >> > > > > > > > >
> > >> > > > > > > > > If something is needed in the short term, I thjink the quickest course
> > >> > > > > > > > > of action is indeed to change the userspace helper to use gssapi
> > >> > > > > > > > > function calls, so that they can be intercepted like we do for rpc.gssd
> > >> > > > > > > > > (nfs client's userspace helper).
> > >> > > > > > > > >
> > >> > > > > > > > > Unfortunately I do not have the cycles to work on that myself at this
> > >> > > > > > > > > time :-(
> > >> > > > > > > > >
> > >> > > > > > > > > HTH,
> > >> > > > > > > > > Simo.
> > >> > > > > > > > >
> > >> > > > > > > > > On Wed, 2020-12-16 at 10:01 +0000, Weiser, Michael wrote:
> > >> > > > > > > > > > Hello,
> > >> > > > > > > > > >
> > >> > > > > > > > > > I have a use-case for authentication of Linux cifs client mounts without the user being present (e.g. from batch jobs) using gssproxy's impersonation feature with Kerberos Constrained Delegation similar to how it can be done for NFS[1].
> > >> > > > > > > > > >
> > >> > > > > > > > > > My understanding is that currently neither the Linux cifs kernel client nor cifs-utils userland tools support acquiring credentials using gssproxy. The former uses a custom upcall interface to talk to cifs.spnego from cifs-utils. The latter then goes looking for Kerberos ticket caches using libkrb5 functions, not GSSAPI, which prevents gssproxy from interacting with it.[2]
> > >> > > > > > > > > >
> > >> > > > > > > > > > From what I understand, the preferred method would be to switch the Linux kernel client upcall to the RPC protocol defined by gssproxy[3] (as has been done for the Linux kernel NFS server already replacing rpc.svcgssd[4]). The kernel could then, at least optionally, talk to gssproxy directly to try and obtain credentials.
> > >> > > > > > > > > >
> > >> > > > > > > > > > Failing that, cifs-utils' cifs.spnego could be switched to GSSAPI so that gssproxy's interposer plugin could intercept GSSAPI calls and provide them with the required credentials (similar to the NFS client rpc.gssd[5]).
> > >> > > > > > > > > >
> > >> > > > > > > > > > Assuming my understanding is correct so far:
> > >> > > > > > > > > >
> > >> > > > > > > > > > Is anyone doing any work on this and could use some help (testing, coding)?
> > >> > > > > > > > > > What would be expected complexity and possible roadblocks when trying to make a start at implementing this?
> > >> > > > > > > > > > Or is the idea moot due to some constraint or recent development I'm not aware of?
> > >> > > > > > > > > >
> > >> > > > > > > > > > I have found a recent discussion of the topic on linux-cifs[6] which provided no definite answer though.
> > >> > > > > > > > > >
> > >> > > > > > > > > > As a crude attempt at an explicit userspace workaround I tried but failed to trick smbclient into initialising a ticket cache using gssproxy for cifs.spnego to find later on.
> > >> > > > > > > > > > Is this something that could be implemented without too much redundant effort (or should already work, perhaps using a different tool)?
> > >> > > > > > > > > >
> > >> > > > > > > > > > [1] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-via-constrained-delegation
> > >> > > > > > > > > > [2] https://pagure.io/gssproxy/issue/56
> > >> > > > > > > > > > [3] https://github.com/gssapi/gssproxy/blob/main/docs/ProtocolDocumentation.md
> > >> > > > > > > > > > [4] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-server
> > >> > > > > > > > > > [5] https://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#nfs-client
> > >> > > > > > > > > > [6] https://www.spinics.net/lists/linux-cifs/msg20182.html
> > >> > > > > > > > > > --
> > >> > > > > > > > > > Thanks,
> > >> > > > > > > > > > Michael
> > >> > > > > > > > > > _______________________________________________
> > >> > > > > > > > > > gss-proxy mailing list -- gss-proxy@xxxxxxxxxxxxxxxxxxxxxx
> > >> > > > > > > > > > To unsubscribe send an email to gss-proxy-leave@xxxxxxxxxxxxxxxxxxxxxx
> > >> > > > > > > > > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > >> > > > > > > > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > >> > > > > > > > > > List Archives: https://lists.fedorahosted.org/archives/list/gss-proxy@xxxxxxxxxxxxxxxxxxxxxx
> > >> > > > > > > > >
> > >> > > > > > > > > --
> > >> > > > > > > > > Simo Sorce
> > >> > > > > > > > > RHEL Crypto Team
> > >> > > > > > > > > Red Hat, Inc
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > >
> > >> > > > > > > --
> > >> > > > > > > Simo Sorce
> > >> > > > > > > RHEL Crypto Team
> > >> > > > > > > Red Hat, Inc
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > > > --
> > >> > > > > Simo Sorce
> > >> > > > > RHEL Crypto Team
> > >> > > > > Red Hat, Inc
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>
