oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

kadm5: kadmin modify must refuse bogus keys

Browse Source 
kadmin should not permit a modify that stores invalid keys into the
database.  Accepting bad key data into the database will result in
errors when those keys are eventually used.

This change does not address the general case.  It does address the
specific case of the kadmin client attempting to store the magic
bogus key since that is trivial to check for and can be unintentionally
returned to kadmind by a 1.6rc2 or prior client.  This can happen when
a user has get privilege but lacks the new get-keys privilege.

Change-Id: I44795e6428472b75ab1e4257ce7cb9160f0299f5
This commit is contained in:
Nicolas Williams
2015-03-12 00:51:16 -05:00
committed by Jeffrey Altman
parent dcbe8ae73b
commit 69b0a8f4eb
1 changed files with 15 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
lib/kadm5/modify_s.c
View File

@@ -68,11 +68,25 @@ modify_principal(void *server_handle,
if(ret)
goto out2;
/*
* If any keys are bogus, disallow the modify. If the keys were
* bogus as stored in the HDB we could allow those through, but
* distinguishing that case from a pre-1.6 client using add_enctype
* without the get-keys privilege requires more work (mainly: checking that
* the bogus keys in princ->key_data[] have corresponding bogus keys in ent
* before calling _kadm5_setup_entry()).
*/
if ((mask & KADM5_KEY_DATA) &&
kadm5_some_keys_are_bogus(princ->n_key_data, princ->key_data)) {
ret = KADM5_AUTH_GET_KEYS; /* Not quite appropriate, but it'll do */
goto out2;
}
ret = hdb_seal_keys(context->context, context->db, &ent.entry);
if (ret)
goto out2;
if((mask & KADM5_POLICY)) {
if ((mask & KADM5_POLICY)) {
HDB_extension ext;
ext.data.element = choice_HDB_extension_data_policy;