credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

[Simo]

On Mon, 2017-03-06 at 16:44 +0100, Stefan Metzmacher wrote:
> Am 06.03.2017 um 16:31 schrieb Simo:
> > On Mon, 2017-03-06 at 15:56 +0100, 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.
> > 
> > It's not clear to me why you would need to use
> > krb5_cc_default_name(),
> > if you are looking to load the default ccache then you should not
> > pass
> > anything, because that's what the code does by default when no
> > "ccache"
> > is provided.
> 
> Have a look at acquire_cred_context() and acquire_init_cred()
> if they don't get a ccache pointer they'll behave like
> gss_acquire_cred() and leave cred->ccache = NULL, which will
> trigger the ccselect logic later, which is a potential security
> problem,
> if you have more than one identity in a process, which our code
> always
> has to assume.

Ah I see what you mean, this is the issue with gss_acquire_cred()
deferring actually acquiring creds ?

Ok for that the solution is to simply inquire for the expiration time.
In recent MIT Kerberos you just pass in a time_rec pointer, and it will
actually force the underlying code to acquire a ccache (I fixed this a
awhile ago in MIT, forgot exactly what version).

On older versions there was a bug and you'd get -1 in time_rec (IIRC),
in that case you can simply call gss_inquire_cred() and that will also
force gssapi to acquire creds right now instead of deferring.

So if the only problem is about deferred acquire creds we know how to
deal with it.

Simo.