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]
password quality check in case the user changes the user's own password
kadm_chpass_with_key: disallow the user to change it own password to a
key, since that password might violate the password quality check.
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@11626 ec53bebd-3082-4978-b11e-865c3cabbd6b
number of keys given: must be non-negative, small enough that it is
not truncated when stuffed into an int16_t for kadm5_free_key_data,
and small enough to avoid integer overflow when calculating the memory
required for the keys themselves.
XXX Why does kadm5_free_key_data use int16_t?
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@11415 ec53bebd-3082-4978-b11e-865c3cabbd6b
