Thread-safety in Kerberos libs

[Xiaoshan Zuo]

Unfortunately we have to share the security context among a few threads.
I took a look of the code again, I really don't see anything other than
ctx->seq_send can cause thread-safety problem (Linux kernel uses lock to
protect it) in the functions I am going to use in multithread context.
We should be able to run integrity/encryption/decryption with the same
security context. However, if I am wrong, I would like to identify which
part of the code causing the problem and hopefully fix them.

One thing I am not clear is what will happen when a credential expires.
Applications would have to destroy the context and re-create the
context. The problem is we may lose some messages during the transition.
In VPN which discards packets but TCP retransmission will retransmit the
discarded packet encrypted with new key. This is not the case here. I
guess I can work around the problem by closing the connection and force
client to reconnect.

Thanks,

- Xiaoshan


> -----Original Message-----
> From: Ken Raeburn [mailto:raeburn at MIT.EDU]
> Sent: Saturday, December 29, 2007 12:20 PM
> To: Xiaoshan Zuo
> Cc: krbdev at MIT.EDU
> Subject: Re: Thread-safety in Kerberos libs
> 
> On Dec 29, 2007, at 14:21, Xiaoshan Zuo wrote:
> 
> 
> > Our requirement comes down to the thread-safety of the code in
> > xdr_rpc_gss_wrap_data() function:
> 
> I don't see anything glaring there that would make it unsafe for a
> multithreaded environment, if "ctx" is not shared, though if
> debugging is enabled the log_debug or log_status output from multiple
> threads could get interleaved; but note that we haven't analyzed our
> version of the rpc library for thread safety.  And a spot check does
> find in clnt_perror.c a routine get_buf that provides a buffer to the
> caller using an unprotected global variable, rather than using per-
> thread data (which is the approach we've used for this sort of thing
> in the past, if you feel like submitting a patch).
> 
> > And similar function xdr_rpc_gss_wrap_data(). gss_get_mic() and
> > gss_wrap() can be called at the same time, and any one of them can
be
> > called by more than one threads simultaneously.
> 
> That part should be okay, as long as the security contexts aren't
> shared.
> 
> > Is a global krb5_context used in the libraries? I guess you mean the
> > krb5_context created by calling program.
> 
> There were at some times; I'm not sure if we've eliminated them all.
> If there are, they should be protected by mutexes.
> 
> When passing a krb5_context from the application, you need to make
> sure yourself that it's only in use from one thread at a time.
> 
> > The thing we care about is: can two threads call krb5 library to do
> > integrity check and encryption/decryption on input buffers at the
same
> > time with the same krb5 context. Since those operations don't
> > change any
> > security context which is established at context creation, they
should
> > be thread-safe.
> 
> The krb5 context includes cached information from the config file,
> which includes information on supported encryption types and such.
> The config file data may be updated if it hasn't been read before, or
> if the config files have changed; other fields cache the results of
> parsing certain of the config file entries.  So, yes, it's possible
> for the context to be changed by many of the calls into the krb5
> library, and it's not safe for a krb5_context to be used in more than
> one thread.  You should create one per thread, or create a shared
> pool of them, or something like that.
> 
> > Do you see there are any thread-safety issues on those operations?
In
> > gss_krb5int_make_seal_token_v3() from file k5sealv3.c, ctx-
> > >seq_send is
> > modified and used without locking, is this a problem?
> 
> That's the GSSAPI security context, and is also not protected against
> use in multiple threads.  It maintains such state as message sequence
> numbers.  If you want to use it in multiple threads, locking will be
> required.
> 
> Ken