Skip Menu |
 

History Show all quoted text — Show full headers
# Tue Jan 23 13:29:23 2007 jaltman (Jeffrey Altman) - Ticket created
Subject: MEMORY keytab
Download (untitled) / with headers
text/plain 1KiB
This is a first cut at the memory keytab.

Outstanding issue:

There is no krb5_kt_destroy() function. This means that there is no
mechanism by which a keytab can be destroyed once it is created.

Heimdal destroys the MEMORY keytab whenever the krb5_kt_close results in
a zero reference count being reached. However, this seems wrong to me.
If you were to apply this semantic to FILE keytabs it would be the
equivalent of deleting the keytab file whenever there are no users of
the keytab. This semantic appears to be wrong to me.

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 ccache, this would mean truncate the contents
of the file and then unlink. 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.

Please comment.

A revised patch will be added to the ticket tomorrow after further testing.
Download kt_memory-diff.txt
unknown/exe 20.1KiB

Message body not shown because it is not plain text.

# Tue Jan 23 13:30:01 2007 jaltman (Jeffrey Altman) - Component krb5-libs added
# Tue Jan 23 13:30:01 2007 jaltman (Jeffrey Altman) - Version_reported 1.6 added
# Tue Jan 23 13:30:02 2007 jaltman (Jeffrey Altman) - Tags enhancement added
# Tue Jan 23 15:20:44 2007 raeburn (Ken Raeburn) - Comments added
From: Ken Raeburn <raeburn@MIT.EDU>
Subject: Re: [krbdev.mit.edu #5411] MEMORY keytab
Date: Tue, 23 Jan 2007 15:20:38 -0500
To: Kerberos Request Tracker <rt-comment@krbdev.mit.edu>
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.4KiB
On Jan 23, 2007, at 13:29, Jeffrey Altman via RT wrote:
Show quoted text
> Heimdal destroys the MEMORY keytab whenever the krb5_kt_close
> results in
> a zero reference count being reached. However, this seems wrong to
> me.
> If you were to apply this semantic to FILE keytabs it would be the
> equivalent of deleting the keytab file whenever there are no users of
> the keytab. This semantic appears to be wrong to me.

Me too.

Show quoted text
> 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 ccache, this would mean truncate the contents
> of the file and then unlink.

s/ccache/keytab/

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.

Show quoted text
> 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).

Ken
# Wed Jan 24 21:08:27 2007 jaltman (Jeffrey Altman) - Correspondence added
Download (untitled) / with headers
text/plain 2KiB
[raeburn - Tue Jan 23 15:20:44 2007]:
Show quoted text
> > 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.

Show quoted text
> 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.

Show quoted text
> > 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.
Download krb5-memory-keytab-heimdal-compat-diff.txt
unknown/exe 28.4KiB

Message body not shown because it is not plain text.

# Tue Jan 30 12:22:01 2007 jaltman (Jeffrey Altman) - Status changed from 'open' to 'resolved'
# Tue Jan 30 12:22:02 2007 jaltman (Jeffrey Altman) - Correspondence added
From: jaltman@mit.edu
Subject: SVN Commit
Download (untitled) / with headers
text/plain 700B
This commit adds a thread safe MEMORY keytab implementation
that is compatible with Heimdal 0.7. Each successful resolve
returns a handle to a keytab and increases the internal
reference count. Each close invalidates the handle and
decreases the reference count. When the reference count hits
zero, the keytab is destroyed.

When a kt_destroy function is added, the automatic destruction
after close behavior will be removed.


Commit By: jaltman



Revision: 19126
Changed Files:
U trunk/src/lib/krb5/keytab/Makefile.in
U trunk/src/lib/krb5/keytab/kt-int.h
A trunk/src/lib/krb5/keytab/kt_memory.c
U trunk/src/lib/krb5/keytab/ktbase.c
U trunk/src/lib/krb5/keytab/ktfr_entry.c
# Sat Feb 03 13:17:21 2007 jaltman (Jeffrey Altman) - Ticket 5427 RefersTo ticket 5411.
# Sun Feb 11 19:19:53 2007 epeisach (Ezra Peisach) - Correspondence added
From: epeisach@mit.edu
Subject: SVN Commit
Download (untitled) / with headers
text/plain 241B
In the resolve function - ensure on memory allocation error -
deref of null pointer does not happen.

Also include kt-int.h for prototypes.


Commit By: epeisach



Revision: 19153
Changed Files:
U trunk/src/lib/krb5/keytab/kt_memory.c
# Fri Jan 30 23:08:17 2009 tlyu (Taylor Yu) - Version_Fixed 1.7 added