Adding back missing people in CC, as I incorrectly pressed reply-to-
list and lost them.
On Thu, 2021-01-07 at 08:37 -0500, Simo via samba-technical wrote:
On Thu, 2021-01-07 at 11:04 +0000, Weiser, Michael via samba-
technical
wrote:
> Hello Simo,
> Hello Steve,
>
> > If something is needed in the short term, I thjink the quickest
> > course
> > of action is indeed to change the userspace helper to use gssapi
> > function calls, so that they can be intercepted like we do for
> > rpc.gssd
> > (nfs client's userspace helper).
>
> To get the ball rolling and give people (including myself and
> client)
> something to play with I went that route and extended cifs.upcall
> to
> fall back to GSS-API if no ticket cache nor keytab can be found for
> the user. An unpolished PoC patch is attached. (Sorry, for not
> putting it inline, have to rock the groupware at work. I will try
> to
> sort that once we've agreed this is the/a way to go.)
>
> With that patch applied, I can do a multiuser cifs mount using the
> system keytab and machine identity as usual and then have users
> access the mount using impersonated credentials from gssproxy.
> Quick
> demo:
>
> [root@fedora33 ~]# umount /mnt
> [root@fedora33 ~]# mount -o sec=krb5,multiuser,user=FEDORA33\$
> //dc/share /mnt
> [root@fedora33 ~]# ls -la /mnt
> total 0
> drwxr-xr-x. 2 root root 0 Jan 7 10:20 .
> dr-xr-xr-x. 18 root root 238 Jan 6 13:59 ..
> -rwxr-xr-x. 1 root root 0 Jan 5 17:02 bar
> [root@fedora33 ~]# klist
> klist: Credentials cache keyring 'persistent:0:krb_ccache_WZh7W8n'
> not found
> [root@fedora33 ~]#
>
> [adsuser@fedora33 ~]$ kdestroy
> [adsuser@fedora33 ~]$ echo test > /mnt/test
> [adsuser@fedora33 ~]$ cat /mnt/test
> test
> [adsuser@fedora33 ~]$ klist
> klist: Credentials cache keyring
> 'persistent:1618201110:krb_ccache_SrGqT3F' not found
> [adsuser@fedora33 ~]$
>
> Server-side permissions are enforced:
>
> [m@fedora33 ~]$ cat /mnt/test
> test
> [m@fedora33 ~]$ echo mytest > /mnt/test
> -bash: /mnt/test: Permission denied
> [m@fedora33 ~]$ klist
> klist: Credentials cache keyring 'persistent:1000:1000' not found
> [m@fedora33 ~]$
>
> The gssproxy config for this configures a cifs-specific socket and
> enables impersonation for any user id:
>
> [root@fedora33 ~]# cat /etc/gssproxy/99-cifs.conf
> [service/cifs]
> mechs = krb5
> socket = /var/lib/gssproxy/cifs.sock
> cred_store = keytab:/etc/krb5.keytab
> cred_usage = initiate
> euid = 0
> impersonate = yes
> allow_any_uid = yes
>
> And request-key config for cifs.spnego enables use of gssproxy and
> the service-specific socket through environment variables:
>
> [root@fedora33 ~]# cat /etc/request-key.d/cifs.spnego.conf
> create cifs.spnego * * /usr/bin/env GSS_USE_PROXY=yes
> GSSPROXY_SOCKET=/var/lib/gssproxy/cifs.sock /usr/sbin/cifs.upcall
> %k
>
> (I see that nfs-utils' gssd does the same by setting the variables
> itself based on command line options. That could easily be done
> here
> as well.)
>
> User FEDORA33$ (the computer object) needs to be enabled for
> delegation to service cifs. I've tested with a Fedora 33 client and
> Windows 2016 Active Directory server.
>
> The patch is against current cifs-utils HEAD. It is lacking all the
> autoconf trimmings and intentionally forgoes reindents of existing
> code for clarity of what's being touched.
>
> What do you think?
Sounds great!
> > Unfortunately I do not have the cycles to work on that myself at
> > this
> > time :-(
>
> I have a client in very tangible need of this functionality who is
> a
> RedHat customer. Would it be helpful if they were to open a case
> with
> Redhat on this?
Yes!
CC me if you need to.
> As an extension the above (but not to distract from the focus of
> getting something to work at all first):
>
> I rather accidentally also played around with delegating retrieval
> of
> the mount credentials into gssproxy as well (due to not realising
> that username=FEDORA33$ would just activate the keytab codepath in
> cifs.upcall).
>
> This can be done by leaving out the username from the mount
> command,
> marking euid 0 as trusted for access to the keytab in gssproxy and
> adding a fallback principal to the gssproxy config (because
> cifs.upcall in this case does not submit a desired name for the
> credential):
>
> [root@fedora33 ~]# mount -o sec=krb5,multiuser //dc/share /mnt
> [root@fedora33 ~]# cat /etc/gssproxy/99-cifs.conf
> [service/cifs]
> mechs = krb5
> socket = /var/lib/gssproxy/cifs.sock
> cred_store = keytab:/etc/krb5.keytab
> cred_usage = initiate
> euid = 0
> trusted = yes
> impersonate = yes
> krb5_principal = cifs-mount
> allow_any_uid = yes
>
> While this works, it requires a separate user who would then
> carefully need to be kept out of any sensitive file access groups.
>
> When trying to use the machine identity FEDORA33$ instead, I ran
> into
> a peculiar error from the AD KDC:
>
> [root@fedora33 ~]# cat /etc/gssproxy/99-cifs.conf
> [service/cifs]
> mechs = krb5
> socket = /var/lib/gssproxy/cifs.sock
> cred_store = keytab:/etc/krb5.keytab
> cred_usage = initiate
> euid = 0
> trusted = yes
> impersonate = yes
> krb5_principal = FEDORA33$
> allow_any_uid = yes
> [root@fedora33 ~]# gssproxy -i -d &
> [2] 3814
> [root@fedora33 ~]# [2021/01/07 10:01:10]: Debug Enabled (level: 1)
> [2021/01/07 10:01:10]: Service: nfs-server, Keytab:
> /etc/krb5.keytab,
> Enctype: 17
> [2021/01/07 10:01:10]: Service: cifs, Keytab: /etc/krb5.keytab,
> Enctype: 17
> [2021/01/07 10:01:10]: Service: nfs-client, Keytab:
> /etc/krb5.keytab,
> Enctype: 17
> [2021/01/07 10:01:10]: Client [2021/01/07 10:01:10]:
> (/usr/sbin/gssproxy) [2021/01/07 10:01:10]: connected (fd =
> 11)[2021/01/07 10:01:10]: (pid = 3814) (uid = 0) (gid =
> 0)[2021/01/07 10:01:10]: (context =
> system_u:system_r:kernel_t:s0)[2021/01/07 10:01:10]:
>
> [root@fedora33 ~]# mount -o sec=krb5,multiuser //dc/share /mnt
> [2021/01/07 10:01:13]: Client [2021/01/07 10:01:13]:
> (/usr/sbin/cifs.upcall) [2021/01/07 10:01:13]: connected (fd =
> 12)[2021/01/07 10:01:13]: (pid = 3824) (uid = 0) (gid =
> 0)[2021/01/07 10:01:13]: (context =
> system_u:system_r:kernel_t:s0)[2021/01/07 10:01:13]:
> [CID 12][2021/01/07 10:01:13]: gp_rpc_execute: executing 6
> (GSSX_ACQUIRE_CRED) for service "cifs", euid: 0,socket:
> /var/lib/gssproxy/cifs.sock
> gssproxy[3814]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS
> failure. Minor code may provide more information, KDC has no
> support
> for padata type
> [CID 12][2021/01/07 10:01:13]: gp_rpc_execute: executing 8
> (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 0,socket:
> /var/lib/gssproxy/cifs.sock
> gssproxy[3814]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS
> failure. Minor code may provide more information, KDC has no
> support
> for padata type
> [CID 12][2021/01/07 10:01:13]: gp_rpc_execute: executing 6
> (GSSX_ACQUIRE_CRED) for service "cifs", euid: 0,socket:
> /var/lib/gssproxy/cifs.sock
> gssproxy[3814]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS
> failure. Minor code may provide more information, KDC has no
> support
> for padata type
> [CID 12][2021/01/07 10:01:13]: gp_rpc_execute: executing 8
> (GSSX_INIT_SEC_CONTEXT) for service "cifs", euid: 0,socket:
> /var/lib/gssproxy/cifs.sock
> gssproxy[3814]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS
> failure. Minor code may provide more information, KDC has no
> support
> for padata type
> mount error(126): Required key not available
> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and
> kernel log messages (dmesg)
>
> With more debugging it appears that gssproxy tries to impersonate
> user FEDORA33$ with a credential which is also for FEDORA33$. After
> further testing it seems this is generally not allowed or just not
> working due to never being tested because it is unnecessary: If we
> can acquire a impersonation credential for that identity we should
> also be able to get the actual access credential as well.
Sounds like a bug in gss-proxy, can you file a github issue/PR ?
We should certainly shortcut the impersonation if we already have a
valid credential.
> From looking at the nfs-utils gssd code it appears the only reason
> it
> hasn't run into this case yet is because it handles the machine
> credentials itself using krb5 functions.
>
> The second attached patch against current gssproxy HEAD adds that
> distinction and makes this case work as an optional extension with
> fallback into the default codepath on error.
>
> Does that make sense?
Yes the patch looks good!
> Is it sane, security wise, do you think?
Sane, you are just avoiding a useless call in a special case.
Simo.