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

[Simo]

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 at fedora33 ~]# umount /mnt
> [root at fedora33 ~]# mount -o sec=krb5,multiuser,user=FEDORA33\$
> //dc/share /mnt
> [root at 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 at fedora33 ~]# klist
> klist: Credentials cache keyring 'persistent:0:krb_ccache_WZh7W8n'
> not found
> [root at fedora33 ~]#
> 
> [adsuser at fedora33 ~]$ kdestroy
> [adsuser at fedora33 ~]$ echo test > /mnt/test
> [adsuser at fedora33 ~]$ cat /mnt/test
> test
> [adsuser at fedora33 ~]$ klist
> klist: Credentials cache keyring
> 'persistent:1618201110:krb_ccache_SrGqT3F' not found
> [adsuser at fedora33 ~]$
> 
> Server-side permissions are enforced:
> 
> [m at fedora33 ~]$ cat /mnt/test
> test
> [m at fedora33 ~]$ echo mytest > /mnt/test
> -bash: /mnt/test: Permission denied
> [m at fedora33 ~]$ klist
> klist: Credentials cache keyring 'persistent:1000:1000' not found
> [m at fedora33 ~]$
> 
> The gssproxy config for this configures a cifs-specific socket and
> enables impersonation for any user id:
> 
> [root at 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 at 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 at fedora33 ~]# mount -o sec=krb5,multiuser //dc/share /mnt
> [root at 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 at 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 at fedora33 ~]# gssproxy -i -d &
> [2] 3814
> [root at 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 at 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.