credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

[Simo]

On Mon, 2017-03-06 at 18:01 +0200, Alexander Bokovoy wrote:
> On ma, 06 maalis 2017, Simo wrote:
> > 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.
> 
> As Metze explained, MEMORY: ccaches are internally handled as a
> credentials cache collection, so even unrelated memory ccaches are
> used
> by ccselect mechanism to find out ccache with closest credential to
> the
> target's realm.
> 
> This is unacceptable in Samba case where multiple memory ccaches are
> used for different parts of the code. They step over each other due
> to
> ccselect making wrong decision to chose a particular memory ccache in
> a
> default memory ccache case.

Sorry guys, I think we are mixing things here.

If the default ccache (as per KRB5CCNAME or the default in the
libdefaults section of krb5.conf is just the string "MEMORY:" then we
will always have this issue, and a name should be provided in nput to
gss_acquire_cred* family of function to figure out which ccache should
be used.

If, instead we have a specific ccache name (either in KRB5CCNAME or by
using the cred_store extension) then all we really need to do is to
make sure GSSAPI does not defer credential acquisition by checking the
returned lifetime of the credentials (the only way to get a valid
lifetime is to actually initialize a ccache and find a ticket or
acquire a TGT for it.

In most cases in our code we want to check got expiration anyway in
order to be able to return an error earlier or (if we have crdentials)
force the system to acquire new creds.

Simo.