[krbdev.mit.edu #5411] MEMORY keytab

Jeffrey Altman via RT rt-comment at krbdev.mit.edu
Wed Jan 24 21:08:30 EST 2007


[raeburn - Tue Jan 23 15:20:44 2007]:
> > I believe that there should be a new function:
> >
> > 	krb5_error_code KRB5_CALLCONV
> > 	krb5_kt_destroy(krb5_context context, krb5_keytab keytab);
> >
> > The semantics of this function are that the contents of the keytab are
> > destroyed.  For the FILE keytab, this would mean truncate the contents
> > of the file and then unlink.

> Do you want to scribble over it with zero/random bytes first?  If the  
> OS reuses the same disk data blocks (not guaranteed, but I suspect  
> common on non-journaling file systems, since it avoids rewriting some  
> metadata), that'll make it harder (not impossible) to recover the keys.
> 
> Same with SRVTAB key table type.  In fact, maybe we should have a  
> "scribble over file, fsync, truncate, and unlink" utility function.

Sounds like a good idea if krb5_kt_destroy() is implemented.
 
> >   For the MEMORY ccache, this would mean
> > empty the keytab of all entries and if it has a refcount of 0  
> > remove the
> > keytab from the in-memory list.
> 
> Use the "zap" macro to make sure the keys aren't left in memory (and  
> core files).

It turns out that krb5_free_keytab_entry_contents() was using memset()
and not zap().  For Windows, zap() results in a SecureZeroMemory() which
is not optimized out by the compiler.  I have replaced this with zap().

Attached is a new patch which implements a tested and I believe ready to
commit version of the Heimdal compatible keytab.   I do not want to add
the krb5_kt_destroy() function until there has been more feedback and
consensus has been reached.

The patch includes a test program t_ktm.c which is currently built on
Windows but not on Unix.  The test program creates 100 keytabs with 20
entries each, resolves each keytab a second time, searches for the
entries that were added, then enumerates the entries, removes some of
them, then closes both reference to each keytab thereby destroying the
contents, then resolves and closes once again the same keytab name.
This exercises all of the code paths.  

Please review when you have a chance.   






More information about the krb5-bugs mailing list