Skip Menu |
 

Date: Fri, 21 Nov 2014 21:37:06 -0700
From: Shawn M Emery <shawn.emery@oracle.com>
To: krb5-bugs@mit.edu
Subject: kadmind w/interactive master key + full resync = dump failure
Download (untitled) / with headers
text/plain 2.7KiB

When the master key is provided during kadmind startup and a full resync
is required for a slave, kdb5_util incorrectly assumes that the stash
file or that the password command argument is required to dump the
database for propagation, resulting in error:

# /usr/lib/krb5/kadmind -d -m
Enter KDC database master key:
kadmind: create IPROP svc (PROG=100423, VERS=1)
kadmind: starting...
iprop_get_updates_1: start, last_sno=0
iprop_get_updates_1:
clprinc=`kiprop/XXXXXXXXXXXX'
svcprinc=`XXXXXXXXXXXXXXXXXX'
iprop_get_updates_1: end (FR NEEDED)
iprop_full_resync_1: start
iprop_full_resync_1:
clprinc=`kiprop/XXXXXXXXXXXXXXXXXXXx'
svcprinc=`XXXXXXXXXXXXXXXXXXXXXX'
iprop_full_resync_1: fork=0 (25264)
iprop_full_resync_1: run `/usr/sbin/kdb5_util dump -i
/var/krb5/slave_datatrans_XXXXXXXXXXXXXXXXXXX' ...
iprop_full_resync_1: fork=25264 (25263)
iprop_full_resync_1: end (OK, sno=0)
kdb5_util: Cannot find/read stored master key while reading master key
kdb5_util: Warning: proceeding without master key
iprop_full_resync_1: pclose=256
iprop_full_resync_1: exec `kprop -f
/var/krb5/slave_datatrans_XXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX'
...
kprop: No such file or directory while trying to stat
/var/krb5/slave_datatrans_XXXXXXXXXXXXX.dump_ok

The problem is that kdb5_util makes a false assumption that the dump is not
valid if the master key is not available. This is a false assumption in a
couple of aspects:

1. The master key may not be readily available during automated propagation
if the stash file has not been created. Admins may not want stash files due
to security risks.

2. Having a master key does not necessarily mean that you can validate a db
dump. There is no way to validate the principals' keys even if they
could be
decrypted. The only keys you could verify is the master key.

Suggested fix is to not make the absence of a stash file or a password
command argument non-fatal:

src/kadmin/dbutil/kdb5_util.c:

@@ -476,11 +476,17 @@

global_params.stash_file,

&master_kvno,

0, &master_keyblock))) {

com_err(progname, retval, _("while reading master key"));

com_err(progname, 0, _("Warning: proceeding without master key"));

- exit_status++;

+ /*

+ * We don't want to count as an error if for instance the stash

+ * file is not present and we are trying to automate propagation,

+ * which really doesn't need a master key to do so.

+ */

+ if (retval != KRB5_KDB_CANTREAD_STORED)

+ exit_status++;

return(0);

}

}



if ((retval = krb5_db_fetch_mkey_list(util_context, master_princ,


Shawn.
--
Download (untitled) / with headers
text/plain 1.4KiB
[shawn.emery@oracle.com - Sat Nov 22 00:15:00 2014]:

Show quoted text
>
> When the master key is provided during kadmind startup and a full
> resync
> is required for a slave, kdb5_util incorrectly assumes that the stash
> file or that the password command argument is required to dump the
> database for propagation, resulting in error:
>
> The problem is that kdb5_util makes a false assumption that the dump
> is not
> valid if the master key is not available. This is a false assumption
> in a
> couple of aspects:
>
> 1. The master key may not be readily available during automated
> propagation
> if the stash file has not been created. Admins may not want stash
> files due
> to security risks.
>
> 2. Having a master key does not necessarily mean that you can validate
> a db
> dump. There is no way to validate the principals' keys even if they
> could be
> decrypted. The only keys you could verify is the master key.
>
> Suggested fix is to not make the absence of a stash file or a password
> command argument non-fatal:

I think that given how the dispatch table works, we can probably just add another column
indicating whether the given subcommand requires the master key and pass that in to
open_db_and_mkey(), so we can still require the master key for those operations which need it.

Tom notes that this might be a little exciting for the dump/load functionality that converts
master keys.

I can probably look into a patch along that route.

-Ben
At some point I would like to eliminate the opendb flag and instead
have the command handlers call a utility function if they need the DB
open. But for the purpose of fixing this issue we should do whatever
is most conservative.