credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

Andreas Schneider asn at samba.org
Mon Mar 6 15:46:00 UTC 2017


On Monday, 6 March 2017 16:17:52 CET Alexander Bokovoy wrote:
> On ma, 06 maalis 2017, Stefan Metzmacher wrote:
> > Am 06.03.2017 um 15:43 schrieb Alexander Bokovoy:
> > > On ma, 06 maalis 2017, Stefan Metzmacher wrote:
> > >> Hi Simo,
> > >> 
> > >>>> Yes, and that's exactly what I want. We should do such things
> > >>>> explicit
> > >>>> in order to avoid unexpected magic depending on the used kerberos
> > >>>> library.
> > >>> 
> > >>> Can you explain what magic you refer to ?
> > >>> What's your goal here ? Keep in mind that in MIT kerberos
> > >>> gss_krb5_import_cred() is implemented by calling the acquire_cred
> > >>> paths
> > >>> internally anyway, so the solution for any "magic" is likely the same
> > >>> in either case.
> > >> 
> > >> See https://bugzilla.samba.org/show_bug.cgi?id=12480, we need to
> > >> pass an explicit krb5_ccache in order to avoid the ccselect
> > >> magic, which is a security risk in our code. Therefore we need
> > >> to call krb5_cc_resolve() ourself. As we don't want the
> > >> library to choose any random ccache! Even if we want to use
> > >> the default cache for one cli_credential struct, it doesn't
> > >> mean we will only ever have one cli_credential in the current
> > >> process.
> > > 
> > > With gss_acquire_cred_from() we don't need to call krb5_cc_resolve() as
> > > you can pass information about specific ccache reference in the cred
> > > store details. That's one of the improvements here.
> > 
> > As far as I understand the code, the keypoint is that
> > acquire_cred_context() gets an explicit ccache, otherwise
> > the ccselect logic will be triggered later. That means
> > krb5_gss_acquire_cred_from() needs an explicit ccache name.
> > In order to pass it explicit we need to use krb5_cc_default_name()
> > anyway, so using krb5_cc_resolve() also doesn't make any difference,
> > but make things more explicit.
> 
> If we can replace ccache handle in our code with ccache name, we then
> can use cred store in gss_acquire_cred_from() to specify which
> credential cache to work on. If you don't pass cred store with 'ccache'
> store, then you wouldn't be able to influence which ccache is used and
> ccselect will kick in to find out closest credential in the collection
> that is marked as a default one.
> 
> This is really what we should do. Right now we use krb5_cc_resolve() and
> pass around ccache handle, but we should just pass a properly formatted
> ccache name and have a helper that prepares cred_store when calling into
> gss_acquire_cred_from().
> 
> Simo promised to look into simplifying use of
> smb_gss_acquire_cred_from() to make sure we don't move complexity up the
> call stack.

Well. That's what I did in my code. As we use a creds_container we can store 
the name of the ccache in the structure ...

https://git.samba.org/?p=asn/
samba.git;a=commitdiff;h=96d04aee8c6ff686be0511592217d2d323ec878f

This is for the keytab container, I had the same for the creds_container ...

https://git.samba.org/?p=asn/samba.git;a=shortlog;h=refs/heads/master-cli_creds


	Andreas

-- 
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             asn at samba.org
www.samba.org



More information about the samba-technical mailing list