The online LIST interrupt message is a NOP, but it's expected to not
have a reply (the server doesn't send one if it receives it before the
LIST finishes).
However, if the interrupt message arrives after the LIST finished, then
it does get a reply, and this causes the client to get out of step with
the server.
Fixes include:
1) flavor the interrupt NOP to make sure it never gets a reply,
2) introduce a new kadm_list_interrtupt message that is like a NOP that
produces no reply
3) always consume -after the LIST ends- a reply to any list interrupt
NOP on the client side.
This implements (1).
Implement a variation on the op for listing principals where if the
client indicates support for the new variation then we stream the list
instead of collecting it into one reply. This is the server-side
version of the associated, preceding commit:
kadm5: Add online kadm5_iter_principals()
Seeing "End of file" errors from kadm5 client calls which were the
result of not sending back errors in many error paths in
kadmin/server.c:kadmind_dispatch().
124b8d0f78 ("kadmin: kadmind_dispatch
do not write NULL 'rsp' to 'out'") was committed with an
unintentional source code removal.
Change-Id: I3de21e3624d713a9b5a1e89d147a5db5f1f55ab1
1b213c1082 ("kadmind: Add missing
error checks") altered the behavior of kadmin_dispatch() such that
it unconditionally called
krb5_storage_to_data(rsp, out);
This change was unsafe because krb5_unparse_name_fixed() failure
would skip the allocation of the 'rsp' and 'sp' krb5_storage
objects.
This change allocates the krb5_storage objects prior to performing
any work. If either of them fail, kadmin_dispatch() immediately
returns ENOMEM.
Change-Id: I14fd96afe029a4e74bb769605286ca0e17d25043
1b213c1082 ("kadmind: Add missing
error checks") altered the behavior of kadmin_dispatch() such that
it unconditionally called
krb5_storage_to_data(rsp, out);
Previously kadmin_dispatch() only wrote to 'out' on success.
Doing so is important because 'rsp' might be NULL on error.
Change-Id: I2688a5c47db0f94d955971e785037c578d3f3fa4
1b213c1082 ("kadmind: Add missing
error checks") altered the scope of the
if (ret == HEIM_ERR_EOF)
ret = 0;
treatment of HEIM_ERR_EOF as a success code. Prior to that
commit HEIM_ERR_EOF meant success only when reading the 'keepold'
value. It indicated a premature failure if returned when reading
'princ' or 'n_key_data'.
This change corrects the scope of HEIM_ERR_EOF indicating success.
Change-Id: If5463b47dc3eabee6fa2f8e717147f02adc1586c
warning: incompatible pointer types passing 'int *' to parameter
of type 'size_t *' (aka 'unsigned long *') [-Wincompatible-pointer-types]
Change-Id: Id75b1b1c9b46b63ab61134f4f91b7c2909d87077
Coverity determined that a NULL pointer segmentation fault could occur
if krb5_storage_emem() fails. Use krb5_enomem() to set an error message
on the context and do not perform further krb5_storage operations.
Change-Id: I9587208e46c184bb061443a44581a32dd722de33
- Add --keepold/keepallold/pruneall options to various kadmin/ktutil
commands. Default behavior to "prune old keys".
- When setting keys for a service, we need to specify enctypes for it:
- Always use kadm5_randkey_principal_3() instead of the older
kadm5_randkey_principal().
- Add krb5_string_to_keysalts2(), like MIT's krb5_string_to_keysalts(),
but with a context, and simpler.
- Add --enctypes options to various kadmin/ktutil commands.
- Add [libdefaults] supported_enctypes param with enctype[:salttype]
list.
- Add [realms] realm supported_enctypes param with enctype[:salttype]
list.
Default to aes128-cts-hmac-sha1-96:normal.
Note that this has a slight behavior change to c89d3f3b in order to continue
allow kadmin in local mode to bypass password quality checks. Password quality
checks are always bypassed if the *client* kadmin principal is kadmin/admin,
i.e. that of the kadmin service itself. This is the case when running kadmin in
local mode. As this is the equivalent of a superuser account, one would
anticipate that deployments would use specific administrator instances for
appropriate ACLs for day-to-day administration; operations by these will be
subject to password quality checks if enforce_on_admin_set is TRUE, or if the
user is changing their own password.
This patch adds the "enforce_on_admin_set" configuration knob in the
[password_quality] section. When this is enabled, administrative password
changes via the kadmin or kpasswd protocols will be subject to password quality
checks. (An administrative password change is one where the authenticating
principal is different to the principal whose password is being changed.)
Note that kadmin running in local mode (-l) is unaffected by this patch.
CVE-2016-2400
kadmind(8) was not checking for 'add' permission to aliases added via
kadm5_modify_principal(). This is a security vulnerability. The impact
of this vulnerability is mostly minor because most sites that use
kadmind(8) generally grant roughly the same level of permissions to all
administrators. However, the impact will be higher for sites that grant
modify privileges to large numbers of less-privileged users.
From what we know of existing deployments of Heimdal, it seems very
likely that the impact of this vulnerability will be minor for most
sites.
The Heimdal kadmind sends bogus keys when the client has 'get'
but not 'get-keys' permission. For some kadmin commands this is
dangerous. For example, ext_keytab could happily write bogus
keys to a keytab when real keys are expected, causing eventual
breakage. Sending bogus keys is important for the kadmin get
command: so it can list the keysets that a principal has.
This patch implements a heuristic detection of kadmin get vs.
ext_keytab, add_enctype, del_enctype, and check commands. If the
client principal lacks 'get-keys' permission, then the server
will fail requests that appear to be from those kadmin commands,
but will continue to serve bogus keys to kadmin get commands.
Thanks to Nico Williams for the idea behind this implementation.
When performing a permission check for a GET operation the
KADM5_PRIV_GET_KEYS privilege should not be assumed to be a pure
superset of KADM5_PRIV_GET. If the "get" permission is denied the
user cannot get an entry with or without key data.
The protocol for "get principal" does not support not sending
principal, so when the caller doesn't add KADM5_PRINCIPAL to the mask,
lets add it for them.
Reported by Henry.B.Hotz@jpl.nasa.gov in [HEIMDAL-588]
