From 69b0a8f4eb0a5b47db65f3427530903fb2238b35 Mon Sep 17 00:00:00 2001 From: Nicolas Williams Date: Thu, 12 Mar 2015 00:51:16 -0500 Subject: [PATCH] kadm5: kadmin modify must refuse bogus keys 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 --- lib/kadm5/modify_s.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/lib/kadm5/modify_s.c b/lib/kadm5/modify_s.c index 347ac2ed1..4f46e8c33 100644 --- a/lib/kadm5/modify_s.c +++ b/lib/kadm5/modify_s.c @@ -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;