credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

Alexander Bokovoy ab at samba.org
Mon Mar 6 17:00:43 UTC 2017


On ma, 06 maalis 2017, Simo wrote:
> 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.
Unfortunately, no. If we ask for expiration of the cred when acquiring
it, acquire_cred_context() would call for kg_cred_resolve() and
there, if target name is known, it goes for krb5_cc_select() in case we
are initiator. krb5_cc_select() uses a collection cursor and MEMORY:
ccache collection does provide cursor interface which means all memory
caches are scanned to find the closest one to the target's realm. If it
happens to exist, this ccache will be taken to find out expiration time
and chosen for further operations.

Currently Samba does not ask for the lifetime of the ticket when calling
to gss_acquire_cred() so we don't get into this problem right now.

> 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.

-- 
/ Alexander Bokovoy



More information about the samba-technical mailing list